Subject: Re: bin/28593: lpd problem/bug with 'port@host' entries and jetdirect/direct tcp printers
To: None <kilbi@rad.rwth-aachen.de>
From: Greg A. Woods <woods@weird.com>
List: netbsd-bugs
Date: 12/09/2004 16:44:20
[ On Thursday, December 9, 2004 at 19:54:05 (+0100), Markus W Kilbinger wrote: ]
> Subject: Re: bin/28593: lpd problem/bug with 'port@host' entries and jetdirect/direct tcp printers
>
> My proposed patch just handles outstanding message data from the
> pronter at the end of a print job what might be not sufficient!
> Depending on the (postscript) print job much more message data can
> accumulate (I can remember some page numbering messages for each page)
> and fail the print job at an earlier stage. Maybe that's the reason
> why cups socket backend checks for (and cond. reads) incoming message
> data after each sent data block (8k in size), too.
Indeed it is quite possible for a print job on a true PostScript printer
to produce output at any time, and for it to produce pretty much any
amount of output too. E.g. fonts can be sent back, etc.
This is also why I use netatalk's printer interface with my Apple
LaserWriter instead of trying to use its builtin TCP/IP interface.
I've also tried to get afpd or papd or whichever it is to e-mail the job
output back to the user, but haven't had as much luck with that part
yet. Ideally though lpd would always do that....
However I would suggest that if lpd is going to read back any messages
from the printer that they should be logged in the error log file (LF)
and that they should also be mailed back to the user if possible.
(BTW, I've got a whole raft of other patches to usr.sbin/lpr that help
me avoid CUPS -- let me know if you want them! :-)
If I could avoid netatalk just for one printer I'd like to do that too!
--
Greg A. Woods
+1 416 218-0098 VE3TCP RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com> Secrets of the Weird <woods@weird.com>