[9fans] Printing via lpdaemon(1)

[Akshat Kumar <akumar@mail.nanosouffle.net>]

My CPU server is connected to an
HP OfficeJet 5610 printer via USB.
In its namespace, this is made
available as /dev/lp7. Printing using
lp(1) directly, as follows, works just
fine:

lp -dofficejet5610 [options] file

where the corresponding line in
/sys/lib/lp/devices is:

# HP OfficeJet
officejet5610	office sounine /dev/lp7 - gsijs!officejet+5500 generic
pcclone.new - - - -

While all this works fine using lp(1)
directly, I tried

cp /rc/bin/service/!tcp515 /rc/bin/service.auth/tcp515

so as to setup access via lpdaemon(1).
I checked with the source (as there are
no man pages for this), and lpdaemon
simply calls lp with the given
commands. So, as long as it is in the
same namespace with /dev/lp7, there
should be no problems.

However, this is not the case. Here is
my trial at using lpsend(1):

term% aux/lpsend tcp!sounine!515
-dofficejet5610
testing
^D
\x04unable to write to output, fd=9, count=2304: m
unable to create Job object err=32
unable to write to output, fd=9, count=16: m
unable to write to output, fd=9, count=0: m
AFPL Ghostscript 8.53: Unrecoverable error, exit code 1
term%

Note that the errors above Ghostscript
are from hpijs(1), which corresponds to
the gsijs!officejet+5500 CLASS spec in
the devices file.

On the other hand, if I specify -dstdout,
then everything works fine. So, I
changed /dev/lp7 in the devices file to
simply '-', without changing gsijs!....
That gave me:


term% aux/lpsend tcp!sounine!515
-dofficejet5610
testing
^D
\x04unable to write to output, fd=9, count=2304: m
unable to create Job object err=32
unable to write to output, fd=9, count=16: m
unable to write to output, fd=9, count=0: m
AFPL Ghostscript 8.53: Unrecoverable error, exit code 1

Error: /ioerror in --.outputpage--
Operand stack:
   1   true
Execution stack:
   %interp_exit   .runexec2   --nostringval--   --nostringval--
--nostringval--   2   %stopped_push   --nostringval--
--nostringval--   --nostringval--   false   1   %stopped_push   1   3
 %oparray_pop   1   3   %oparray_pop   1   3   %oparray_pop   1   3
%oparray_pop   .runexec2   --nostringval--   --nostringval--
--nostringval--   2   %stopped_push   --nostringval--
--nostringval--   0   3   %oparray_pop   --nostringval--
--nostringval--
Dictionary stack:
   --dict:1130/1686(ro)(G)--   --dict:0/20(G)--   --dict:77/200(L)--
Current allocation mode is local
Last OS error: 55
^Dterm%

So it seems to be a problem regarding the
processing of the data through the hpijs
program when lp is executed via lpdaemon.
Since this problem is nonexistent outside
of lpdaemon's invocation, I'd like to know
what it's doing differently - I don't see
any differences. Any ideas?


Thanks,
ak