[Printing-architecture] Handling multiple files of varying formats in CUPS

Tim Waugh twaugh at redhat.com
Tue Aug 6 12:20:38 UTC 2013


Multiple files handling seems a little broken in CUPS 1.6.3 when more
than one format is involved.

The scenario I'm looking at is this sort of thing:

lp -dtheprinter postscript.ps text.txt

(any two supported formats will show the issue)

where theprinter is a remote IPP queue. I'm testing with remote CUPS
queues.

What happens is that the Send-Document request fails altogether:

D [06/Aug/2013:11:13:39 +0100] Send-Document client-error-bad-request:
Missing last-document attribute in request.
E [06/Aug/2013:11:13:39 +0100] Returning IPP client-error-bad-request
for Send-Document (ipp://192.168.122.1:631/printers/DESKJET-990C) from
192.168.122.243

This is because the client, the ipp backend, only sets the last-document
attribute for the last file -- but the scheduler requires it for each
Send-Document request.

Attached is a patch to fix that.

However, even with that patch there is another problem. The files are
auto-typed correctly but the ipp backend sends:

Create-Document document-format=application/postscript
Send-Document document-format=application/postscript
Send-Document document-format=application/postscript (WRONG!)

In other words, CUPS sets the document-format attribute of every file in
a multi-file job to the format it detected for the first file.

I don't think the ipp backend has access to the auto-typed formats for
subsequent files (just the CONTENT_TYPE variable, which is set to that
of the first file).

One possible solution is to simply use application/octet-stream and let
the remote queue do its own auto-typing. I'm not sure what possible
downsides this might have.

How should this be handled?

Thanks,
Tim.
*/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: cups-ipp-multifile.patch
Type: text/x-patch
Size: 709 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/printing-architecture/attachments/20130806/8faf779b/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 482 bytes
Desc: This is a digitally signed message part
URL: <http://lists.linuxfoundation.org/pipermail/printing-architecture/attachments/20130806/8faf779b/attachment.sig>


More information about the Printing-architecture mailing list