Skip to main content
Skip table of contents

Raster devices and setpagedevice

 This page applies to Harlequin v13.1r0 and later; both Harlequin Core and Harlequin MultiRIP.

Conceptually, painting operations in PostScript modify a raster. Which raster that is may change from time to time, either temporarily or permanently. (In practice, some of these rasters may not ever actually exist, or may not exist in their entirety at any one time, but the operations can still be thought of in this way.)

The setcachedevice and nulldevice operators both switch painting to another raster temporarily. setcachedevice is told how big to make a new raster for holding a rendered character in the font cache. nulldevice does not need size information because painting directed at its raster is simply discarded. The current raster device is a property of the graphics state so operators such as grestore, restore, and setgstate can revert to a previous raster when these temporary redirections are complete.

setpagedevice however, switches permanently to a new raster, even when the operand of setpagedevice is an empty dictionary. This is also true when grestore and the like change one page device for another; this does not revert to the previous raster but to a new one with the properties held in the restored graphics state. It is the contents of the page device rasters that are delivered to the %pagebuffer% i/o device when ready, at a showpage.

The setpagedevice operator combines its main function of switching rasters with that of setting the properties of the new raster. These properties are held in a dictionary, the page device dictionary, which can be examined in full using currentpagedevice.

setpagedevice takes one argument, a dictionary, which is just a modifier for the central page device dictionary. The entries in the operand dictionary can be regarded as requests for particular features or settings of the page device. The setpagedevice operator may grant these requests if it is able to, or ignore or reject them depending on how the page device dictionary is set up that is, on whether the appropriate entries exist, and what the Policies entry allows.

Using a dictionary makes the mechanism extendable, and the RIP takes full advantage of this capability. For example, Adobe does not specify a page device key which can change the raster format from monochromatic bitmap to varieties of continuous-tone color. However, for a system such as the Harlequin RIP where this property is configurable, it is clearly a property of the page device, so the RIP provides several keys to control this (see Configuring the page device).

The setpagedevice operator is complex, but has three main stages:

  • Merging the dictionary operand with the current page device dictionary - This means replacing the values in the page device with those taken from the operand dictionary where corresponding keys exist.
  • Media matching - What [RB2] calls InputAttributes is more recognizable as choices of paper tray or film cassette; similarly OutputAttributes represents choices of media delivery to sorting bins, or perhaps film developers and the like. The entries in the InputAttributes dictionary describe the “cassettes” by their properties, which, because these are also collected into dictionaries, are also extendable. The actual cassette is then selected by comparing the properties in the page device dictionary with the corresponding properties in the InputAttributes dictionaries and selecting the “best” fit in the manner described in [RB2]. OutputAttributes follows a similar process.
  • Raster initialization - This takes the properties and sets up an appropriate raster, clears it (with erasepage), sets up the graphics state, and so on. Because many of the properties of the page device are also required by the %pagebuffer% device, the RIP also passes on some of this information to the %pagebuffer% device at this point.

There are various ancillary operations such as handling what happens when keys are inappropriate (via the Policies entry), or changing the meaning of “best match” (see SensePageDevice in the following section).

JavaScript errors detected

Please note, these errors can depend on your browser setup.

If this problem persists, please contact our support.