STODOLA@FCCC.EDU (Bob Stodola) (07/12/90)
After reviewing the recent flurry of activity concerning printers attached to
x-terminals, I'd like to add a vote in favor of it. I think most of the
objections to it (at least based on the alternatives), assume that the norm
will be a workstation on every desk. In practice, I don't see this in the
near future. Looking at my own organization, there are many applications
that can and will benifit from the X user interface which will not justify
the cost of a workstation -- nursing stations, patient rooms (physician order
entry, etc.), accounting clerks, lab data entry stations. In practice, what
is required in this area is an inexpensive X-station (<$1000). Currently,
many such locations have terminals with printers attached, and the printer
is a required part of the package. Regardless of the "political soundness"
or lack thereof of including this in the X protocol, I see the cost of not
doing so to be very high. I can more easily write an application which
addresses the local printer through an already established X-server connection
than by identifying, opening, and addressing a separate path to a printer --
especially if the manufacturers of X-terminals all choose separate interfaces
to the local printer. Without quibbling over whether Xterm is itself a bug,
I have many VT100 terminal based programs which print through to the printer
port. Unless this issue is addressed as part of the standard, I don't see
being able to do this universally. Its very difficult to explain to someone
how much better the X-terminal is when it can't do something that they require
and are used to having.
The good news is that most of these locations already have serial lines strung
to them for printers. I don't view this as a permanent solution. :-)
Network printers are not a very good model for local printers -- it is typically
desireable to have them personally under the control of the current user
of the terminal. The same security concerns as access to the X-terminal itself!
What a coincidence! :-)
In short, I would plead for R5 to address this, regardless of philosophical
objections, simply to put an end to the various hacks being designed by
X-terminal manufacturers to address this much needed functionality.
Reply to:
stodola@fccc.edu Robert K. Stodola, Manager
Research Computing Services
Phone: (215) 728-3660 The Fox Chase Cancer Center
7701 Burholme Avenue
Philadelphia, PA 19111
USArws@EXPO.LCS.MIT.EDU (Bob Scheifler) (07/13/90)
Regardless of the "political soundness"
or lack thereof of including this in the X protocol, I see the cost of not
doing so to be very high.
No, you see the cost of not having a printing mechanism as high. I'll
agree with that assessment, but it is independent of whether the mechanism
is through an X protocol extension.
I can more easily write an application which addresses the local printer
through an already established X-server connection than by identifying,
opening, and addressing a separate path to a printer -- especially if the
manufacturers of X-terminals all choose separate interfaces to the local
printer.
You shouldn't waste your time writing an application. It should be possible
to use an existing network protocol (the one that lpr uses). You should be
able to use lpr.
Unless this issue is addressed as part of the standard, I don't see
being able to do this universally.
You are falling into the typical hole of "Gee, X has somebody who makes
standards, so let's take anything related to distributed computing and
call it part of X so we can get a standard." I'm exaggerating in your
particular case, but I do believe it is the same hole.
Its very difficult to explain to someone
how much better the X-terminal is when it can't do something that they
require and are used to having.
It's even more difficult to explain why existing mechanisms (like lpr) can't
be utilized. I have various systems here that don't run X but speak the
lp network protocol. I'd sure like to be able to print from them to the
printer attached to my X terminal.
Network printers are not a very good model for local printers -- it is
typically desireable to have them personally under the control of the
current user of the terminal.
That's fine, and there's no reason why it can't be done.
The same security concerns as access to the X-terminal itself!
What a coincidence! :-)
I have the same security concerns about the resources attached to the
workstation sitting on my desk, wherein my X server is executing, but
I don't think you would suggest that all access to them should be done
through an X extension in order to make the security "common".
In short, I would plead for R5 to address this, regardless of philosophical
objections, simply to put an end to the various hacks being designed by
X-terminal manufacturers to address this much needed functionality.
In short, I disagree.guy@auspex.auspex.com (Guy Harris) (07/15/90)
>You shouldn't waste your time writing an application. It should be possible >to use an existing network protocol (the one that lpr uses). You should be >able to use lpr. I don't know that "lpr" is necessarily the right choice - it may assume that the printer is willing to queue up lots of print jobs, but an X terminal may not want to do that (you might have some other protocol, with an "lpr" back end that talks the protocol)... ...but I'll definitely agree that X doesn't become the right choice just because the same piece of hardware to which you can attach the printer also happens to provide X services. > In short, I would plead for R5 to address this, regardless of philosophical > objections, simply to put an end to the various hacks being designed by > X-terminal manufacturers to address this much needed functionality. > >In short, I disagree. And I agree - with Robert Scheifler, not with the original poster. I don't see the "various hacks" being a fatal problem (almost said "terminal problem" :-)); printer port access on ordinary dumb terminals ain't standardized - different terminals have different escape sequences they use.
jcp@ciba-geigy.ch (Joseph C Pistritto) (07/17/90)
Just briefly, let me put in my 2 pfennigs worth in favor of some
mechanism in the X protocol to utilize manufacturer provided local
RS-232 connections attached to the X terminal.
I use X in a process control application, where the X terminal
may be located anywhere in a plant relative to where the server
is, and sometimes hundreds of meters away. The cost of running
distinct RS-232 out to each location is non-trivial, (I already
have the Ethernet strung everywhere for other reasons, so the
cost of using it is not high).
In many of our applications, there is ALWAYS a character printer
provided for every operator position, (for alarm messages, etc.),
so the RS232 from the X terminal is very handy. Certainly standardizing
the way of accessing it among manufacturers would be A Good Thing.
In addition to printing, by the way, the other handy application we
have is for doing RS-232 input, usually from authentication devices
like card or barcode readers. Once again, standardization, (and the
ability for 'standard programs' like xterm to be able to use the
device) would be handy.
-jcp-
--
Joseph C. Pistritto (bpistr@ciba-geigy.ch, jcp@brl.mil)
Ciba Geigy AG, R1241.1.01, Postfach CH4002, Basel, Switzerland
Tel: +41 61 697 6155 (work) +41 61 692 1728 (home) GMT+2hrs!dricejb@drilex.UUCP (Craig Jackson drilex1) (07/20/90)
About printing on X-Terminals:
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. People with things like Annex boxes
need additional software (output filters) which open up a net connection
and talk to the printer.
Point 1: The Internet community sure could use a standard spooler-to-printer
protocol. It could then be implemented by X terminals.
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.
Duplicate sets of code are required, one to call XDrawLine, etc, and
one to create Postscript, PCL, or whatever your printer's religion is.
On the Mac, all one needs to do is direct a graphport at the printer
instead of the screen, and Quickdraw is still the language.
Point 2: There should be some standard extension to the X windowing system
which would allow programs to use the same interface to create hardcopy
as they use to create screen images.
Note: I don't consider a screendump to be a real answer to the hardcopy
problem. Unless your bitmaps are routinely done at 2540 bits per inch
or greater, there are hardcopy devices with more resolution.
--
Craig Jackson
dricejb@drilex.dri.mgh.com
{bbn,axiom,redsox,atexnet,ka3ovk}!drilex!{dricej,dricejb}mouse@LARRY.MCRCIM.MCGILL.EDU (der Mouse) (07/21/90)
> 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. Only because nobody has implemented such a thing. There would be absolutely nothing wrong with providing an X server which has, say, display 0 being the CRT and display 10 using the page buffer for a laser printer, where display 10 supports an extension corresponding to PostScript's showpage operator. (I have a guess at how useful it would be. But my guess is irrelevant and likely wrong; a thousand guesses aren't worth one trying it and finding out.) > Point 2: There should be some standard extension to the X windowing > system which would allow programs to use the same interface to create > hardcopy as they use to create screen images. Using something like the above paradigm, all that'd be necessary would be one very simple extension (the showpage analog). The CRT display should probably have some indicator of the existence of the printer display. Maybe the extension could support three calls: (1) showpage, (2) get printer display number, and (3) get CRT display number. (1 and 3 would be useful on only the printer display, with 2 useful on only the CRT display, of course.) > Note: I don't consider a screendump to be a real answer to the > hardcopy problem. Unless your bitmaps are routinely done at 2540 > bits per inch or greater, there are hardcopy devices with more > resolution. Well, what I proposed above amounts to a screendump, but of a second screen. If the code is carefully written to use the resolution values from the two screens, everything should work just fine. (Not much current code does this because present resolution values are nearly worthless; this would obviously have to be fixed for the above to be very useful.) der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu
rws@EXPO.LCS.MIT.EDU (Bob Scheifler) (07/22/90)
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.dricejb@drilex.dri.mgh.COM (Craig Jackson drilex1) (07/22/90)
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}
rws@EXPO.LCS.MIT.EDU (Bob Scheifler) (07/23/90)
Der Mouse mentioned a second 'screen' which is a printer,
at a different resolution, as a possible server-side solution.
Not really a very good solution, in my opinion.