🚀 go-pugleaf

Thanks, Brian, for your comments; I agree.

And now for something completely different.

The structuring conventions separate a document into four sections
(for the purpose of this discussion):  prolog, setup, pages, and
trailer.  A lot of programs rearrange pages to do 2-up and the like
by assuming the state between pages is the same as the state before
the prolog.  I claim this is incorrect, and indeed these programs
should look at not the original state, or the state between pages,
but the changes between the two (there is a matrix divide in PostScript,
right?) to perform there magic.

Consider the following program.

...
%%EndProlog
%%BeginSetup
2 2 scale
%%EndSetup
%%Page 1
... gsave showpage grestore
%%Page 2
... gsave showpage grestore
%%Trailer

The graphics state at the beginning is completely unknown (this file,
or a subset, might be included and scaled, rotated, etc.)  The setup
can completely alter the state, and gsave/grestore can be used to
maintain that state across page boundaries.

Thus, a program that attempts to 2-up this document cannot simply
redefine the `showpage' operator, as there could be any number of
(including zero) gsave/grestore pairs around showpage.  Rather,
the 2-up program needs to store away the initial state somewhere.
Then, after setup, it needs to divide the new state by the initial
state, and save this information away for its later use.  Each
`transformation' it wants to make must then be divided by this
new matrix we created before it is applied.

Why do I bring all this up?  With the large number of PostScript
clones, previewers, and manipulators being released, issues such
as these must be clearly stated and carefully dealt with.  Most
PostScript previewers and manipulators make completely invalid
assumptions that cause problems with correctly-written PostScript.

Comments?

-tom