🚀 go-pugleaf

Excerpts from internet.other.info-andrew: 10-Nov-92 Re: Printers
Garrett.Wollman@UVM.EDU (1049)

> <<On Tue, 10 Nov 1992 07:44:55 -0600 (CST), Todd Inglett
> <tinglett+@rchland.ibm.com> said:

> > I think a class similar to graphic (subclass of graphic) to render
> > postscript would result in the biggest short term win. 

> This should actually be a fairly quick hack, if you are willing to
depend on ghostscript.

I think you've slightly misunderstood the proposal (though what you say
is correct given the misunderstanding.)

I believe the concept Todd Inglett is speaking of is that there be
another subclass of graphic (and probably view) which would allow any
existing ATK view to be printed simply by inserting it under a special
view, and requesting a full update.  The result of which would be a
batch of postscript for drawing the view.  This will probably be part of
the system if we do go through with direct postscript printing.

Excerpts from internet.other.info-andrew: 10-Nov-92 Re: Printers
Garrett.Wollman@UVM.EDU (1049)

> Just create a pixmap or window on the X server, and set the enviornment
> variable GHOSTVIEW to be either the window ID, or the window ID and the
> pixmap ID.  Then fire up ghostscript with the PostScript code as
> standard input, and away we go.

I actually had the quick hack done once, unfortunately I was not
satisfied with the requirement that I have one gs process per ps inset
(also the ability to tell gs what area of the window to use would be a
big help).  I've been meaning to send the Ghostscript folks my wish list
for awhile now...  (Another approach would be to have gs use it's
backing pixmap, and never map it's window..., then just xcopyare from
it's pixmap onto the view.)  Unfortunately all of this violates the
concept of window system independence.  (It could be preserved if we
used the pbm device, but that would mean putting the images out over the
wire to the X or WM server.)

-Rob