PostScript Device Plugins

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

PSDEV plugins provide the means to implement dynamically linkable implementations of PostScript language i/o devices. These are briefly described in [RB3] in Section 3.8.

Such a device is created using the PostScript language (using the devmount operator) and then linked up to the appropriate device type implementation (using the setdevparams operator). It is referred to in filenames and in the device manipulation operators (typically starting dev ...) enclosed in percent signs, as in %myowndevice% .

Postscript language calls to manipulate files opened on the device are then be routed to functions defined in a DEVICETYPE structure for the device type related to the device.

The SDK includes two examples of PostScript Device plugins, a simple “ram disk” and a raster reader/writer.

The plugin selector mechanism is only used for housekeeping and to provide this structure of function pointers and related information. Once provided to the RIP in response to the appropriate selector call, further interfacing is only by means of the functions in the DEVICETYPE structure. The plugin can publish more than one DEVICETYPE structure, so that multiple device types can be implemented within the same plugin.

Streamed data (whether incoming or outgoing, or as in the case of a filter, both) can and should be implemented using an input plugin.

On the other hand, PSDEV plugins offer a more direct interface with the RIP, especially in respect of synchronicity of calls. In fact, input plugins are implemented by a DEVICETYPE that hosts the plugin and provides buffering support, asynchronicity, and so on. The Harlequin Core SDK exposes the same DEVICETYPE interface as the only means of adding i/o functionality, as it does not support plugins at all.

However, the main purpose of a PSDEV plugin in the Harlequin MultiRIP is to be able to replace built‐in devices. In particular, the header and data of a pagebuffer file ‐ the file on disk used by the Output Controller to store pages, which can also be redirected externally ‐ is read from a device called %pgb% . If the device type for this device is replaced by another, so long as the same information is provided, the method of storing the raster data can be entirely different.

It is possible, for example, to use standard TIFF files in place of pagebuffer files (providing the extra information about target output plugins and their parameters is synthesized or sorted somehow). It is also possible to store the data on some different medium, for example a database. The DEVICETYPE may also be used as a more intelligent pipe between the Harlequin MultiRIP and FlatOut. (FlatOut uses the same implementation of %pgb% to read pagebuffers.)