🚀 go-pugleaf

In article <1517@tukki.jyu.fi>, sakkinen@tukki.jyu.fi (Markku Sakkinen)
writes:
> However, PostScript code generated by text processors and similar
> application software should be very well-behaving.
> Indeed, if it conforms to the structuring conventions recommended
> by Adobe, such things as the number of pages are given in special
> comments at the beginning or end of the file.

Specifically, you can look for the "%%Pages:" structure comment. (This
is what we do locally, and output it as "Pages expected" in an operator
message.) Note, however, that it is not mandatory under the structuring
conventions to have this structure comment. (It is only mandatory that
if it occurs it is correct... or in other words if it is wrong the
document is non-conforming... bad luck!)

Certainly any approach based on a naive search for "showpage" will get
you nowhere, in practice as well as in theory.

However, the situation for knowing how many pages a document *did*, in
fact, print is rather better, and doesn't need the patch that Geoff
Cooper posted. The "pagecount" operator in "statusdict" (see page 296
of the Red Book) gives you the number of pages ever printed by the
LaserWriter (or since the last time the EEROM was replaced, anyway).
You can take the difference of its value at the start and end of a job,
and print the difference in an operator message, or on a cover page.

The determined user will be able to cheat even on this unless you
execute both examinations of the page count in nice, clean, start of
job, PostScript environments. This requires keeping the initial value
external to the LaserWriter. (Or perhaps Geoff can work out for us how
to keep it in a protected, exitserver-installed, piece of workspace
that survives between jobs!)

Chris Thompson
JANET:    cet1@uk.ac.cam.phx
Internet: cet1%phx.cam.ac.uk@nsfnet-relay.ac.uk