[Inkjet-list] resetting printer

Mark VanderWiele 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
structure.

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
information
stored with a job can identify where graphics segments begin and end
(without reparsing
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
letting another
job get in that may get lost.

A simple method might be to have the printer driver return the size of it's
maximum graphics
segment, preferred character to fill the segment, and termination sequence.
Without the
additional knowledge of the beginning and end of graphics segments,  you
send extra
unprinted data.   However it always aborts without eating the next job.
Optimally,
there is a method to tell the (lp,usb,...) port to throw away buffered data
without letting
another job in during pooled printer situations.

Yes, something like this needs to be considered in a printer driver
interface.

Regards,
Mark V






More information about the printing-driver mailing list