Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!snorkelwacker!bloom-beacon!SMITHKLINE.COM!wood%lavc3.dnet
From: wood%lavc3.dnet@SMITHKLINE.COM (Bill Wood, SKB Pharmaceuticals R&D, 215-270-5163)
Newsgroups: comp.windows.x
Subject: Re:  printing at X terminals
Message-ID: <9007161432.AA02724@smithkline.com>
Date: 16 Jul 90 14:32:26 GMT
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
Lines: 45

>lpr the program is operating system specific.  lpr the network protocol
>is not; any machine capable of supporting TCP connections should be
>able to speak the network protocol used by lpr.  The only OS-specific
>part I see is that it uses BSD's "privileged port" notion, which does
>not prevent its use in this case.

There are a many ways to print to an X terminal's
printer, but none of them are as simple, straightforward, and obvious
as doing it through X.  The implementations of X terminal printing are
currently all different, are not secure, and don't run on all transport
layers supported by the server.  This situation is not surprising.  It is
difficult for a terminal manufacturer to implement, say, lpr, on a VMS
system.  For one thing, very few VMS systems have TCP/IP.
(I don't know of a terminal manufacturer who used lpr over tcp/ip either!)

>I'd much rather use something else (such as lpr), so that when the X
>server is not working (eg, not running) the printer is still available.

If the server isn't running on an x terminal, you're dead in the water.  If
you're on a workstation, use lpr to print.  I'm not suggesting that the
server monopolize the printer - the server could implement the printing
extension using (local) lpr on a workstation.

>I can't see how communicating with a printer attached to the box on
>your desk is any more a "terminal issue" than communicating with a disk
>attached to the same box.

Because local printing is something you do through your terminal connection.
Always has been.  The security  and access concerns of most users vis-a-vis
their terminal are the same  for their printer as for their terminals.
The printer is an extension of the terminal.

>It slices, it dices, it even displays windows!  I don't think X should
>be a do-everything protocol.  Something should be added to X only when
>necessary, which typically means that arbitrarion of access to it must
>(or should) depend on the window system.

That's a nice distinction, but its not practical in this case.  It doesn't
print.

>			old: mcgill-vision!mouse
>			new: mouse@larry.mcrcim.mcgill.edu


- Bill			wood@smithkline.com