Path: utzoo!mnetor!tmsoft!torsqnt!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!tut.cis.ohio-state.edu!snorkelwacker!bloom-beacon!drilex.dri.mgh.COM!dricejb
From: dricejb@drilex.dri.mgh.COM (Craig Jackson drilex1)
Newsgroups: comp.windows.x
Subject: Re: Printing on X-terminals
Message-ID: <9007221422.AA25681@drilex.DRI.MGH.COM>
Date: 22 Jul 90 14:22:38 GMT
References: <9007212057.AA01784@expire.lcs.mit.edu>
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
Lines: 45

Bob Scheifler said:
>I said:
>> 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. :-)

It's not too hard to think of using lpr as a user-to-spooler protocol; the 
user task needs simply to take over some of the function of the originating
spooler.  It might be possible to twist this into a spooler-to-printer
protocol, as well; I don't know it that well.  

I don't think that the printer protocol should be part of the basic X
protocol.  It should be sufficient either to recommend a standard auxiliary-
device protocol, or *perhaps* to add sort of 'external device control'
extension to the basic X protocol.  This is really for the IETF to
solve in conjunction with the research & development community.  However,
I'm sure that some leadership from the Consortium would accelerate things.

>> 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.

I don't think the argument is 100% either way; I can conceive of several
implementations.  (Der Mouse mentioned a second 'screen' which is a printer,
at a different resolution, as a possible server-side solution.)  Once
again, this is an area which needs leadership & direction in its resolution.

-- 
Craig Jackson
dricejb@drilex.dri.mgh.com
{bbn,axiom,redsox,atexnet,ka3ovk}!drilex!{dricej,dricejb}