> 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,
I can only change my own machine in order to Get Things Done (tm).

In an ideal world lpd would probe the printer to find out what formats it
supports (keep an eye on HP's JetDirect initiative) and publish them on a
well-known port. This would allow lpr to do high-level typechecking of
print jobs sent to remote printers and could also become the basis for a
system that tracks the state of all available remote printers. A graphical
front end to lpr would look at the job file, show you a list of printers that
would be able to print it, and in principle could even show you the depth of
the print queue on each printer (plus the status of the paper tray!!).

Back to the original topic: We are looking at a performance/flexibility
tradeoff here. (It also impacts the elegance/cleanliness of lpr/lpd which
I think is your main point.) It is not a question of whether or not these
features are a good idea. The real question is whether or not they should
be integrated _into_ _lpr/lpd_ or whether they should be implemented in a
separate program (or a compile-time configurable variant of lpr/lpd).

Todd Whitesel
toddpw @ best.com