All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tim Waugh <twaugh@redhat.com>
To: Open Printing <printing-architecture@lists.linux-foundation.org>
Subject: [Printing-architecture] Handling multiple files of varying formats in CUPS
Date: Tue, 06 Aug 2013 13:20:38 +0100	[thread overview]
Message-ID: <1375791638.6320.8.camel@rubik> (raw)


[-- 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 --]

             reply	other threads:[~2013-08-06 12:20 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-06 12:20 Tim Waugh [this message]
2013-08-06 15:47 ` [Printing-architecture] Handling multiple files of varying formats in CUPS Michael Sweet

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1375791638.6320.8.camel@rubik \
    --to=twaugh@redhat.com \
    --cc=printing-architecture@lists.linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.