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

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

[Tim Waugh]

[-- Attachment #1.1: Type: text/plain, Size: 1713 bytes --]

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


[-- Attachment #1.2: cups-ipp-multifile.patch --]
[-- Type: text/x-patch, Size: 709 bytes --]

diff -up cups-1.6.3/backend/ipp.c.ipp-multifile cups-1.6.3/backend/ipp.c
--- cups-1.6.3/backend/ipp.c.ipp-multifile	2013-08-06 10:40:28.081145525 +0100
+++ cups-1.6.3/backend/ipp.c	2013-08-06 11:55:01.237739431 +0100
@@ -1682,8 +1682,8 @@ main(int  argc,				/* I - Number of comm
 	  ippAddString(request, IPP_TAG_OPERATION, IPP_TAG_NAME,
                        "requesting-user-name", NULL, argv[2]);
 
-        if ((i + 1) >= num_files)
-	  ippAddBoolean(request, IPP_TAG_OPERATION, "last-document", 1);
+	ippAddBoolean(request, IPP_TAG_OPERATION, "last-document",
+        	      (i + 1) >= num_files);
 
 	if (document_format)
 	  ippAddString(request, IPP_TAG_OPERATION, IPP_TAG_MIMETYPE,

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 482 bytes --]

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

[Michael Sweet]

Tim,

Filed the following Apple bugs to track this:

    <rdar://problem/14660379> cups.org: Missing last-document attribute from IPP backend.
    <rdar://problem/14660414> cups.org: Multiple file printing with different document formats is broken

Comments inline...

On 2013-08-06, at 8:20 AM, Tim Waugh <twaugh@redhat.com> wrote:
> ...
> 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.

Will include this in the final 1.6.4 and 1.7.0 releases.

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


The downside is that we will rely on auto-typing, even for jobs that auto-typing doesn't work (e.g. raw jobs).

I'm not sure what the right answer is, but I am tracking this separately since it will be a harder problem to solve.  I am thinking that we need CONTENT_TYPE_n environment variables that provide the content type of each file, not just the first one.

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair