Bug#719946: cups: CUPS 1.6 client sends wrong mimetype to 1.5 server, can't print
On Tue 20 Aug 2013 at 18:54:11 -0430, Tom Maneiro wrote:
> There are no lpoptions files anywhere on the clients. inetd.conf
> also yields nothing interesting (nothing at all regarding
> CUPS/printing).
>
> Running "lpoptions" yields this on my Jessie clients:
> device-uri=usb://KONICA%20MINOLTA/mc1600W?serial=06796 finishings=3
> printer-uri-supported=ipp://192.168.0.254:631/printers/CL3005W
>
>
> On a Wheezy client I get a mostly identical output:
> device-uri=ipp://192.168.0.254:631/printers/CL3005W ICM=km2530_0
> printer-uri-supported=ipp://192.168.0.254:631/printers/CL3005W
(I suppose you have changed device-uri for the Jessie clients from what
you had previously so that you can print from them).
I think I can now reproduce what you are experiencing. It appears that
on Jessie FINAL_CONTENT_TYPE is categorised as application/vnd.cups-pdf
and this information is passed on to the server by the ipp backend. The
server is then unable to auto-type the incoming file because there is no
rule in mime.types to help it. So it just accepts what it is told.
foomatic-rip doesn't actually care what FINAL_CONTENT_TYPE is and should
render either application/pdf or application/vnd.cups-pdf on the basis
that both are in PDF format (from CONTENT_TYPE). It fails because the
file it has to deal with is not a PDF but HP Printer Job Language Data.
More on this later.
>From a log on a Jessie client would you please confirm you get something
like this:
D [26/Aug/2013:11:02:28 +0100] [Job 278] Auto-typing file...
D [26/Aug/2013:11:02:28 +0100] [Job 278] Request file type is text/plain.
I [26/Aug/2013:11:02:28 +0100] [Job 278] File of type text/plain queued by "brian".
Followed by
D [26/Aug/2013:11:02:28 +0100] [Job 278] 3 filters for job:
D [26/Aug/2013:11:02:28 +0100] [Job 278] texttopdf (text/plain to application/pdf, cost 0)
D [26/Aug/2013:11:02:28 +0100] [Job 278] pdftopdf (application/pdf to application/vnd.cups-pdf, cost 22)
D [26/Aug/2013:11:02:28 +0100] [Job 278] foomatic-rip (application/vnd.cups-pdf to printer/delcop, cost 0)
and then
D [26/Aug/2013:11:02:28 +0100] [Job 278] envp[30]="FINAL_CONTENT_TYPE=application/vnd.cups-pdf"
Contrast this with a Wheezy client log:
D [26/Aug/2013:11:25:04 +0100] [Job 388] Auto-typing file...
D [26/Aug/2013:11:25:04 +0100] [Job 388] Request file type is text/plain.
I [26/Aug/2013:11:25:04 +0100] [Job 388] File of type text/plain queued by "brian".
Followed by
D [26/Aug/2013:11:25:04 +0100] [Job 388] envp[29]="FINAL_CONTENT_TYPE=printer/CL3005W"
and then
I [26/Aug/2013:11:25:04 +0100] [Job 388] Started filter /usr/lib/cups/filter/texttopdf (PID 3866)
I [26/Aug/2013:11:25:04 +0100] [Job 388] Started filter /usr/lib/cups/filter/pdftopdf (PID 3867)
I [26/Aug/2013:11:25:04 +0100] [Job 388] Started filter /usr/lib/cups/filter/foomatic-rip (PID 3868)
I [26/Aug/2013:11:25:04 +0100] [Job 388] Started backend /usr/lib/cups/backend/ipp (PID 3869)
There is a disparity in the MIME types for FINAL_CONTENT_TYPE. I do not
know whether this is an intentional difference between CUPS 1.5.3 and
CUPS 1,6,3, so I'm Cc'ing this report upstream.
Finally: in your first mail you say:
. . . intensive), so the print data is crunched on the clients,
then sent as a raw print job to the server (which does nothing
but to dump it directly to the printer in its native LAVAFLOW
format)
In order for the server to do "nothing" it should not be filtering the
job.
lpadmin -p CL3005W -v usb://KONICA%20MINOLTA/mc1600W?serial=06796 -m raw
The file which comes from a Jessie client is in PJL format; it should
print with the server queue set up as above.
Regards,
Brian.
Reply to: