[cups.development] [RFE] STR #621: printing to classes of IPPproduction printers

Michael R Sweet msweet at apple.com
Sun Feb 8 10:24:04 PST 2009

H. Blischke wrote:
>> [STR Closed w/Resolution]
>> In reviewing this bug, the "waitprinter" URI option can be used to ignore
>> the printer state, e.g.:
>>     ipp://foo/bar?waitjob=no&waitprinter=no
>> Note however that you'll lose any guarantee that the job actually got
>> printed.
>> Link: http://www.cups.org/str.php?L621
>> Version:  -feature
>> Fix Version: 1.1.21
> For sure, I useed (and still use) these options but it does not cure the problem I have. As the respective printer returns a "stopped" response, the CUPS queue *and* the current job both get stopped although the job has been submitted successfully.
> On enabling the printer the job is submitted once more, which is not acceptable in a production environment.

As I'm mentioned to Xerox and (indirectly) to several other users in
the same boat, having a printer-state of "stopped" has serious side-
effects with CUPS.

Our hack of "waitprinter=no" combined with the existing changes in
CUPS 1.3.9 and later to not pause the local queue when the remote
queue reports "paused" should prevent the queue from getting stopped.

Michael R Sweet                        Senior Printing System Engineer

More information about the cups-devel mailing list