Bug#777286: foo2zjs: cups to cups via IPP with foo2zjs processed on client fails
Source: foo2zjs
Severity: important
Tags: upstream
Dear Maintainer,
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.
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.
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.
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.
-- System Information:
Debian Release: 8.0
APT prefers testing-updates
APT policy: (500, 'testing-updates'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=pl_PL.utf8, LC_CTYPE=pl_PL.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
Reply to: