Xref: utzoo comp.windows.x:31125 comp.lang.postscript:7161
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!ncar!noao!arizona!sunquest!bill
From: bill@sunquest.UUCP (Bill Raves)
Newsgroups: comp.windows.x,comp.lang.postscript
Subject: Postscript X server
Keywords: X server, Postscript
Message-ID: <12083@sunquest.UUCP>
Date: 3 Jan 91 20:56:00 GMT
Followup-To: comp.windows.x
Organization: Sunquest Information Systems, Tucson
Lines: 34

I think this subject has come up before but it seems to just dribble
away - it has to do with the feasibility of implementing an X server
that drives a Postscript device.  Some advantages:

  - a mechanism for suitably equipped clients to produce hardcopy
    documents as well as normal crt images
  - higher resolution
  - minimal client-side modifications

What are the potential problem areas?  Some that I can envision:

  - drawing primitives which assume a readable frame buffer
    (e.g. Copy{Area, Plane}, {Get, Put}Image)
  - mapping X fonts to Postscript fonts
  - mapping X rasterops to Postscript painting operators

Would you anticipate any problems with a server that has no input
devices or cursors?

How about a "window manager" that interacts with a print spooler,
breaks windows into numbered pages, dumps out page decorations?...

Does this sound feasible?
Has anyone attempted or is anyone attempting to do this?
Is this a good project to hire out (we have minimal X server,
Postscript experience) ?
----



-- 
Bill Raves				bill@sunquest.com
Sunquest Information Systems		sunquest!bill@arizona.edu
Tucson, AZ                              {arizona,uunet}!sunquest!bill