chr(12) Form Feed in Notepad

[Steve Holden]

Odd that TXT files under Windows still use the same 13 (carriage
return), 10 (linefeed) and 9 (tab) codes that used to work on my ASR 33.
So why not code 12 (formfeed)?

Because the KSR/ASR33 devices were designed for continuous output in
things like torn-tape and torn-paper messaging systems (where I believe
Cable and Wireless made a lot of money once upon a time). There was no
point paginating the copy, and to do so would have been wasteful. An
operator would just hit CRLF a few times (in fact a good operator would
only return the carriage once at the start, and then just hit the
requisite number of line feeds.

regards
Steve

 

[bartc]

Because the KSR/ASR33 devices were designed for continuous output in
things like torn-tape and torn-paper messaging systems (where I believe
Cable and Wireless made a lot of money once upon a time). There was no
point paginating the copy, and to do so would have been wasteful.

My point was these other control codes from over 30 years ago are still in
use today, so why not also make use of chr(12)?

 

[Dennis Lee Bieber]

The package he's probably referring to is PyRTF. I took a quick look
at it and in my opinion it's overkill for your purposes. Since RTF is
actually just a markup language, and the only features of it that you
absolutely need are (1) a way to ensure a fixed-width font is used and
(2) a way to insert page breaks, it's probably quickest and simplest
to just throw the markup into the document yourself (well, with
Python) and naming the result with the .rtf suffix instead of .txt.

So, how do you find out what markup to use? Open WordPad, select the
font you want, type a bit of text, save the file as RTF (this should
be the default), and open up the file in Notepad. At the top will be
a bunch of setup codes, including the font selection. Make your
Python program put that whole spiel (including a trailing space or
newline, to separate your text from the last RTF tag) at the top of
your output. There will be one unmatched curly brace, which you
should close at the end of the document. On my computer, it looks
like this:

Basically the route I took a few years ago when I had to write a
tool parsing ClearCase file listings into a landscape format report...

Create a sample report in Word; save as RTF; cut snippets of RTF
control structures for use in a Python "report writer" (I had features
for defining page header/footers, column headers, page length, and
output methods that kept track of how many data lines remained on the
page -- if a block of text given for output wouldn't fit on the
remainder of the page, it would skip down to the footer area, output a
footer, newpage, output a header, output a column header if defined,
then output the data block)

 

[Dennis Lee Bieber]

My point was these other control codes from over 30 years ago are still in
use today, so why not also make use of chr(12)?

<FF> worked with old style text-only printers, where it triggered
the paper to move until a marker in a control tape matched. These
printers had known line spacing and column width (and did not wrap
text)...

Printing from Word/WordPad/NotePad doesn't follow that easy behavior
(in WordPad you can have text wrap to window, but it gets sent to a
printer as one long line which may or may not wrap depending on the
printer). A Text-only printer probably honors <FF>, but most all
printers in Windows are defined as graphical -- what is sent is a
bit-image of the data as rendered in a memory buffer at printer
resolution.

At that level, it is dependent upon what the printer driver and GDI
do when receiving a non-printable byte value...

 

[Grant Edwards]

The 1970's are over, and neither Notepad nor your printer attempts to
maintain compatibility with a Teletype model 37.

FF still works with a lot of things. Most ASCII printers still
honor it, as do pagers and programs like a2ps. I still use it
in ASCII text files...

 

[bartc]

<FF> worked with old style text-only printers, where it triggered
the paper to move until a marker in a control tape matched. These
printers had known line spacing and column width (and did not wrap
text)...

Printing from Word/WordPad/NotePad doesn't follow that easy behavior
(in WordPad you can have text wrap to window, but it gets sent to a
printer as one long line which may or may not wrap depending on the
printer). A Text-only printer probably honors <FF>, but most all
printers in Windows are defined as graphical -- what is sent is a
bit-image of the data as rendered in a memory buffer at printer
resolution.

At that level, it is dependent upon what the printer driver and GDI
do when receiving a non-printable byte value...

Until recently at least printers were non-text-only but did not necessarily
accept only bitmap images. For example they might use Postscript, HP/PCL or
Epson Esc/p (or whatever the exact names were). I'm fairly certain the last
two responded directly to chr(12) codes in the input stream.

Windows may or may not drive these in bitmap mode (which can be simpler for
Windows, but then you lose any special processing available inside the
printer), but given the task of sending a TXT file to such a printer, it is
not unreasonable to expect it to honour codes such as CR, LF and FF,
especially as most printers seem to be page-oriented now rather than use
roll or fanfold paper.

It would just need to translate FF into the page-break command for the
printer in question, eg. send the image so far and eject the page, just as
it might do for EOF.

 

[Dennis Lee Bieber]

Until recently at least printers were non-text-only but did not necessarily
accept only bitmap images. For example they might use Postscript, HP/PCL or
Epson Esc/p (or whatever the exact names were). I'm fairly certain the last
two responded directly to chr(12) codes in the input stream.

I no longer have access to the HP PCL, or the ancient Epson MX-80,
manuals... But those printers also operated in raw text modes; one had
to send control codes to enable the graphical operations, and might have
been able to drop in and out at will.

In contrast I once had a Lexmark inkjet (lasted less than a year --
poor color rendition, practically no ink-low feedback, I'm surprised it
honored paper-out signaling). This printer had NO TEXT MODE, and no
internal control language either [short of maybe codes telling it to
start/end page] -- the Windows (only) driver had to lay out everything
as a bitmap and send it to the printer... PCL, at least, allowed one to
send text to the printer after giving it codes for position on page,
font, and size...