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

Michael Sweet msweet at apple.com
Tue Aug 6 15:47:15 UTC 2013


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

More information about the Printing-architecture mailing list