Package: cups Followup-For: Bug #769058 Looks like my ISP mailservers are acting funky lately. Ah well, time for an angry phone call to CS. (thanks for bouncing the message, guys!). I'm using Reportbug this time.
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, 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). 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. Although there is no bug on CUPS this time, such recent changes (the whole thing regarding FINAL_CONTENT_TYPE) aren't really documented in any end-user- facing documentation - same as for the tidbit regarding gzip compression and raw print queues. Again, I've been using the same print setup across all my clients (several versions of Windows, Debian, Fedora, and even Mac), and servers (all the way from Debian Lenny, up to Wheezy), but I haven't see nowhere that such setup (send formatted print data to a non-raw print queue) is no longer supported upstream. Expect breakage and pain for a lot of users (not that dealing with printers is funny nowadays, but I digress). Feel free to close this bug, but please make sure to point such things somewhere in the documentation, where end-users can actually find it. [1] https://en.opensuse.org/SDB:Using_Your_Own_Backends_to_Print_with_CUPS#A_careless_backend_for_a_single_USB_printer [2] http://www.cups.org/pipermail/cups/2011-September/023699.html -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'testing-updates') Architecture: i386 (i686) Kernel: Linux 3.16.0-4-686-pae (SMP w/1 CPU core) Locale: LANG=es_VE.UTF-8, LC_CTYPE=es_VE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages cups depends on: ii cups-client 1.7.5-7 ii cups-common 1.7.5-7 ii cups-core-drivers 1.7.5-7 ii cups-daemon 1.7.5-7 it cups-filters 1.0.61-4 ii cups-ppdc 1.7.5-7 ii cups-server-common 1.7.5-7 ii debconf [debconf-2.0] 1.5.54 ii ghostscript 9.06~dfsg-1.1 ii libavahi-client3 0.6.31-4+b1 ii libavahi-common3 0.6.31-4+b1 ii libc-bin 2.19-13 ii libc6 2.19-13 ii libcups2 1.7.5-7 ii libcupscgi1 1.7.5-7 ii libcupsimage2 1.7.5-7 ii libcupsmime1 1.7.5-7 ii libcupsppdc1 1.7.5-7 ii libgcc1 1:4.9.1-19 ii libstdc++6 4.9.1-19 ii libusb-1.0-0 2:1.0.19-1 ii lsb-base 4.1+Debian13+nmu1 ii poppler-utils 0.26.5-2 ii procps 2:3.3.9-8 Versions of packages cups recommends: ii avahi-daemon 0.6.31-4+b1 ii colord 1.2.1-1+b1 it cups-filters [ghostscript-cups] 1.0.61-4 ii printer-driver-gutenprint 5.2.10-3 Versions of packages cups suggests: ii cups-bsd 1.7.5-7 pn cups-pdf <none> ii foomatic-db-compressed-ppds [foomatic-db] 20141016-1 ii hplip 3.14.6-1+b2 ii printer-driver-hpcups 3.14.6-1+b2 ii smbclient 2:4.1.13+dfsg-2 ii udev 215-6 -- debconf information: cupsys/raw-print: true cupsys/backend: lpd, socket, usb, snmp, dnssd -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
