Channels managed from the PostScript language in an input plugin
This page applies to Harlequin v13.1r0 and later; and to Harlequin MultiRIP but not Harlequin Core
Channels can also be managed directly from PostScript language jobs and startup files. In fact, when channels are created in the Input Manager, the RIP just creates a PostScript language file (SW/Config/Input
) with which to control them thereafter.
Channels are represented in the PostScript language as devices
. The devmount
operator - not listed in [RB3]
, but nevertheless available in all PostScript languageLevel2‐ and LanguageLevel3‐compatible RIPs - is used to create a channel. (The PostScript Language Reference Supplement, version 3010 and 3011
, and later, does list devmount
.) The setdevparams
operator is used to set its parameters, whether the channel is created from the Input Manager or directly from the PostScript language. The devdismount
operator can be used to delete a channel. Other device operators can be used as appropriate.
PostScript language fragments providing device creation and manipulation facilities can be put in a startup file, or generated in response to a particular PostScript language operation. For example, a high‐resolution image file to be substituted for an OPI comment could be obtained from an input channel by mounting and reading from it when the interpreter encounters the comment.
This is a typical fragment of PostScript language code to create and configure a channel:
(%mydevice%) dup dup
devmount pop % Creates the device object
<<
/DeviceType 15 % Identifies the device as an input plugin
% channel: input plugin channels are
% always numbered 15.
/Enable true % Turns the channel on.
/Password 0 % Required by the setdevparams operator.
/ChannelClass (MyOpiClass)
% Identifies the channel class by name.
>> setdevparams % Configures the device object
<<
/Password 0
/MyParameterA true % Arbitrary parameters to be passed to
/MyParameterB 42 % the plugin to configure the channel.
>> setdevparams % Configures the channel.
In this fragment of code, there are two separate setdevparams
operations. The first one creates the device - a channel of the specified channel class. The second setdevparams
configures the device just created. (When the device is created, it is created with its default configuration without D_IP_SETPARAMS
being called.)
- In the first call to
setdevparams
, the keysDeviceType
,Enable
, andPassword
are common to all devices and recognized specially by thesetdevparams
operator.ChannelClass
is recognized by the device‐type‐specific part ofsetdevparams
for input plugin (type 15) devices. - In the second call, the keys are specific to the channel class itself, and are passed to the plugin in the
D_IP_SETPARAMS
selector, with a call to change each parameter in turn. (See D_IP_SETPARAMS .) Keys not recognized as belonging to the device are ignored.
Note:
Because the order of keys in a dictionary is undefined, any keys specific to the channel class must be set in a separate call to setdevparams
. The separate calls ensure that the channel class has been created before a class‐specific key is encountered. Where the default values set by the plugin are sufficient, this second call is not required.
Once created, devices exist indefinitely until unmounted, and parameter values persist until changed: they are not subject to save
and restore
operators and are not affected by the end of a job. Further, a device cannot be unmounted if a file object still refers to it, even if the file is closed. Therefore, the request for file access would typically be put inside a save
/restore
context, like this:
(%mydevice%) dup devmount pop
<< ... >> setdevparams % create/configure the device save % before reading
10 dict begin
/thesave exch def (%mydevice%) (r) file dup
... % do something with file closefile
thesave end
restore % after reading
... % other code if required
% can include other reads (%mydevice%) devdismount % destroy device after
% final read
To implement an OPI server, all that would then be required would be to spot the OPI comments in the job, and run the code above at that time. You can do this using Global Graphics' comment parsing facilities. For an example of these, see the procset HqnParseComments
in the SW/procsets
directory.