Mailinglist Archive: opensuse (5130 mails)
|< Previous||Next >|
Re: [SLE] Cleaning cups queue through ssh [SUSE 8.2]
- From: Johannes Meixner <jsmeix@xxxxxxx>
- Date: Tue, 9 May 2006 11:11:55 +0200 (CEST)
- Message-id: <Pine.LNX.4.58.0605091045540.21642@xxxxxxxxxxxxx>
On May 9 01:49 Carlos E. R. wrote (shortened):
> I was going to suggest "lpq" and then "lprm JOBNUMBER".
> However, I find that although the job disappears from the queue (lpq shows
> nothing), 90% of the times my printer continues printing, and I have to
> "kill -9" as root the "parallel" job that is printing to the parallel
> I don't know why, but it has been so for ages.
The "parallel" process is the CUPS backend which keeps running.
The backend must keep running so that the filter could send a
termination sequence to the printer to reset it.
Regarding filter and backend in general, see
"The Filter" versus "The Backends".
The problem is how to interrupt a printing job and leave the printer
in a clean state so that it is ready to print the next job.
Often this is simply not possible with generic printer drivers.
Often printing on a low-level inkjet printer with a generic driver
means that the driver sets up the printer to receive e.g. 12345678 bytes
of binary graphics data and then send the 12345678 bytes of binary
graphics data. Then the printer will interpret and print the next
12345678 bytes as graphics.
When this job is interrupted e.g. after 2345678 bytes, the printer
is still waiting for 10000000 bytes which it will interpret and
print as graphics.
I.e. the tricky part is how to tell a printer which is in graphics
printing mode to switch back to its normal mode. This is very
model specific and generic printer drivers don't support it.
And don't rely on that even model specific drivers support it
in any case.
You ask for more details?
You get more details ;-)
Here we are (from a mail on the gimp-print-devel mailing list):
Subject: Re: [Gimp-print-devel] Cancelling printing
Date: Tue, 9 May 2006 09:22:10 +0800 (CST)
The real problem I am having is if I succesfully cancel a print job
in cups, my Epson Photo 830 stops, leaving the cartiage in the air
in the middle, wait 3 mins, cartiage back to the printer, and no
more respond, it simply dead there ignoring anything sent from cups
and keep flashing blue LED, the only way to solve it is to
code-boot the printer and restart CUPS service. This doesn't seem
to happen on my PS laserjet printer.
I think cups is lacking a good way to handle communication to the
Inkjet printer which already started their job. Don't know if this
is cups problem or gutenprint enhancement.
As usual when it comes to printing, it's a bit more complicated than
it looks at first glance. The answer's different when you're printing
from the GIMP, Cinepaint, or PhotoPrint than it is when you're
printing from anything else.
The Print plugins for the GIMP and Cinepaint, and PhotoPrint as a
whole, are linked directly against Gutenprint and generate the raw
printer data in the application. CUPS doesn't know anything about the
contents of the data; it just sees a stream of bits and feeds them to
the printer. If you abort the job, it just stops sending data. The
only way out is to power cycle the printer, although I don't know why
you'd need to restart CUPS.
When printing from "conventional" applications, the application
generates PDF (or Postscript, or some kind of well-known image
format), which it sends to CUPS. CUPS creates a chain of filters and
back ends; the most interesting ones are the filter that generates
raster format (pstoraster, imagetoraster); the one that generates
printer-specific data; and the back end that actually sends the data
to the printer (parallel, usb, whatnot).
The filter that generates printer-specific data is actually the most
interesting, at least from my point of view. It takes raster data on
its stdin and sends printer-specific output to its stdout. One of
these filters is named rastertoprinter (in Gimp-Print 4.2) or
rastertogutenprint.5.0 (in Gutenprint 5.0). This is the piece that's
linked against Gutenprint.
In this situation, you can abort a job cleanly (most of the time, at
any rate). In this case, when you abort the job, what should happen
is that the top level filter gets killed, which cuts off its output.
The next filter sees that its input is cut off and cuts off its
output. When the Gutenprint filter sees that its input has been cut
off prematurely, it aborts the job cleanly (sending the correct
You can do this by selecting the Postscript output driver in the
Cinepaint print plugin; the problem with doing this is that you lose a
lot of the nice features of Gutenprint because we haven't implemented
them in the Postscript driver. This is an improvement that we want to
make, but didn't get to in time for 5.0. Hopefully we'll finally get
to it in the next release.
SUSE LINUX Products GmbH, Maxfeldstrasse 5 Mail: jsmeix@xxxxxxx
90409 Nuernberg, Germany WWW: http://www.suse.de/
|< Previous||Next >|