Before we "fix" lpd, I'd like to point out that there is an advantage to
the existing scheme: there are a limited number of possible formats going
over the net to the remote printer - see lpr(1), and printcap(5).

One of the guiding principles of the Internet is virtualization - we speak
to each other over the wire in a common intermediate bit stream which may
or may not be the native form on our particular hosts (and if not, we
translate in and out of it, as necessary). This is to guarantee
interoperability between hosts whose local forms are alien to each other.
Hopefully, the virtualized form has sufficient semantics that you don't
lose anything in the translation from the local host form to the
virtualized form (or vice versa).

I suspect that the authors of lpr/lpd decided that they didn't know, or
couldn't predict the full range of possible page description language
possibilities (e.g. PostScript, HP PCL, InterPress, raster), and that some
of the transformations would end up with lots more bits across the wire
than if sent in the original format. So, they decided to push
format-to-printer translation to the host directly connected to the
printer, rather than expose that entire transformation matrix to the
Internet at large.

I'd say we got lucky - there aren't that many printer languages. It's
mostly PostScript or raster for the "dumb" ink-jets (or straight ASCII for
gude old parallel printers). I'd also say that lpr/lpd needs some help
pretty badly - it's far too intimate with things like troff and the plot
system, but I suppose that is because they didn't want to invent their own
printer language as an intermediate...

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. It's
something I've needed or wanted to do any number of times myself. However,
I suggest that we think carefully about *how* we do it, and what result we
want...

	Erik <fair@clock.org>