Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!elroy.jpl.nasa.gov!lll-winken!tekbspa!uunet!auspex!guy
From: guy@auspex.auspex.com (Guy Harris)
Newsgroups: comp.windows.x
Subject: Re:  My $0.02 on local printing at X terminals
Message-ID: <3660@auspex.auspex.com>
Date: 15 Jul 90 01:30:17 GMT
References: <9007140606.AA03669@Larry.McRCIM.McGill.EDU>
Organization: Auspex Systems, Santa Clara
Lines: 30

>Primo: a standard already exists.  It's called lpr.

Well, "lpr" may or may not be the right protocol to use to talk to an X
terminal with a printer attached, but...

>Secundo: even so, that's no excuse for making X handle something
>  inappropriate to it.

...I agree 1000% with the second point.

If it's convenient for the X terminal to talk "lpr" (i.e., if it's
capable of taking several jobs and queuing them up somehow, which means
it may want to either have a local disk or a remotely-mounted file
system) it's a better choice. 

Otherwise, some other protocol could be imagined; I seem to remember
that Imagen printers have some protocol that lets you connect them to an
Ethernet and open TCP connections to some port and blat a print job at
them (they may refuse a connection, or something, if they're busy
printing), and Apple Laserwriters can certainly work over Appletalk, so
the idea of sending output to a printer over a network is demonstrably
implementable.

You could have a backend for your spooler (whether "lpr"-based or not)
that opened a connection to the printer rather than opening a serial or
parallel port to it (such as Columbia's CAP has for Appletalk printers,
for example).

No need to drag X into it, just because X happens to be *ONE* of the
services that the device to which the printer is attached offers.