Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!intercon!news
From: amanda@mermaid.intercon.com (Amanda Walker)
Newsgroups: comp.lang.postscript
Subject: Re: Printer state between pages
Message-ID: <1699@intercon.com>
Date: 9 Jan 90 19:53:51 GMT
References: <1990Jan8.195614.27489@Neon.Stanford.EDU> <17604@rpp386.cactus.org>
Sender: news@intercon.com
Reply-To: amanda@mermaid.intercon.com (Amanda Walker)
Lines: 26

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
I end up using gsave & grestore, it's to get around the fact that I can't save
a path away in a variable and then bring it back later to stroke or fill it.
This is one of the things that I love about Metafont, that PostScript does
clumsily at best, and I really feel this lack when trying to describe complex
glyphs in a font.  It would also be very useful for doing step-and-repeat
work for things that aren't straightforward linear tilings.  For some tilings
(i.e. those that parallelogram-shaped tiles), you can get by pretty well
by defining a font of tiles, much the way Adobe Illustrator does pattern
fills.  However, for anything less text-like, the only approach seems to
be to build an exectuable array with pathforall and execute it later.
Unless of course you want to draw strings as part of the tile...

Even if path objects were occasionally opaque in the same ways the current
path is (such as when character outlines are in the path), they'd still be 
very useful.

Tough to implement, though, especially without a better storage allocator
(the old persistent variable-size data structure problem again).

Amanda Walker
Speaker To PostScript
InterCon Systems Corporation
--