Bug 688213 - setpagedevice does not have Level3 BeginPage behavior
setpagedevice does not have Level3 BeginPage behavior
Status: NOTIFIED WONTFIX
Product: Ghostscript
Classification: Unclassified
Component: PS Interpreter
7.07
PC NetBSD
: P3 normal
Assigned To: Ray Johnston
Bug traffic
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-07-15 19:04 PDT by Chapman Flack
Modified: 2014-02-17 04:41 PST (History)
1 user (show)

See Also:
Customer:
Word Size: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Chapman Flack 2005-07-15 19:04:16 PDT
Page 430 in PLRM3 provides:

  4. Calls the BeginPage procedure of the device being activated.
     At the time this call is made, the current device in the graphics
     state is the new one. Its count of previous showpage executions is
     reset to 0.

  With the exception of step 4 (which setpagedevice always performs), these
  actions occur only when switching from one page device to another.

PLRM2 only said (page 254) "The above actions occur only when switching from
a page device to a different page device (however, setpagedevice always calls
BeginPage)."

From PLRM2 it could at least be a defensible reading that setpagedevice could
sometimes call BeginPage without resetting the count to zero, but that is not
a possible reading of PLRM3 (since setpagedevice always performs all of
step 4).  Sure enough, on an Adobe level 3 interpreter:

PostScript(r) Version 3010.108
(c) Copyright 1984-1999 Adobe Systems Incorporated.
Typefaces (c) Copyright 1981 Linotype-Hell AG and/or its subsidiaries.
All Rights Reserved.
PS><</BeginPage{=}>>setpagedevice
0
PS>showpage
1
PS><<>>setpagedevice
0

but in ghostscript:

GNU Ghostscript 7.07 (2003-05-17)
Copyright (C) 2003 artofcode LLC, Benicia, CA.  All rights reserved.
This software comes with NO WARRANTY: see the file PUBLIC for details.
GS><</BeginPage{=}>>setpagedevice
0
GS>showpage
1
GS><<>>setpagedevice
1

I suppose this bug might depend partly on device-specific code, but I can
confirm it in gsnd and gs with x11 and x11alpha devices

An effect of this bug can be to cause utilities that use BeginPage/EndPage
for such purposes as n-up printing or page selection to give different
results in ghostscript than in PostScript.
Comment 1 Chapman Flack 2005-10-06 11:41:08 PDT
Just checked, this bug is present in AFPL Ghostscript 8.51.
Comment 2 Ray Johnston 2005-10-06 20:38:58 PDT
Even though Ghostscript is *NOT* compliant with the PLRM 3rd edition,
the compliant behaviour relies on "They do not occur when the current
device remains unchanged or when switching to or from devices of other
kinds, such as ..."

The vague description of "devices of other kinds" is problematic.

While this can be seen to interfere with N-up printing, this is not
a backwards compatible change and the compatibility with PS Level 2
printers is (as the bug reporter points out) not assured.

Thus, I (in my admittedly flawed wisdom), deem this to be a change that
we don't want to impose.

Instead, I propose that those that code BeginPage procedures to not
rely on this LL2 to LL3 indeterminate behaviour.

Note, Even though I am closing this bug, I am still "Assigned", so
any followup comment from the submitter or others will come to me
(even if the bug is not reopened).
Comment 3 Chapman Flack 2005-10-07 07:19:15 PDT
> the compliant behaviour relies on "They do not occur when the current
> device remains unchanged or when switching to or from devices of other
> kinds, such as ..."

I think more of that passage needs to be quoted:

 With the exception of step 4 (which setpagedevice always performs), these
 actions occur only when switching from one page device to another. They do not
 occur when the current device remains unchanged or when switching to or from
 devices of other kinds, such as the cache device or the null device set up by
 the setcachedevice or nulldevice operator. (PLRM3 p. 430)

"With the exception of step 4 (which setpagedevice always performs)" is not
a separable part of this passage. So, while

> The vague description of "devices of other kinds" is problematic

its vagueness does not extend to step 4, which is the central (and only) issue
to this bug.

> a backwards compatible change and the compatibility with PS Level 2
> printers is (as the bug reporter points out) not assured.

A worthwhile question (and I'm not asking rhetorically--I really don't know
the answer) would be, can anyone remember an example (other than ghostscript)
of a Level 2 implementation that matched ghostscript on this behavior? As the
language in PLRM2 can be read either way, it is possible that the new wording
in PLRM3 was just Adobe's way of saying more clearly what they had done all
along. I know there have been a number of printer and RIP brands with non-Adobe
PostScript compatible interpreters, and I've always assumed there were probably
fewer underlying implementations than brand names, but I don't have access to
any of those to play with. You guys have surely seen much more than I have; do
you know of Level 2 applications that behave this way?'

> Instead, I propose that those that code BeginPage procedures to not
> rely on this LL2 to LL3 indeterminate behaviour.

I am modifying PageNest to insulate programmers from this question by
discarding the interpreter's page count entirely and maintaining its own,
uniformly along strict PLRM3 lines. It will also provide a mechanism for
getting the ghostscript behavior, where that is wanted, also uniformly.
That should give programmers the predictability to allow them to write
programs. The issue affects not only n-up printing, but any application of
BeginPage/EndPage that looks at page numbers, such as page selection,
running header page numbering, and so on. Neither convention is terribly
difficult to work with, but when you don't know which one you'll get, code
can get ugly fast.

It turns out that my Adobe LL3 interpreter also calls EndPage even for a
bare <<>>setpagedevice, and ghostscript *does* match that behavior, even
though that's an example where PLRM3 vagueness really does come into play;
in case any future question comes up about that EndPage behavior I'll register
my vote in advance against changing that - not only because it currently
matches an Adobe implementation, but also because as it is now it provides
the only really decent way to code a workaround for the BeginPage difference,
so it is likely to be relied on.