(v13) The Imposition page device key
This page applies to Harlequin v13.1r0 and later; both Harlequin Core and Harlequin MultiRIP.
There is a problem in using BeginPage
and EndPage
as described in (v13) Positioning and printing pages using BeginPage and EndPage .
Consider the following:
%%BeginSetup
...
<< ... >> setpagedevice % (A)
...
%%EndSetup
%%Page: 1 1 save % (B)
... % do some graphics for page 1
showpage % (C) calls EndPage and BeginPage restore % (D)
%%Page: 2 2 save % (E)
... % graphics for page 2
showpage % (F) calls EndPage and BeginPage restore % (G)
This is typical of the way many real jobs are structured. The problem is that the transformations given in BeginPage
are immediately restored away, and those in force from the first setpagedevice
are reinstated. Therefore all the pages come out on top of each other. Beware of writing simple jobs to test imposition and related facilities: real jobs often do things such as this, which a simple test would not reveal.
To solve this problem, the Imposition
keyword has been added to the page device in the Harlequin RIP. When it is true
, any difference between the current matrix before and after the call to BeginPage
is recorded; this matrix is called the page base matrix. On a restore
or grestore
, the page base matrix in force at the corresponding save
is factored out of the current matrix, and the page base matrix in force inside the save
/restore
is reapplied. This has the effect of carrying over changes made in each BeginPage
to subsequent pages irrespective of save
and restore
.
For a job like the one at the beginning of this section, this works in practice as follows:
- The
setpagedevice
at (A) would set up the position for the first page by calling aBeginPage
procedure, implicitly setting the first page base matrix. - The
showpage
(C) would result in a further call toBeginPage
when the second page’s base matrix is computed. - Without
Imposition true
, therestore
at (D) would then reinstate the matrix as it was at thesave
(B) losing the effect of theBeginPage
at (C). Instead, however, the base matrix at (A)—the position information for the first page—is removed, and that from (C)—the position information for the second page—is inserted. - The process is repeated at the
restore
(G), which removes the second page’s positioning as it was at thesave
(E) and replaces it with the position applied in theBeginPage
executed during theshowpage
(F) for the third page, and so on.
Furthermore, when Imposition
is true
, setmatrix
and other relevant operators apply the page base matrix so that these operators cannot upset the imposition. From the job’s point of view, it is as if it is working on a single page with its origin at (0, 0) as normal. (Note the corollary to this: if a job tries to determine the resolution of the output device using the defaultmatrix
or idtransform
operators, and the imposed pages are scaled, the job reacts as if it is working at the resolution of the unscaled pages).
Therefore, for imposition to work as required, /Imposition true
must be set in a call to setpagedevice
:
<<
...
/BeginPage { ... } bind
/EndPage { ... } bind
/Imposition true
>> setpagedevice
If Imposition
is false
(the default), then transformations work exactly as described in [RB2].