The DCSCommentParser procset

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

The Harlequin RIP is supplied with the DCSCommentParser procset, designed to be used for replacing DCS main files with the appropriate high-resolution separation(s) when a PostScript language job containing DCS files is processed. The mechanism for accessing the procset’s functionality is a dynamic scheme where there is a search for files as they are required. There is some initial setting up, but subsequently a workflow system that delivers jobs and replacement images into the defined locations, operates without user intervention.

To set up the DCS mechanism your code must call the DCSstandardSetup procedure from the procset. This procedure takes a dictionary on the stack, which may contain configuration values.

            <<
              /DCSdirectories [ (%MacHD%/DCS/) ]
              /DCStranslator /standardDCStranslator
            >> /DCSCommentParser /ProcSet findresource
            /DCSstandardSetup get exec

Two important configuration parameters DCSdirectories and DCStranslator, are concerned with establishing the location of high resolution files. (See Other DCS configuration items for other unconnected configuration items defining how to act with missing or partial high-resolution files.)

DCSdirectories must be an array of strings, defining the directories that are searched for high resolution files. Each string is read using the normal PostScript language parsing rules. Use it as a prefix to the file name being searched for; it should therefore normally end with a slash ( / ) character. In most cases, an explicit device name should be used in each string; if none is supplied, then the directory is taken as a subdirectory to the SW directory.

Two keys may be used rather than strings for special cases:

In most cases, the high-resolution files are placed in the database by some agency external to the Harlequin RIP, using standard names as available to the operating system. It is therefore sensible to explicitly disable filename mapping when constructing these strings, as described in What is a device? (in particular on Files, devices, device types, channels, and channel classes). Thus, if a database of high-resolution files is available on the D: drive of a Windows-based RIP installation, a string (%D%/OPI/) might be used.

The exact mechanism by which the contents of the directories specified are searched is modified by the DCStranslator parameter, described below:

DCStranslator must be either a procedure, or one of two standard names.

If DCStranslator is set as /standardDCStranslator, then each separation is searched for, first as <dir>/<color>/<file> and then in <dir>/<file>, where <dir> is the path defined in the DCSdirectories array, <color> is the color of the separation currently being processed (cyan, magenta, and so on);  <file> is the file name specified in the DCS main file for that separation.

If DCStranslator is set as /OPIlikeTranslator, each separation is searched for first as <dir>/<file> for each of the strings listed in the DCSdirectories array, and then as <dir>/*/<file>, where the asterisk ( * ) means any subdirectory found by an unlimited recursive search.

The DCS File Search page feature sets DCStranslator to standardDCStranslator, while the Image replacement page feature sets it to OPIlikeTranslator.

Both of these supplied procedures strip any drive name or directory path from the file name included on the DCS comment lines in the main file before searching for the file. The technique used is intended to work for files using directory separators from all common operating systems, but one side effect is that file names must not themselves contain any of the reserved characters ( : / \ or % ).

If DCStranslator is defined as a procedure, it must take two arguments: a color name and a key, and return either a filename and true if it succeeds in finding an appropriate high-resolution file, (or false if it does not).

The filename returned may be either a complete name, or a name relative to a %dcs% device, but to use the latter technique you must define and mount a %dcs% device yourself. Nevertheless, defining and mounting a %dcs% device allows you to use a very simple DCStranslator procedure (for example, { exch pop true } ) if you have complete control over the generation of the DCS files in the first place and can generate them with only the file name and no drive name or directory path on the DCS comment lines).

Mounting such a device may be accomplished using code like the following example; here the high-resolution data is stored on a drive named MainDrive in the directory /Publication/Seps. Alternatively you could make %dcs% relative to the SW directory. If the files are in a directory called dcs under SW, the Prefix line in the example would read:

/Prefix (dcs/)

If it is being used, the %dcs% device must be mounted first. This example checks whether it is already mounted; if not, it is mounted.

          (%dcs%) [ 1 index devstatus ] length 1 sub get not {
            dup devmount pop
            dup <<
              /Prefix (%MainDrive%Publication/Seps/)
              /Password 0
              /DeviceType 0
              /Enable true
              /SearchOrder -1
            >> setdevparams
          } if 
	      pop
        

DeviceType 0 is the file system device type; in HMR, you could also use an input plugin, in which case the device type would be 15 instead, and the other device parameters would be different—see Input plugins for more details. For users of the Core RIP, the examples here depend upon the particular device implementations adopted in your implementation.