Hello, 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 port. 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 http://en.opensuse.org/SDB:CUPS_in_a_Nutshell "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): ----------------------------------------------------------------------- ... Cc: gimp-print-devel@lists.sourceforge.net Subject: Re: [Gimp-print-devel] Cancelling printing Date: Tue, 9 May 2006 09:22:10 +0800 (CST) From: ... 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 termination sequence). 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. ----------------------------------------------------------------------- Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH, Maxfeldstrasse 5 Mail: jsmeix@suse.de 90409 Nuernberg, Germany WWW: http://www.suse.de/