Todd Whitesel <toddpw@best.com> writes:

  >> I recognize the impulse to change lpr/lpd as suggested here. If you "know"
  >> the remote printer speaks PostScript, then you want to use local resources
  >> (which may not be present at the spooler - lpr(1) makes reference to this
  >> in talking about Fonts) to do the transformation to PostScript.

  > There's more to it than that -- I may have root on my machine (thus freedom
  > to edit printcap) but not on the printer's serving machine. On short notice,

There is more than just the division between local/remote host to
consider, there is also the division between user/daemon process to
consider.  I see no reason why troff filters for example and the
various "magic" input filters around should not be run by lpr instead
of lpd.

In my view, lpd filters should do their "main" job of banner pages,
accounting and ensuring that each print job gets a "clean" printer
(not set to some funny state). Stuff you might not want to trust to a
user process. Another thing you might want to do is provide a virtual
postscript (for example) printer. The main reason you might want to do
postscript to inkjet conversion in an lpd daemon instead of in lpr
running as the user is to save on spool space. Postscript is typically
more dense than inkjet raster formats. But conversion from formats
which are likely to need to include fonts or postscript images etc
should run in the users context.

Other problems with lpd are the lack of two way data flow. Some
printers are capable of returning status and accounting
information. You can handle that with local printers and smart
filters, but not really for remote printers. There is a need for lpd
to be able to handle protocols other than lpd protocol (such as is
found in various printserver boxes).  This can all be done now, but in
a rather kludgy way. I bundle everything into the input filter,
including a process to talk to the print server.

I gather that currently input and output filters are not really in a
pipeline as one might imagine. Instead, they all have their standard
output connected to the device and lpd multiplexes between them (I
don't think this is documented anywhere). This prevents using the
output filter to impliment a "foreign" networking protocol (unless it
is the only filter). I suggest allowing the device to be a process,
perhaps by allowing "device" names starting with '|'.

A final annoyance with lpd is that you can not provide arguments to
printcap filters in /etc/printcap. Ultrix used to provide such a
capability and it was useful. Either you could simply append the
"standard" filter arguments to any arguments given in printcap, or you
could only supply the standard arguments when there are none specified
in /etc/printcap. Substitution of %x would be useful (for suitable
definitions of x).

For example, I wanted a filter to write "out of paper" etc status
messages to the status file. I ended up hard coding the name of the
status file because I couldn't supply it as a command line
argument. Nor could I really get the filter to look at /etc/printcap
itself, because the printer name is not available to the filter
either.

Finally, The ability to redirect jobs from one printer to another
would be useful for large sites. Of course, the printers have to be
"equivalent" in some sense so you need some concept of classes of
printers. Automatic load balancing I guess might be useful for large
sites though I think these days the trend is to having printers local
to workgroups rather than a bank of central printers.

This is all rather a long list, but I think much of it could be done
fairly simply without incompatability. 

 1. Allow "|<executable>" as a device name. This allows extensibility to
    other protocols.

 2. Allow arguments to be specified in /etc/printcap for filters
    (and for "device" processses above). % interpolation would be
    nice but less important.

 3. Allow for lpr filters as well as the existing lpd filters.

I think these would allow considerable extra flexibility.
    

Ian