[cups.general] cups stops itself due to rejected print file

Ambrose Li ambrose.li at gmail.com
Tue Jul 11 11:52:46 PDT 2006


On 11/07/06, Michael Sweet <mike at easysw.com> wrote:
> Click on "printers", scroll to your printer, click on "Set
> Printer Options", scroll to the bottom, choose your error
> policy.

Thanks. I had gone to that page before, but for some reason
(I blame the unreadable Unicode font) I missed that whole
"Policy" section.

> > 3. I still do not agree with client-error-bad-request stopping the
> > printer for the following reasons:
> >
> > (a) The HTML docs says that "The ErrorPolicy directive
> > defines the policy that is used when a backend is unable to
> > send a print job to the printer." The client-error-bad-request
> > is not about not being able to send a print job, it is (at least
> > for this case in question) about receiving malformed input.
>
> Actually, it is an error that cannot be recovered from.  We don't
> know why the request was bad, and that error should not occur
> during normal operations.
>
> Since, by default, CUPS does *not* throw away print jobs (we have
> a lot of customers that depend on reliable printing...), we have
> to stop the queue since the receiving end is rejecting the job with
> an unknown/unexpected/unexplained error.

No, this is a false dilemma: it does not "have to" to either throw away
the job or stop the queue; it can just as well Hold it and proceed to
the next job, and the problematic job still would not be lost.

What "reliable printing" means is different to different people. As I
have mentioned in a previous post some weeks ago, I used to
work in a place where "reliable printing" does not mean what you
have in mind.

> > (b) You cannot configure cups 1.2 to emulate cups 1.1,
>
> The default CUPS 1.2 configuration matches the CUPS 1.1
> behavior.

It may match the CUPS 1.1 "configuration", but it certainly does
not match its *behaviour* because of the new way that pstops
now works. (I.e., it was previously impossible to generate a
client-error-bad-request error because the application was not
very careful about following the DSC).

Perhaps DSC compliance problems should generate a new
error other than client-error-bad-request. CUPS certainly know
what happened (missing mandatory DSC comments in a file
that claims DSC compliance - many broken apps do this), and
IMHO it certainly is a fundamentally different kind of problem
than "not being able to send a print job to a printer".

>  > or
> > configure it to emulate an ordinary Postscript printer (e.g.,
> > which is connected to a parallel port), which would discard
> > malformed input but would *hold* the job if it really could
> > not be *sent* (i.e., paper out, offline, etc.). Doing this
> > would require the error policy to be sometimes cancel,
> > and sometimes hold, which is impossible but would be
> > what an ordinary person would expect.
>
> An "out of paper" condition, when detectable, holds a job for
> printing as you'd expect.  The only time we stop a queue is
> when we run into an error we can't explain or recover from
> without human intervention.

When I am sure that CUPS is functional again I'll see how
Win98 prints. But at the moment (I have put the problematic
jobs on hold) it does look like Win98 clients cannot set
options when printing to cups 1.2 queues.

-Ambrose





More information about the cups mailing list