--- Begin Message ---
Package: cupsys
Version: 1.1.10-3
Severity: normal
Tags: sid
When I setup a printer in CUPS which will output to a file (i.e. instead
of to a parallel port or serial port) I am unable to successfully send
raw data to that printer, and have the data show up in the file.
I use the hpoj drivers for hp multi-function devices available at
hpoj.sourceforge.net. These drivers allow me to print to and scan
from my PSC500. But to operate, they need to maintain the locks on
the /dev/lp0. So, I can print just fine to /dev/lp0, but as soon as I
run a scan job, I have to manually break the lock on /dev/lp0 before I
can print again. If I don't do this, the parallel backend reports that
the device is locked. To get around this, the hpoj software sets up a
named pipe that acts as a "spooler agnostic" interface to the user space
software that talks directly to the hardware. Thus the same software can
maintain locks on the device for both printing and scanning.
This works perfectly if I'm sending print jobs to the printer that
need to be processed by the filters. But I have windows users who are
trying to print to this printer (using IPP). They have a local print
driver installed and they need to be able to have CUPS handle raw print
jobs correctly.
I have tested sending raw print jobs to the parallel backend and the
socket backend and they seem to handle it correctly. I have also tested
sending raw print jobs to a plain file. If I send a non-raw job, the
file ends up with data in it. If I specify '-o raw' on the print job,
then the file ends up empty.
I've written a couple of very simple CUPS backends, and I have a guess
at what the problem is. When a CUPS backend gets input that's been
processed by the filters, that input comes on <stdin>. But when a CUPS
backend gets input delivered with the '-o raw' option (i.e. raw input,
or input that is not processed by the filters), CUPS stores that data
in a file, and sends nothing to the backend on <stdin>. Instead it
gives the name of the file as an argument when the backend is called
(specifically argv[6]). My guess is that the backend that handles
printing to files, assumes that all of its input will come on <stdin>,
and when it gets nothing, it sends nothing to the file.
I'm sending this here because this problem exists in the debian package.
But also because I could not find a mechanism to track this problem
when sent directly to the CUPS developers. I'm hoping that the debian
maintainer has better ability to track bugs submitted to the CUPS folks.
I've also cc'd the hpoj developer. He requested to be copied on this
bug report so that he can track the status.
-- System Information
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux mhorn 2.4.10mh01 #1 Mon Oct 1 21:43:48 EDT 2001 i686
Locale: LANG=C, LC_CTYPE=C
Versions of packages cupsys depends on:
ii adduser 3.42 Add and remove users and groups to
ii cupsys-pstoraster 1.1.10-3 Common UNIX Printing System(tm) -
ii libc6 2.2.4-3 GNU C Library: Shared libraries an
ii libcupsys2 1.1.10-3 Common UNIX Printing System(tm) -
ii libpam0g 0.72-32 Pluggable Authentication Modules l
ii libstdc++2.10-glibc2.2 1:2.95.4-0.011006 The GNU stdc++ library
ii zlib1g 1:1.1.3-16 compression library - runtime
--- End Message ---