Ok, so what should I try now? How I should prevent double-processing? After reading #769058 I supposed it's gzip related, but I haven't managed to properly disable it, nor catch the gzipped file anywhere. Although, It used to work with older versions. -- Regards Oskar
2015-02-09 18:06 GMT+01:00 Brian Potkin <claremont...@gmail.com>: > On Sat 07 Feb 2015 at 11:49:10 +0100, Oskar Bożek wrote: > > Hellp Oskar, > > Thank you for your report. > > >> Please consider following configuration: >> >> Raspberry Pi with raspbian wheezy with >> printer-driver-foo2zjs 20120510dfsg0-1 >> cups 1.5.3-5+deb7u4 >> and a HP Laserjet 1018 connected. >> >> Client (amd64 PC) with Debian jessie with >> printer-driver-foo2zjs 20140925dfsg0-3 >> cups 1.7.5-10 >> >> Printing from client to server over IPP does not work. Both are set to >> foo2zjs >> driver. > > The job undergoes two sets of processing - once on the client and then > on the server. I do not understand why this is necessary. If processing > on the client is a must the queue on the server should be a raw one. > > #769058 is a similar report. It is difficult to accept there is a bug in > the behaviour of the printing system. > >> Client is doing the ghostscript job, foo2zjs job, and sending the zjstream >> over >> IPP. The stream is then processed by server, and here the fail comes: >> >> D [07/Feb/2015:10:18:24 +0100] [Job 798] Cannot process "<STDIN>": Unknown >> filetype. > > Possibly the file type is application/vnd.cups-pdf. > >> D [07/Feb/2015:10:18:24 +0100] [Job 798] Process is dying with "Could not >> print >> file <STDIN> >> D [07/Feb/2015:10:18:24 +0100] [Job 798] ", exit stat 2 >> D [07/Feb/2015:10:18:24 +0100] [Job 798] Cleaning up... >> D [07/Feb/2015:10:18:24 +0100] [Job 798] Sent 0 bytes... >> D [07/Feb/2015:10:18:24 +0100] [Job 798] Waiting for read thread to exit... >> D [07/Feb/2015:10:18:24 +0100] [Job 798] Read thread still active, aborting >> the >> pending read... >> D [07/Feb/2015:10:18:24 +0100] [Job 798] End of messages >> D [07/Feb/2015:10:18:24 +0100] [Job 798] printer-state=3(idle) >> D [07/Feb/2015:10:18:24 +0100] [Job 798] printer-state- >> message="/usr/lib/cups/filter/foomatic-rip failed" >> D [07/Feb/2015:10:18:24 +0100] [Job 798] printer-state-reasons=none >> E [07/Feb/2015:10:23:29 +0100] [Job 798] Stopping unresponsive job! >> >> >> Basically - zjs is not sent directly to the printer as it should. >> >> It used to work some time ago, with some limitations, like page number always >> set to 1, etc. >> >> The basic solution is to send generic postscript stream over IPP (setting >> driver on client to Generic Postscript Printer) and process it to zjs on >> server. It works, but foo2zjs on Raspberry Pi is obviously very inefficient. > > The file type given to the server is application/vnd.cups-postscript, so > this works. > >> Why do I even report it? Because using MS Windows as clients, and sending >> client-side processed stream over IPP just works perfectly, so there must be >> some client-side solution. That's the desired way because of processing >> power. > > Jobs from Windows clients undergo no further processing on the server. > > Regards, > > Brian. > -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
