Bug#777286: foo2zjs: cups to cups via IPP with foo2zjs processed on client fails
Ok,
I've changed
*cupsFilter: "application/vnd.cups-postscript 100 foomatic-rip"
*cupsFilter: "application/vnd.cups-pdf 0 foomatic-rip"
to
*cupsFilter: "application/vnd.cups-postscript 100 -"
*cupsFilter: "application/vnd.cups-pdf 0 -"
and It now works remotely.
(after some time - I've changed it BACK to foomatic-rip - it still
works. even after printserver reboot).
Local printing does NOT work with this printer, despite chaging it
back to foomatic-rip. I don't need it currently. It looks like the
modified PPD has been cached somewhere(?!).
The automatically discovered printer (avahi?) with server side
processing now does not work neither, but it used to.
Modifying the settings from cups panel recreates the problem, and the
problem is present for freshly added duplicates of the printer.
So the current situation is:
Cups with foo2zjs on client puts the stream with unknown mime to the
server. The server matches the stream to one of those:
application/vnd.cups-pdf
application/vnd.cups-postscript
but it should not - as raw stream it should be sent directly.
2015-02-15 12:37 GMT+01:00 Oskar Bożek <bozkar@gmail.com>:
> 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: