waitjob, waitprinter

Steve Bergman sbergman27 at gmail.com
Fri Aug 19 13:57:04 PDT 2011


> On Aug 19, 2011, at 12:57 PM, Steve Bergman wrote:

> 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.

A 'best effort' to cancel the job is perfectly fine.

> If you want reliability and the ability to cancel jobs while they are being sent or printed, that's the penalty you pay.

That's what I needed to know. I can tell the users, and we can make the decision on a printer by printer basis. It's amazing how important 1-2 seconds can become when it's the focus of discussion.

> 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.

This one was exceptional. But I'm curious about whether this has been happening all along, or if the way I had things set up, with the ppd on the sending machine, was mitigating it. Presumably, the huge inefficient PS document would have gone through pstops before being sent over the wire. Would that have compacted it substantially? I should have thought to capture it for testing.

BTW, I really do appreciate your taking the time to answer my questions. Google has guided me to a lot of "But what does that mean, really?" sorts of answers.

After a long time selecting LPD and Appsocket because they are simple, I'm waking up to some of the real advantages of IPP.

-Steve Bergman




More information about the cups mailing list