(v13) The different types of plugin
This page applies to Harlequin v13.1r0 and later; and to Harlequin MultiRIP but not Harlequin Core
Plugin types include:
- Input drivers, such as alternate communication links and file types.
- Output drivers, such as printer and typesetter drivers.
- Programmatically generated Halftone Screening solutions, such as Harlequinʹs HEDS screening.
- Interfaces to alternative color management systems, such as “littlecms”.
- Interfaces to alternative font rendering technologies.
Output plugins are used to direct bitmaps from the RIP to the next (possibly final) stage in the work‐ flow. Normally this is a digital printer or typesetter device, but it could be to a file or to a network socket or some other destination.
The SDK includes several examples of output plugins, including a null device, a bitmap‐to‐PostScript language converter, and a raster file data generator.
Input plugins are used to present input to the RIP from a source, or in a format, that the RIP does not currently support. For example, an input plugin would be used to read files from an FTP server and submit it to the RIP for processing.
The data is often in PDF/PostScript language form. An input plugin could transform incoming data from a particular format into PostScript language format before passing it on to the RIP for processing.
You can think of input plugins as data‐generating devices that are plugged into the RIP - typically PostScript language devices. Because they can transform the data being submitted to the RIP, input plugins can extend the range of input the RIP accepts. You could, for instance, implement your own extensions to the PostScript language by writing an input plugin which transforms jobs using the extensions into legal PostScript Level 2 or Level 3 jobs.
The connection between an input plugin and the RIP can be bidirectional, if necessary, with the PostScript language code in a job both reading from and writing to the plugin.
The SDK includes several examples of input plugins, including a repeating “Hello World” job generator, a font query generator, a uudecoding filter, and a progress device. Also included in the source code is an example console command‐line application for submitting jobs via TCP/IP sockets to RIPs running on any platform.
PostScript Device plugins
are used to present services to PostScript language programs running on the RIP as PostScript language I/O devices. Devices are initialized using the devmount
and setdevparams
operators, and referenced in filenames and other device operators. One way in which such devices can be used is to replace devices provided by the RIP so their functionality can be adjusted, for example, adding new pseudo, bulk‐data processing operators to the RIP, adding new PostScript language resource categories supported by databases, or implementing communication protocols such as CORBA or DCOM. The interface can also be used to implement replacements for certain built‐in devices, such as the pagebuffer reader and writer that supports the Output Controller and pagebuffer redirection capabilities, thereby allowing alternative file formats for these files.
The SDK includes two examples of PostScript Device plugins, a simple “ram disk” and a raster reader/writer.
Core Screening Device Plugins provide a method to extend the screening options available to PostScript language jobs running on the RIP. Standard PostScript language screening actions are implemented as static data, but the core screening API provides the ability to implement dynamically changing actions on the page buffer - for example, true error diffusion screening.
The Core Screening API is implemented in a slightly different way for the Harlequin Core command line RIP (HHR) and the Harlequin MultiRIP (HMR). In both cases, individual screens may be created as “modules”, and one or more modules can be combined. In the case of the HHR, all of the modules are compiled into the final executable. Whereas for the HMR, individual screens or collections of screens can be compiled into one or more DLL plugins.
The SDK includes two examples of Core Screening API screening: a simple bi‐level halftone that includes the ability to extinguish dark as well as light pixels, and an 8‐bit MultiLevel screen similar to that built‐in to the page‐buffer device.
Event based plugins are implemented to allow the GUI RIP to be able to locate and load event handling plugins. Two example event handler plugins are available for handling monitor messages. evteg1 is used to suppress composite time and recombine time progress messages, and to prepend text to the total time progress messages. evteg2 can be used to count warning and error level messages. In addition, an example usage of the GUI RIPʹs RDR interface is added to the opeg5 example to demonstrate aborting the output of a job, and output of text to the monitor window.
Note: The “opeg3” example can accept halftone rasters, but in a 64‐bit build it treated them as though they were 32‐bit packed. From HMR v10.0r1 this has been corrected. For more information (v13) Halftone raster packing - 1-bit-per-pixel .
The plugin example “opeg5” (available as part of the plugin kit v20.0 or later). This example shows how to use a thread to process data. Each time the “output thread” gets passed a new raster it “sleeps” for a while (to represent the time spent “processing” the data), and then the raster data itself is discarded. The plugin also shows how to report progress from the output thread using timelines. The APIs for handling threads and timelines are obtained using a PFI function to access the RDR API interface for API discovery. For more information see (v13) Event based plugins and (v13) Plugin Function Interface .