Raster scaling and orientation

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

Before methods documented in the next section determine the page size, use various keys to adjust both the size and orientation of the page and its contents.

Scaling

Scaling is a two-entry array that gives x- and y-scale factors to be applied to the raster. [1 1] means no change to the scale.

For example, the following causes pages to be produced that are 1% larger than the job being run is asking for:

<< /Scaling [1.01 1.01] >> setpagedevice

The Scaling parameter changes the size of the raster, and scales objects on the page accordingly. It does not change the resolution; in particular, the resolution and frequency of device-dependent artifacts such as halftone screens is unaltered. It differs from using the scale operator in, say, BeginPage, or changing the default matrix with Install, as these operations do not change the size of the raster. Scaling might be used to make small adjustments to compensate for film shrinkage, for example, or with large factors to produce poster versions of a page.

The use of Scaling affects any attempt by the PostScript-language code in the job to discover the resolution of the output device using the dtransform or idtransform operators. Also, the effect on some pixel-based thresholds, such as the HintedFonts system parameter, may mean that details of the output can change in small ways when scaled.

The use of Scaling in conjunction with imposition is also illustrated in The imposition mechanism, where a Scaling factor is used in one direction to produce a raster which will accommodate more than one copy or color separation of a page. In that case, the scale operator is used to reverse the effect of the scaling of the contents so that the end result is just a scaling of the raster size.

Orientation and ExtraOrientation

The PostScript-language page device key Orientation is described in [RB3]. The numbers 0, 1, 2, and 3 rotate the page and its contents through those multiples of 90° (counter-clockwise).

The equivalent control in PDF files is the Rotate key in a page object (except that Rotate is specified in degrees and must be an integer multiple of 90° and rotates clockwise instead of counter-clockwise). When processing a PDF file, the value of Rotate for the current page is represented in the page device with an appropriate value of Orientation.

The ExtraOrientation Harlequin extension page device key is very similar to Orientation, in that it specifies a counter-clockwise rotation as an integer that must be multiplied by 90°. The effect of Orientation and ExtraOrientation is cumulative (that is, the two numbers are added together). But ExtraOrientation differs significantly in how it’s applied. A value specified for Orientation in the page device is overwritten by a value of Orientation in a PostScript file, or by Rotate in a PDF file. But ExtraOrientation would only be overwritten by code explicitly written for Harlequin, which means it won’t be overwritten by a normal job.

This means that OEM code should normally only set ExtraOrientation, as that applies a rotation relative to how the page was displayed in any reasonable PDF viewer, which has already taken Rotate into account.

However, Orientation and ExtraOrientation may be overridden by the effects of TimeSaving or FilmSaving, as shown below.

Note the interaction with the OneWayMedium key described above. If we have:

            <<
            /OneWayMedium false
            /PageSize [600 500]
            /Orientation 1
            /InputAttributes <<
              0 << /PageSize [500 600] >>
            >>
            >> setpagedevice

then the attribute is matched in the rotated orientation, and then further reoriented by Orientation. However, if this example had set /OneWayMedium to true instead of false (as below), it would have failed to match the page size because only the original order of PageSize elements is considered, and the attribute is selected by relaxing the matching constraints as described in [RB2]. Then Orientation is applied, which gives a ninety-degree difference between the two cases:

            <<
            /OneWayMedium true
            /PageSize [600 500]
            /Orientation 1
            /InputAttributes <<
              0 << /PageSize [500 600] >>
            >>
            >> setpagedevice

XFeed: Page orientation vs. media orientation

XFeed is a boolean page device parameter (that is, a RIP extension) which when true indicates that media is fed through the printer at right angles to the slow-scan direction of the imaging process; when false (or not present), it is parallel to the slow-scan direction. It was introduced to provide added support for drum-type printers.

The XFeed key automatically sets to true in the GUI version for those plugins that set deviceType appropriately in the DeviceCapabilities structure in their C language code. Set other implementations to XFeed explicitly when driving x-fed devices.

Some confusion about orientations and coordinate systems occurs when considering drum printers because of where you stand when you look at such a machine.

By definition, a raster is arranged so that pixels within each scanline (row in the x direction) are contiguous in memory. Viewed as a 2-D array, the column indices (x coordinates) vary fastest. The x-axis is arranged so that it aligns with the fast-scan direction of the printing technology (typically a laser deflected by a rotating prism) and the y-axis with the slow scan direction (typically controlled by stepper-motors or a rotating cylinder or screw). For output to a window, the x-axis of the display is aligned with the x-axis of the raster. It is rare to find a printer for which there is no “natural” alignment for the raster.

The PostScript-language default matrix applies whatever mirroring and rotation is necessary to map the device-independent PostScript-language user space into this device-dependent coordinate system, as well as scaling to account for resolution. Most rasters are imaged starting from the top and from left to right with respect to the original page (a left-handed cartesian system), so the typical default matrix causes a mirroring about the x-axis (user space is defined as a right-handed Cartesian system).

Where continuous media is used, the roll may be aligned so that it feeds media either:

• relative to the y-direction of the raster the slow-scan direction of the printer typical of capstan-type printers; or
• relative to the x-direction of the raster the fast-scan direction of the printer typical of drum-type printers. This class of printers is said to be x-fed, or side-fed. For x-fed printers therefore, media width corresponds to the height of the raster (its y-dimension), and media length corresponds to the raster width (x- dimension), because the media is oriented at right angles to the raster.

However, the problem is compounded because physical imaging engines are nearly always seen from the direction of the media feed. For capstan printers, this is the same orientation as the raster; however, for drum devices, the top of the raster is usually at the left side of the machine and the x-axis runs around the circumference of the drum.

Except when discussing media orientation, all the orientations referred to here are with respect to the raster, not the media or the direction from which the machine is viewed. So “side” in “side-fed” means the side of the raster, which for a drum device means what appears at the side if you stand at the end of the machine and look along the drum.

Occasionally, manufacturers reverse the usual notation by labeling the slow-scan direction x and the fast-scan direction y, so be sure you always know which is which.

FilmSaving and TimeSaving

The FilmSaving page device key allows for reorienting the page to make best use of continuous media; TimeSaving makes best use of imaging speed on x-fed devices.

Where media is fed from a roll, the width of the media is fixed but the length is variable. Where the feed direction is the same as the slow-scan imaging direction (parallel to the y-axis), typical of capstan devices, in principle the page length is usually limited only by the length of the roll, but for side-fed devices (/XFeed true), typical of drums, there is usually a maximum length of media for any page, imposed by the circumference of the drum.

In both these cases you can use less media if the longer side of the page to be imaged fits across the width of the media. If FilmSaving is true, then the page is rotated if necessary to align its longer side with the media if it fits. If the page is already aligned this way, or if it doesn't fit, it is left in its original orientation (even if the Orientation and ExtraOrientation keys suggest that it should be rotated). If FilmSaving is false, the test is not carried out.

An interaction occurs here with the system parameter ScreenRotate (see ScreenRotate (system param)). If rotation occurs, then if ScreenRotate is true, any halftone screens applied to the page rotate too. This is normally unnecessary, so the default for ScreenRotate is false, but if some separations are rotated and others are not (which implies the page sizes for each are different, which is unusual), the screen angles would be incorrect relative to each other.

Also note that “alignment with the media” has the opposite sense when dealing with x-fed devices. A portrait-oriented page is rotated (if it fits) on a capstan device, but the same page would not on a drum printer. Conversely a landscape page requires rotation to make best use of media in a drum device, but is already correctly aligned for a capstan. Some drum printers require a full sheet every time, either because the media is inserted from a stack of cut sheets, or because the mechanical systems cannot deal with arbitrary lengths cut from a roll; desktop printers are also typically fed-cut sheets, though some work from a roll or fan-folded stock. Where fixed size sheets are used, FilmSaving actually achieves no saving, though the rotation is still applied as described.

When media is fed from the side, it is also possible to optimize for time instead of media by rotating the page. This rotation is applied if appropriate when both TimeSaving and XFeed are true; TimeSaving has no effect for y-fed devices. For a capstan-type printer, the slow-scan direction coincides with the media feed direction, so the less media is imaged, the faster the result. On drum-type devices, however, the time taken to image depends on the length of the page, so a portrait page takes longer to image than a landscape one. Therefore the page is rotated when TimeSaving is requested if its long side fits along the media (subject to its maximum length where the length is variable), in the y direction.

If FilmSaving, TimeSaving and XFeed are all true, then TimeSaving takes precedence over FilmSaving.

The diagram shows how pages are output with the various configurations. The raster to be imaged is shown in gray. The media used is shown as a white box. The maximum imageable area is shown as a black shadow. Note that y-fed devices have a fixed media width, while x-fed devices have a fixed media height.

ImagingBBox, TileDeviceBBox

ImagingBBox is a standard page device key that takes as its value an array of four numbers [x1, y1, x2, y2], identifying the corners of a bounding box in the default coordinate space of the page outside, which the PostScript-language job is claiming no marks appear (or at least none that are of interest). TileDeviceBBox is another bounding box, specified as an array of four numbers in the device space of the output raster. It is applied after all other transformations and the ImagingBBox restriction. The Harlequin RIP interprets ImagingBBox by producing a raster which is formed from the intersection of the page size, as determined by all the other page device keys, with the bounding box given by ImagingBBox.

It then corrects for the bottom left of the raster in general no longer coinciding with the user-space origin by:

• inserting an appropriate translation component into the default matrix, and
• increasing the margins settings

The default clipping area is set to the boundaries of the raster, which is illustrated:

The area identified by ImagingBBox is affected by media auto-rotation and fitting, Orientation, MirrorPrint, Scaling, and PDF's UserUnit.

ImagingBBox never enlarges the raster; it may only restrict the area rendered; you may need to deliberately set a PageSize that encapsulated the ImagingBBox when setting it.

TileDeviceBBox is an additional restriction applied to the output raster after all other transformations and after ImagingBBox. TileDeviceBBox is specified in the device space of the output raster after all other transformations and the ImagingBBox restriction. TileDeviceBBox never enlarges the raster; it may only restrict the area rendered.

ImagingBBox and TileDeviceBBox set the PageRelativeBBox pagebuffer parameter (present in HHR's RasterDescription as the pageRelativeBBox array) to the offsets from the output raster to the media raster boundary (as defined by RasterBBox, RasterDeviceBBox, or the default media size). This allows raster backends to determine where on the page a particular output raster tile was located. The relationship between the bounding boxes, margins, and output raster size are shown in the following diagram:

You may use RasterBBox/RasterDeviceBBox, ImagingBBox, and TileDeviceBBox together.

TrimPage

The TrimPage page device key is a RIP extension that takes a boolean value. When true, it permits the Harlequin RIP to ignore unused space at the top and bottom of the raster (white space for positives and black space for negatives). Unused space is calculated in whole bands (and so has little or no effect at lower resolutions). It is determined for all separations at once when automatically separating (so the area omitted is the intersection of the unused space at the top and bottom of all the separations).

The effect is not to image the unused areas, thereby saving media (for y-fed printers) or time (for x-fed printers). This does have a visual effect on the final output: it moves it up the page, which is the original reason for implementing. The missing bands are identified to the core-RIP skin and to GUI version plugins by the parameters TrimStart and TrimEnd in the %pagebuffer% device and the pageHeader C data structure, respectively).

The TrimPage page device key cannot be used with the ResamplingFactor page device key.