Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!zaphod.mps.ohio-state.edu!usc!snorkelwacker!bloom-beacon!EXPO.LCS.MIT.EDU!rws
From: rws@EXPO.LCS.MIT.EDU (Bob Scheifler)
Newsgroups: comp.windows.x
Subject: Re: Printing on X-terminals
Message-ID: <9007212057.AA01784@expire.lcs.mit.edu>
Date: 21 Jul 90 20:57:46 GMT
References: <13689@drilex.UUCP>
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
Lines: 22


    Guy Harris is right; others don't really know lpr.  The lpr protocol is
    basically a spooler-to-spooler protocol, not a user-to-printer protocol,
    nor a spooler-to-printer protocol.

That's fine.  I would say it has been used essentially as a user-to-spooler
protocol (that's roughly how I would characterize the way a Symbolics machine
uses it), and I'm not sure the calling end could really tell the difference
between taking a long time to spool and actually printing directly.  That's
may undoubtedly be stretching the original purpose of the protocol, but then
adding a printer extension to X would be stretching the X protocol. :-)

    However, there does seem to be a deficiency in the X regime: X provides
    a useful, standard means of displaying text and graphics on a computer
    screen.  However, if one wishes to render that same text and graphics
    in another environment, particularly hard copy, X provides no assistance.

Point well taken.  You can look at the Andrew system for one attempt to
deal with this issue.  Another answer is to use a higher-level graphics
package, like PHIGS or GKS, instead of directly using X graphics calls.
But I would argue that this issue is a client-side issue, not a server-side
issue.