Bug#777286: foo2zjs: cups to cups via IPP with foo2zjs processed on client fails
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.
Reply to: