Ignoring printer errors

[Andrew Bartlett]

On Tue, 2003-02-11 at 00:15, Michael Sweet wrote:
> Andrew Bartlett wrote:
> > I'm wondering, why (in HEAD and 3.0) 
> > rpc_server/srv_spoolss_nt.c:_spoolss_enddocprinter_internal() doesn't
> > handle any errors?
> > 
> > It sort of makes sense if we don't check the output of running the
> > unix 'lpr' command (due to the separate thread of execution), but now
> > we have back-ends like CUPS, that return real error codes - error
> > codes that could well be used to give real meaning back to clients.
> 
> There is certainly no reason not to support error codes, and even the
> external print commands can return a non-zero exit status to indicate
> basic failure to queue (even if you don't know what the specific
> error is...)
> 
> I'll volunteer my time with an IPP->Windows error code mapping
> function...

Unless you have an official table we can (legally) get a copy of, I
would suggest this method to find the 'correct' mapping:

Win32 can print to IPP, as I understand it.  Therefore there must be a
function that submits a print job, and gets back an error code.  Submit
print jobs by the name "ipp-error-x" where x is a number in the range of
IPP errors.  Hack up CUPS to return that error, and print out what Win32
gives you as the error mapping.

In this case, we are interested in the Win32 errors (W_ERR), because
that is apparently what this function returns (but I'll let JRA comment
on that).  (We normally operate on NTSTATUS codes, which are slightly
different).

Andrew Bartlett