(v13) The file system device type, 0

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

All versions of the RIP include a device type 0. (Core-RIP versions of the RIP must be provided with one by the OEM’s skin code). This supports relative devices which represent the main repository of external data for the RIP, typically disks or parts of them available through the operating system, though this is not necessarily the case: the “filing system” could be modeled in many different ways in different versions. However, it is true of all GUI and command-line versions, and most core-RIP implementations are likely to use this model.

Whatever the underlying implementation, there is always at least one device mounted for device type 0. This is %os%, mounted automatically by the RIP, which refers to the Harlequin RIP database; usually the directory is called SW (though in principle, this directory could be modeled in memory for some implementations, especially embedded controllers).

All GUI and command-line versions, and the example implementations supplied for core-RIP versions, have a single device parameter specific to type 0 devices: the Prefix parameter. This tells the operating system where on its filing system to locate files opened on the given device.

For command-line versions, and the example core-RIP versions, the string is in the operating system’s native representation and includes a trailing path name separator. For example, consider mounting a disk partition on a UNIX machine for use by the command-line version:

            (%HQN-unix-disk%) dup devmount pop
            <<
            /DeviceType 0
            /Enable true
            /Prefix (/nfs/somemachine/u/ldisk3/my-partition/)
            /Password 0
            >> setdevparams

For GUI versions, Prefix is normally the operating system name of the disk enclosed in percent signs. This is subject to file name mapping if necessary (although this would be unusual for a disk name).

For example, consider mounting a CD-ROM, say drive E: on a PC, which contains a directory fonts. This immediately makes any additional fonts in that directory available to the Harlequin RIP. The mount sequence resembles the following:

            (%HQN-cdrom%) dup devmount pop
            <<
            /DeviceType 0
            /Enable true
            /Prefix (%E%)
            /Password 0
            >> setdevparams

It is possible to put the mount point somewhere other than the top level of the disk. To do this, make the Prefix look like the PostScript-language filename of the directory you want, using slash ( / ) as the separator (subject to file name mapping as appropriate). For example, consider mounting the Macintosh directory External Disk:OPI Files:Images as the PostScript device %HQN-images%:

            (%HQN-images%) dup devmount pop
            <<
            /DeviceType 0
            /Enable true
            /Prefix (%External Disk%OPI Files/Images/)
            /Password 0
            >> setdevparams

A common requirement is to be able to store fonts in a location other than the SW folder. This is complicated by the expectation of many font downloaders to find disks named %disk0%, %disk1%, %disk2%, and so on; and the difficulties that some find when they encounter a file that does not match this pattern. To avoid the problems, the Harlequin RIP mounts all local and mounted networks drives using a meaningful prefix (to the host operating system) but makes them non-searchable by default. The simple way to make another location available for fonts is to mount %disk1% as device type 0, and make its Prefix the appropriate path.

UNC file names

On Windows it is possible to mount remote file systems using universal naming convention (UNC) filenames, expressed in the operating system loosely in the form:

\\machine\share-name\directory\...\file)

Versions of the RIP running on Windows systems allow UNC shares to be accessed directly as PostScript language devices by including a slash ( / ) in the "device" part of the Prefix device parameter of the device. For example, consider a machine called OPIPC with a published drive called EXTERNAL. The mount would then be as follows:

            (%OPIPC/EXTERNAL%) dup devmount pop
            <<
              /DeviceType 0
              /Enable true
              /Prefix (%OPIPC/EXTERNAL%)
        /Password 0
        >> setdevparams

With this done, files on that drive can then be referenced relative to this device. For example:

(%OPIPC/EXTERNAL%/OPI/IMAGES/BIRD.TIF) (r) file

The name of the device need not match the Prefix; the Prefix can also include a directory path on the shared drive:

            (%OPI%) dup devmount pop
            <<
              /DeviceType 0
              /Enable true
              /Prefix (%OPIPC/EXTERNAL%OPI/IMAGES/)
        /Password 0
            >> setdevparams (%OPI%/BIRD.TIF) (r) file

Disk mounting and versions of the RIP

The way in which disks are mounted differs between platforms and versions of the RIP:

• In Macintosh and PC GUI versions of the RIP, when a file is printed using Print File, the Print File dialog automatically generates a PostScript-language sequence to access the file. It does this using procedures in the procset HqnConfigProvider, which can be examined (but must not be changed). The sequence mounts the top level of the disk on which the printed file is located the first time it is used, taking the native disk name as the name of the PostScript-language device, as in the example in (v13) The file system device type, 0.
• In UNIX GUI versions, the RIP mounts %/% as a single top-level drive and relies on NFS to reach other disks.
• In the UNIX command-line versions, the first path in the SWPATH environment variable (or SWROOT if SWPATH is not defined) is mounted as %os%, then each subsequent path as %disk0%, %disk1%, and so on. A device %/% is also mounted to represent the top of the filing system hierarchy, which allows explicit access to all files in the UNIX filing system. For example:

%/%usr/users/harlequin/logo.ps

• UNIX command-line versions also use another device, %cd%, with a Prefix referring to the current directory when the RIP is started, which allows for easy reference to files in that directory.