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 [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: https://lists.debian.org/[email protected]
