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. -- http://mail.python.org/mailman/listinfo/python-list
