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 keys DeviceType , Enable , and Password are common to all devices and recognized specially by the setdevparams operator. ChannelClass is recognized by the device‐type‐specific part of setdevparams 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.