Path: utzoo!mnetor!tmsoft!torsqnt!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!snorkelwacker!bloom-beacon!LARRY.MCRCIM.MCGILL.EDU!mouse
From: mouse@LARRY.MCRCIM.MCGILL.EDU (der Mouse)
Newsgroups: comp.windows.x
Subject: Re: Printing on X-terminals
Message-ID: <9007210504.AA09950@Larry.McRCIM.McGill.EDU>
Date: 21 Jul 90 05:04:19 GMT
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
Lines: 41

> 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