Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!decwrl!adobe!gelphman
From: gelphman@adobe.COM (David Gelphman)
Newsgroups: comp.lang.postscript
Subject: Re: Printer state between pages
Message-ID: <1596@adobe.UUCP>
Date: 10 Jan 90 00:12:34 GMT
References: <1990Jan8.195614.27489@Neon.Stanford.EDU> <17604@rpp386.cactus.org> <1699@intercon.com>
Reply-To: gelphman@adobe.UUCP (David Gelphman)
Organization: Adobe Systems Incorporated, Mountain View
Lines: 26

In article <1699@intercon.com> amanda@mermaid.intercon.com (Amanda Walker) writes:
>I'm usually not too annoyed at the strict stack behavior of gsave & grestore,
>but among the things that I would love to see in some future version of
>PostScript is the path as a first class data type.  In most of the cases that
...
   Two things in the PostScript language extensions contained in the
Display PostScript system help this particular situation. One is the
user path facility. Basically a user path is a procedure which contains
pure path construction (with optional caching) and can be passed directly
to operators like 'ustroke' and 'ufill' to stroke and fill a user path.
You can keep these objects around like normal procedure bodies and repeatedly
fill and/or stroke them. 
   A second facility is the gstate object. These are essentially an object
which is equivalent to the PostScript graphics state that can be used
to arbitrarily switch between graphics states (without concern about
the graphics state stack). It could be used to recover an already
constructed path had you saved away the gstate. Clearly the user path
machinery is more likely what you want since the graphics state contains
more state than what you wish to recover.
   These facilities are documented in the document "Extensions for the
Display PostScript System", available as part of a package from Adobe
of documentation on the Display PostScript system. 

>Amanda Walker
David Gelphman 
Adobe Systems Incorporated