Thank you for your analysis, Tom.
On Mon 01 Dec 2014 at 19:29:22 -0430, Tom Maneiro wrote: > Anyway, I've found the last missing piece on this puzzle. I decided to peek at > /var/spooler/cups while a print job was in transit down to the printer. And > sure enough, instead of uncompresssed PJL+LAVAFLOW data, I found that the job > data was compressed (gzipped, actually). Of course, my printer doesn't know > what to do with gzipped LAVAFLOW, because it can only deal with raw > uncompressed streams (luckily for me, this mishap didn't ended into a ton of > printed garbage sheets - the printer just silently discarded the data assuming > it was corrupt, Having data compressed by the IPP backend is new(ish) and documented at http://www.cups.org/str.php?L4168 > and this also explains why there were no errors logged by the > CUPS USB backend since the printer didn't tell that something went wrong with > the data sent). Your previous log records an unhappy USB transaction: D [30/Nov/2014:16:53:22 -04-30] [Job 354] Read thread still active, aborting the pending read... I do not know what the significance is. > This also explains why the simple cat print.file > > /dev/usb/lp0 > worked fine, yet a simple CUPS backend script [1] doing exactly the same > yielded more failure > > Sadly, disabling gzip compression in CUPS isn't straigtforward, instead you're > expected to use a dummy shell script to force decompression if you're dealing > with raw queues [2]. The file:/ backend seems to do decompression due to its > nature, yet none of the other backends do it. After applying the workaround > noted in that message, I'm now able to print just fine. The file backend makes a call to gziptoany, which uncompresses the file taken from the spool. Two other (possibly simpler) methods: 1. On a client have a queue with '-v ipp://<IP>/printers/CL3005W?compression=none' 2. Set up clients and server as you originally had them. Delete the two *cupsFilter lines from the foo2zjs PPD on the server and add *cupsFilter "application/vnd.cups-pdf 0 -"' '-' passes through the data without doing anything apart from running gziptoany when the file is taken out of the spool. Regards, Brian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
