[cups.general] waitjob, waitprinter

[Michael Sweet]

On Aug 19, 2011, at 12:57 PM, Steve Bergman wrote:
> ...
> I'm not certain whether the HP LaserJet P3005n printers' internal IPP servers will act the same, and acknowledge an IPP cancel request from a CUPS server.

That really depends on the printer and the type of file being sent; in general, we stop sending data and send a cancel job request to the printer immediately afterwards, so you'll often get some output but hopefully not everything.

> I'm wanting to give the user the most extensive control possible for cancelling the job if they accidentally send a 1,000 page document to an invoice printer. If that requires a slight pause between back to back print jobs, we can certainly live with it. (It's just that people do grumble about the slight pause when they are doing multiple 1 page documents to the dot matrix printers.)

If you want reliability and the ability to cancel jobs while they are being sent or printed, that's the penalty you pay.  Being able to queue, monitor, and control multiple remote jobs is technically possible but will require some rather extensive changes to how we support shared printers. We're moving towards that...

> Is there some explanation of all this, somewhere, that goes beyond what is in the "Using Network Printers" portion of t.he CUPS documentation?

Not specifically, although you can search the archive here and in the bug database to find plenty of questions about this and requests to change it (thus things like the waitprinter and waitjob options).

> BTW, I wiped everything, recompiled with the zlib-devel stuff installed, as you suggested. Set up the local printers without  PPD's, moving the processing to the remote server. And compression=gzip is working very well. I've even seen a 20% to 30% reduction in bandwidth for a lot of the PDF's my users are sending, which surprised me, since they are already compressed. Though some show little to know reduction, as I had expected.
> 
> I saw one very interesting job, this morning (a postscript 3.0 document) which weighed in at 175MB before compression, and 2.2MB afterward. I'm not sure what was going on there.

Usually PostScript documents do not use compression, and often use the most inefficient encoding for images (uncompressed, hex encoded) which can yield some impressively large files.

Glad the compression is working well for you!

________________________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair