[Inkjet-list] resetting printer
markv at us.ibm.com
Mon Feb 4 09:18:27 PST 2002
> ming wrote:
>The problem is: printers have different reset code,
>there is no printer reset code definition in any printer capability
database. But even you
>have the reset code for a specific printer, you still have to be
>careful, because sometimes the printer is in such a transmission state
>that it accept your reset code as binary data. It's very tricky to
>figure out how to make printer get out of those mode.
>CUPS guys told me they can bring the printers to a sanity state when you
>cancel the print job in the middle. Ghostscript is so ugly for modern
>printing. I always ask Linux printing guys why don't they abandon
>working around with ghostscript and start from a totally new one
You are absolutely correct. Only the printer driver for the device knows
how much data to
complete before a reset command can be successfully sent. Additional
stored with a job can identify where graphics segments begin and end
unfamiliar data). Additional communication between the output device
driver (lp...) is necessary
to abort all queued data, send the correct amount of nulls (or other
characters specified by
the printer device driver) to get the printer out of graphics mode, send
any additional necessary
commands, and then send the reset command. Ouch, and do this without
job get in that may get lost.
A simple method might be to have the printer driver return the size of it's
segment, preferred character to fill the segment, and termination sequence.
additional knowledge of the beginning and end of graphics segments, you
unprinted data. However it always aborts without eating the next job.
there is a method to tell the (lp,usb,...) port to throw away buffered data
another job in during pooled printer situations.
Yes, something like this needs to be considered in a printer driver
More information about the printing-driver