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