«

I thought I'd put a page break, chr(12), character in a txt file I wrote
to skip to the top of the page. It doesn't work. Comments?

On 2010-01-15, W. eWatson <> wrote:

> I thought I'd put a page break, chr(12), character in a txt
> file I wrote to skip to the top of the page. It doesn't work.
> Comments?

Yes, it does work.

--
Grant Edwards grante Yow! ... bleakness
at ... desolation ... plastic
visi.com forks ...

Grant Edwards wrote:
> On 2010-01-15, W. eWatson <> wrote:
>
>> I thought I'd put a page break, chr(12), character in a txt
>> file I wrote to skip to the top of the page. It doesn't work.
>> Comments?
>
> Yes, it does work.
>
Apparently not with with my Brother 1440 laser printer. The character in
NotePad.txt looks like a small rectangle, and on the printed page. Same
result HP C6180 Photosmart.

W. eWatson wrote:
> Grant Edwards wrote:
>> On 2010-01-15, W. eWatson <> wrote:
>>
>>> I thought I'd put a page break, chr(12), character in a txt
>>> file I wrote to skip to the top of the page. It doesn't work.
>>> Comments?
>> Yes, it does work.
>>
> Apparently not with with my Brother 1440 laser printer. The character in
> NotePad.txt looks like a small rectangle, and on the printed page. Same
> result HP C6180 Photosmart.

But are you sending the raw control codes to the printer, or are
you sending the image-of-my-text-document to a printer-GDI which
then renders the as-you-see-it out of the printer?

The pseudo-pipeline comparison would be

type file.txt > lpt1:

which would send the raw text file to the printer (assuming it's
set up on LPT1, otherwise, use whatever port it's attached to in
your printer control panel); or are you using something like

notepad file.txt
File -> Print

which renders to an internal image representation and then sends
that image out to the printer. If it were a dot-matrix printer,
you'd here/see the difference in a jiffy -- the raw dump is fast
and uses the printer's built-in fonts while the render-as-image
is slow and NOISY.

One alternative is possibly to set up the "Generic Text" printer
as a device type and attach it to the same port; I've had fair
fortune with this letting me control the printer more directly if
I want fast dumps (particularly on dot-matrix printers) rather
than pretty dumps.

-tkc

Tim Chase wrote:
> W. eWatson wrote:
>> Grant Edwards wrote:
>>> On 2010-01-15, W. eWatson <> wrote:
>>>
>>>> I thought I'd put a page break, chr(12), character in a txt
>>>> file I wrote to skip to the top of the page. It doesn't work.
>>>> Comments?
>>> Yes, it does work.
>>>
>> Apparently not with with my Brother 1440 laser printer. The character
>> in NotePad.txt looks like a small rectangle, and on the printed page.
>> Same result HP C6180 Photosmart.
>
> But are you sending the raw control codes to the printer, or are you
> sending the image-of-my-text-document to a printer-GDI which then
> renders the as-you-see-it out of the printer?
>
> The pseudo-pipeline comparison would be
>
> type file.txt > lpt1:
>
> which would send the raw text file to the printer (assuming it's set up
> on LPT1, otherwise, use whatever port it's attached to in your printer
> control panel); or are you using something like
>
> notepad file.txt
> File -> Print
>
> which renders to an internal image representation and then sends that
> image out to the printer. If it were a dot-matrix printer, you'd
> here/see the difference in a jiffy -- the raw dump is fast and uses the
> printer's built-in fonts while the render-as-image is slow and NOISY.
>
> One alternative is possibly to set up the "Generic Text" printer as a
> device type and attach it to the same port; I've had fair fortune with
> this letting me control the printer more directly if I want fast dumps
> (particularly on dot-matrix printers) rather than pretty dumps.
>
> -tkc
>
>
>
I should mention I'm using Windows. I just put chr(12) right in the txt.
It's the first character in the next line of the txt file where I want
to page forward. Not acquainted with GDI. Maybe I need some sequence of
such characters?

W. eWatson wrote:
> Tim Chase wrote:
>> The pseudo-pipeline comparison would be
>>
>> type file.txt > lpt1:
>>
>> which would send the raw text file to the printer (assuming it's set up
>> on LPT1, otherwise, use whatever port it's attached to in your printer
>> control panel); or are you using something like
>>
>> notepad file.txt
>> File -> Print
>
> I should mention I'm using Windows. I just put chr(12) right in the txt.
> It's the first character in the next line of the txt file where I want
> to page forward. Not acquainted with GDI. Maybe I need some sequence of
> such characters?

It's not a matter of you controlling the GDI stuff. Unless
you're writing directly to the printer device, printing on
Windows is done (whether by Notepad, gvim, Word, Excel, whatever)
into a graphical representation which is then shipped off to the
printer. So if you're printing from Notepad, it's going to print
what you see (the little square), because Notepad renders to this
graphical representation to print. If you send the file
*directly* to the printer device (bypassing the Win32 printing
layer), it will send the ^L directly and should eject a new page
on most printers.

-tkc

Tim Chase wrote:
> W. eWatson wrote:
>> Tim Chase wrote:
>>> The pseudo-pipeline comparison would be
>>>
>>> type file.txt > lpt1:
>>>
>>> which would send the raw text file to the printer (assuming it's set
>>> up on LPT1, otherwise, use whatever port it's attached to in your
>>> printer control panel); or are you using something like
>>>
>>> notepad file.txt
>>> File -> Print
>>
>> I should mention I'm using Windows. I just put chr(12) right in the
>> txt. It's the first character in the next line of the txt file where I
>> want to page forward. Not acquainted with GDI. Maybe I need some
>> sequence of such characters?
>
> It's not a matter of you controlling the GDI stuff. Unless you're
> writing directly to the printer device, printing on Windows is done
> (whether by Notepad, gvim, Word, Excel, whatever) into a graphical
> representation which is then shipped off to the printer. So if you're
> printing from Notepad, it's going to print what you see (the little
> square), because Notepad renders to this graphical representation to
> print. If you send the file *directly* to the printer device (bypassing
> the Win32 printing layer), it will send the ^L directly and should eject
> a new page on most printers.
>
> -tkc
>
>
I am writing a txt file. It's up to the user to print it using Notepad
or some other tool. I have no idea how to send it directly to the
printer, but I really don't want to furnish that capability in the
program. From Google, The Graphics Device Interface (GDI).

On Jan 15, 6:40*pm, "W. eWatson" <wolftra...@invalid.com> wrote:
> Tim Chase wrote:
> > W. eWatson wrote:
> >> Tim Chase wrote:
> >>> The pseudo-pipeline comparison would be
>
> >>> * type file.txt > lpt1:
>
> >>> which would send the raw text file to the printer (assuming it's set
> >>> up on LPT1, otherwise, use whatever port it's attached to in your
> >>> printer control panel); or are you using something like
>
> >>> * notepad file.txt
> >>> * File -> Print
>
> >> I should mention I'm using Windows. I just put chr(12) right in the
> >> txt. It's the first character in the next line of the txt file where I
> >> want to page forward. Not acquainted with GDI. Maybe I need some
> >> sequence of such characters?
>
> > It's not a matter of you controlling the GDI stuff. *Unless you're
> > writing directly to the printer device, printing on Windows is done
> > (whether by Notepad, gvim, Word, Excel, whatever) into a graphical
> > representation which is then shipped off to the printer. *So if you're
> > printing from Notepad, it's going to print what you see (the little
> > square), because Notepad renders to this graphical representation to
> > print. *If you send the file *directly* to the printer device (bypassing
> > the Win32 printing layer), it will send the ^L directly and should eject
> > a new page on most printers.
>
> > -tkc
>
> I am writing a txt file. It's up to the user to print it using Notepad
> or some other tool. *I have no idea how to send it directly to the
> printer, but I really don't want to furnish that capability in the
> program. From Google, The Graphics Device Interface (GDI).

Have you considered the possibility that your printer can't print
raw text files? I had one that would ONLY print Postscript. Embedding
a chr(12) would accomplish nothing, you HAD to use a driver that
would translate chr(12) into the appropriate Postcript codes.

What you're doing MIGHT work for others with different printers.

W. eWatson wrote:

> I am writing a txt file. It's up to the user to print it using Notepad
> or some other tool.

WordPad will interpret chr(12) as you want.

Neil

W. eWatson wrote:
> I am writing a txt file. It's up to the user to print it using
> Notepad or some other tool. I have no idea how to send it
> directly to the printer, but I really don't want to furnish
> that capability in the program. From Google, The Graphics
> Device Interface (GDI).

If you're writing it to a text file and assuming that Notepad is
smart enough to properly handle form-feeds, I'm sorry, you'll be
disappointed...this says more about the brain-deadness of Notepad
than your optimism

If you have a configurable destination, you might be able to do
something within your Python app like

if 'win' in sys.platform.lower():
default_dest = "lpt1:"
else:
default_dest = "/dev/lp0"
dest = config.get("printer", default_dest)
f = file(dest, 'wb')
f.write(my_output_with_ff)
# optionally
# f.write(chr(12))
# to eject the last page
f.close()

Otherwise, you'd have to write to something a default Windows
application would know how to handle with embedded
form-feeds/page-breaks (i.e., not Notepad as the default .txt
handler). My first thought would be to export it as RTF (there
was a good python RTF library I tinkered with one afternoon --
it's a quick google away) which should allow embedding
page-breaks, and even give you a fair bit of additional control
over other aspects like fonts and styles.

-tkc