Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!uunet!intercon!news
From: amanda@mermaid.intercon.com (Amanda Walker)
Newsgroups: comp.lang.postscript
Subject: Re: Printer state between pages
Message-ID: <1695@intercon.com>
Date: 9 Jan 90 01:44:35 GMT
References: <1990Jan8.195614.27489@Neon.Stanford.EDU>
Sender: news@intercon.com
Reply-To: amanda@mermaid.intercon.com (Amanda Walker)
Lines: 59

In article <1990Jan8.195614.27489@Neon.Stanford.EDU>, rokicki@Neon.Stanford.EDU
(Tomas G. Rokicki) writes:
> 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.

I'd agree, almost.  In particular, I believe that the document setup should
be considered to be effectively part of the prolog (at least, as far as the
state at the beginning of the page is concerned), since by its nature it does
things that affect the global state (paper size, etc.).

However, it is also very much a part of the Document Structuring Conventions
that there can be *no* persistent state from page to page.  Each page should
be thought of as sitting inside a save/restore pair.

> Consider the following program.
> 
> ...
> %%EndProlog
> %%BeginSetup
> 2 2 scale
> %%EndSetup
> %%Page 1
> ... gsave showpage grestore
> %%Page 2
> ... gsave showpage grestore
> %%Trailer

The '...'s are evil :-) if they change the global graphics state at all.

> 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.

Well, inclusion of multi-page documents is a problem.  Aside from that,
however, how about doing a 'save' after the setup, and a 'restore save'
before each page?  That way, any transformations the new showpage does
are automatically added to the ones that the setup did.  I have in fact
used this very technique:  I have a version of "showpage" that prints
two-up with cut and fols marks.  The setup code tests to see if 11x17
paper is available, and if not it translates, rotates, and scales so 
that you get both pages (somewhat reduced) on a landscape-oriented letter
size page.  The 'showpage' doesn't care, since all of its transformations
are additive.  Ordering of setup code does become a problem, however,
unless each program that manipulates the PostScript file also produces
a completely conforming file as output (which I think should indeed happen).
Not always easy, though...

Amanda Walker
InterCon Systems Corporation
--