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