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.
Just checked, this bug is present in AFPL Ghostscript 8.51.
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).
> 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.