(v13) Filter plugin implementation
This page applies to Harlequin v13.1r0 and later; and to Harlequin MultiRIP but not Harlequin Core
Filter plugins differ from other input streams in that they just transfer data, transformed appropriately, from the plugin's input buffer to its output buffer, rather than to or from any external place. (Though in performing the transfer, data might be sent through some hardware, such as a decompression board.)
Filter plugins identify themselves by setting the flag CCF_FILTER
in channelClassDescription
of the channel class. When they require data to transform, they set a special error code, IPS_FILTER_DATA
. Otherwise, they are implemented in much the same way as other input plugins, using the plugin library calls to access the buffers during D_IP_OBJECT_TICKLE
calls.
A decoding filter plugin detects the end of its source data by looking for the error code IPS_EOF
in the dataOutStatus
field of the channelContext
.
A pair of filters performing encoding and decoding operations for a certain format should be written as separate channel classes and given different names.
In the PostScript language, filters are represented as “implicit” resources see section 3.9 of [RB3]
. The RIP extends this to make filters explicit resources. A filter plugin is set up with the defineresource
operator, like this:
/MyNameDecode <<
/FilterType (r) % (r) means Decode filter, or (d) will do;
% (w) or (e) for Encode filter
/FilterNumber 16 % Always the constant 16 for input plugin
% filters
>> /Filter defineresource
This can appear in a startup file, a page feature, as part of a job, or can be invoked by comments in a job, as appropriate. The filter name is used as the channel name. The filter is used in the standard PostScript Level 2 manner, with the filter
operator. Of course, because filters are here represented as resources, uses of findresource
, and so on, are also valid. The name of the filter resource MyNameDecode
in this example is used to look up a channel class of that name.