tron@lyssa.owl.de (Matthias Scheler) writes:

  > In article <199807220154.LAA01390@wasd015.dsto.defence.gov.au>,
  > 	Ian Dall <Ian.Dall@dsto.defence.gov.au> writes:
  >> 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.

  > Because the machine sending the job to "lpd" maybe a stupid Windows NT?
  > Or because it makes much more sense to install and configure "magicfilter"
  > and the packages required to use it on a single server instead of several
  > clients?

OK, I take that point. More often I see it the other way around though.
The printer is connected to a stand alone print server or a host
I don't have administrative control over.

Note though that I didn't suggest taking out the existing server side
filters. Rather, I suggested *adding* client side filters which would
run from lpr (if they are defined in printcap). That leaves the
decision to the administrator. Obviously you wouldn't want the troff
(or whatever) filter applied twice, but that isn't hard to organize.

Part of the problem is that troff, dvi etc are not very good printer
protocols for various reasons, so making a virtual troff printer has
problems, but my proposal doesn't make these problems any worse.

Ian