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. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
