shyam@atc1.UUCP (Shyam Mittur) (09/05/90)
Does anybody know of a strategy to obtain hardcopy from X clients that is not restricted to the server's display resolution? For example, I would like to preview an X-Y plot on a window and then get hardcopy from a 300 dpi PostScript printer, without being restricted to 75 or 100 dpi on the printer. If there is enough interest, I will post a summary of the responses. Thanks, SHYAM MITTUR
poser@csli.Stanford.EDU (Bill Poser) (09/06/90)
In article <103@atc1.UUCP> shyam@atc1.UUCP (Shyam Mittur) writes: > >Does anybody know of a strategy to obtain hardcopy from X clients that is >not restricted to the server's display resolution? For example, I would like >to preview an X-Y plot on a window and then get hardcopy from a 300 dpi >PostScript printer, without being restricted to 75 or 100 dpi on the printer. For arbitrary clients this is impossible in principle because they may be drawing individual pixels. Only if they were restricted to drawing higher-level objects (e.g. lines) would there be a possibility of finding out what objects they were drawing and redrawing them for hardcopy at higher resolution. Of course, individual applications can often generate hardcopy at better than monitor resolution, because they may have available the abstract representation of the image. For example, my time-series editor produces window dumps that look better than screen dumps because I redraw the image from the internal representation in Postscript or PIC.
fgreco@govt.shearson.COM (Frank Greco) (09/06/90)
>Does anybody know of a strategy to obtain hardcopy from X clients that is >not restricted to the server's display resolution? For example, I would like >to preview an X-Y plot on a window and then get hardcopy from a 300 dpi >PostScript printer, without being restricted to 75 or 100 dpi on the printer. > >SHYAM MITTUR Most 3rd party and public domain plotting programs have Postscript support so its a no-brainer if thats the case. If you are writing your own routines, you typically have some sort of data structure that describes the things you're plotting (e.g., a display list). In your repaint proc, you traverse your data structure and call the appropriate Xlib routines to display things. So if you wanted to produce PostScript, then "all you have to do" is, when you're traversing your data structure(s), produce PostScript calls instead. For the most part, the requisite Xlib calls for a plotting program map pretty well to PostScript calls (being vector-based), so it shouldn't be that much of a headache. If you're going to use fonts for labeling axes and things....you're probably not going to get a perfect duplicate of your screen, but it should be close if you make some careful decisions on screen-fonts v.s. Postscript fonts. ----- Frank G. Of course, you could use NeWS and not even think about this problem. +-----------------------------------+-----------------------------------+ |On Assignment at: |Office: | | Shearson Lehman Brothers | Crossroads Technologies, Inc. | | World Financial Center, 11th Floor| PO Box 530 | | New York City, NY 10285 | Fanwood, NJ 07023 | | email: fgreco@shearson.com | email: frank5@mars.njit.edu | | voice: (212) 528-6122 | voice: (201)-754-7820 | +-----------------------------------+-----------------------------------+ My comments reflect my own opinions, not my clients.
janssen@parc.xerox.com (Bill Janssen) (09/07/90)
In article <103@atc1.UUCP> shyam@atc1.UUCP (Shyam Mittur) writes:
Does anybody know of a strategy to obtain hardcopy from X clients that is
not restricted to the server's display resolution? For example, I would like
Sure. Have the client generate different formats for different
output devices. For example, the Andrew zip drawing editor draws
with pixels on the X Window System screen, but outputs PostScript
for the printer. Frame's FrameMaker does this as well.
(Why do I think this wasn't the real question?)
Bill
--
Bill Janssen janssen@parc.xerox.com (415) 494-4763
Xerox Palo Alto Research Center
3333 Coyote Hill Road, Palo Alto, California 94304razdan@phx.mcd.mot.com (anshuman razdan) (09/08/90)
In article <JANSSEN.90Sep6162652@holmes.parc.xerox.com> writes: In article <103@atc1.UUCP> shyam@atc1.UUCP (Shyam Mittur) writes: Does anybody know of a strategy to obtain hardcopy from X clients that is not restricted to the server's display resolution? For example, I would like Sure. Have the client generate different formats for different output devices. For example, the Andrew zip drawing editor draws with pixels on the X Window System screen, but outputs PostScript for the printer. Frame's FrameMaker does this as well. (Why do I think this wasn't the real question?) if Shyam is looking for a "wonder tool" that automatically generates Postscript(or such) for the image on the screen, there exists none to my knowledge. Ofcourse xdpr etc... are avialable but there is no control over the resolution or filtering of the image/drawing. The best bet is to generate the Postscript code by the application. It is only possible, ofcourse, if the application knows how to redraw the contents of the window(which a good application should anyways). One great advantage is that the application has control over what it ouputs on the printer and I mean not just resolution wise. One of the problems that I ran into was resolving the issue of color. The lighter(??) colors get converted to white and darker colors to black (for regular b/w printeres). The application may want to have the control over this. Also, since color printers are becoming more and more common(read popular) and considering most graphics application have bigger on the user if color is splashed all over( I do not want to start a color vs monochrome war though), the application should have control over generating postscript for color printers and yet be able to service b/w printers. What I did and it certainly is not the best way (I did not know of a better then or now) is write C routines that generate postscript code and then I ship the file to the printer. But every application has different needs so.....unless (somebody thinks I did not understand the question like Janssen) -- Anshuman Razdan ************************************************************ * razdan@toy Test and Methodology Group * * * * razdan@phx.mcd.mot.com Diablo Plant, Tempe Az * ************************************************************
shyam@atc1.UUCP (Shyam Mittur) (09/19/90)
A couple of weeks ago, I posted the following query: ----------------------------------------------------------------------------- >Does anybody know of a strategy to obtain hardcopy from X clients that is >not restricted to the server's display resolution? For example, I would like >to preview an X-Y plot on a window and then get hardcopy from a 300 dpi >PostScript printer, without being restricted to 75 or 100 dpi on the printer. ----------------------------------------------------------------------------- I received six responses, four of them by E-Mail and two as return postings. I have replied individually to those who sent me E-Mail, this is a summary. My conclusion is that there is no such "strategy". Perhaps this situation has not been faced by most people yet, I think it will become an issue once more "real-world" applications start working with X. It appears that my use of PostScript as an example misled people from the crux of the problem. I should have mentioned something like a drum plotter. Of the responses I received, all except one assumed the problem is restricted to PostScript. This is not so. Most of the responses suggested rewriting the client to call external routines, or generate PostScript, but this is not an option here. A good example to illustrate the situation is the Xload client. Let's say I have Xload running on a display, and at some point, I decide I would like to get hardcopy of the load plot for the next three hours on an attached Calcomp plotter (1/1000 inch resolution - "I paid for it, I want to use it!" syndrome). I can see no way of doing this, short of rewriting Xload, which may not be feasible. As an aside, I get the impression from the traffic in this newsgroup that most developers working in X assume PostScript when hardcopy is mentioned. Am I mistaken, or is this because most developers have a PostScript printer next to their workstation and are still busy developing "nifty" clients? I would like to thank everybody who responded. SHYAM MITTUR ATC Laguna Hills, CA
mouse@SHAMASH.MCRCIM.MCGILL.EDU (der Mouse) (09/20/90)
> As an aside, I get the impression from the traffic in this newsgroup > that most developers working in X assume PostScript when hardcopy is > mentioned. This is not restricted to X. Far too many people seem to assume that "oh, you want hardcopy, no problem, it generates PostScript". Not only that, but far too many programs (and presumably the people behind them) assume that if it prints on *their* PostScript-based printer, it's good enough to ship. Witness the example we had in xpert some time ago, when someone put up some documentation for ftp in PS form, but the PS file used the banddevice (or was it framedevice?) operator explicitly. This operator is documented in the Red Book as being device-specific and not even guaranteed to exist, yet this silly whateveritwas-to-PostScript program was generating it. All you developers, >>>> HARDCOPY != POSTSCRIPT <<<< >>>> POSTSCRIPT != AUTOMATIC DEVICE INDEPENDENCE <<<< Please try to isolate the printer interface so we can plug in a module that speaks Impress, or HP-GL, or whatever else we happen to have a printer that understands.... der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu (Thank you for putting up with this only-vaguely-X-related polemic. We now return you to your X discussion in progress.)