"Dennis Lee Bieber" <wlfr...@ix.netcom.com> wrote in message
news:mailman.1021.1263702437.28905.python-l...@python.org...
On Sat, 16 Jan 2010 23:59:52 GMT, "bartc" <ba...@freeuk.com> declaimed
the following in gmane.comp.python.general:
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...
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.
--
bartc
--
http://mail.python.org/mailman/listinfo/python-list
