🚀 go-pugleaf

A number of people have responded to my question about showpage-layering, 
both via news and via mail.  In article <1990Aug15.163702.15828@wrl.dec.com>, 
heiney@wsl.dec.com (Bob Heiney) wrote:

> Thus, the original poster can see that his software *ought* to work.
> If only every file that claimed to be well-behaved actually was.
 
and he quoted version 2.1 of Adobe's Document Structuring Conventions 

> 	If the showpage operator is used with save and restore, the
> 	showpage operator shall occur after the page-level restore
> 	operation.  The motivation for this is to be able to handily
> 	redefine the showpage operator to have side effects in the
> 	printer VM such as maintaining page counts for printing n-up
> 	copies on a single sheet of paper.  

An interesting point was made in an e-mail response that I received from
James Clark <uupsi!relay.EU.net!jclark!jjc>

> I tried your code with two drivers I have written (dvitops and groff),
> and it worked fine with both.  But I had this sort of showpage-layering 
> in mind when I wrote them.
> 
> The document structuring conventions (version 2.1) specifically forbid
> enclosing showpage within save/restore; but I can't find anything that
> forbids enclosing it with gsave/grestore.

The reason he mentioned gsave/grestore, is that I'd used gsave and grestore 
in order to obtain (at the end of the page I wanted to skip) the clippath 
that had been in effect (at the start of that page).  In fact, in one of 
the cases where my routine broke, it was because the program generating the 
PostScript document had enclosed showpages within gsave-grestore pairs!
[I guess I could make the usually-true assumption that clippaths will be
rectangles and save the bounding box values at `start of page', but it
feels kludgy.]

Incidentally, James Clark also pointed something out to me that I thought I
should pass along:

> I think the technique of writing a dictionary into a procedure after
> definining it is no longer thought to be advisable because it doesn't
> work when setpacking is true.

A number of other people responded with helpful suggestions about getting
around specific problems.  For example, Brian Thomson <thomson@hub.toronto.edu>
suggested a clever trick to preserve variables across a restore:

> eg. if you want to save the value of "x" across a restore,
> 
> /restore { x exch restore /x exch def } bind def

Of course, this makes a lot of assumptions about the environment, such as
you've chosen a unique name `x' that will not conflict with any body else's.

I would like to thank all who responded, both in news and mail.
-- 
Bob Tinkelman, Cambridge Computer Associates, Inc., 212-425-5830              
bob@camb.com  or ...!{uupsi,uunet}!camb.com!bob