(v13) Files and file names

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

The PostScript language (and thus the Harlequin Core) makes no distinction between binary and text files, and views a file as a stream of bytes with no other structure. If the underlying operating system does make such distinctions, the device implementation must take any necessary actions to conceal this from the Harlequin Core. The PostScript language definition does cater for the usual line endings of text files, however. Text files can use ASCII CR (character 13), ASCII LF (character 10) or CR /LF pairs to indicate the end of a line.

[RB3] does not define the maximum length of a filename or the characters that a filename can contain, saying that these are defined by the underlying operating system. In practice, this is not good enough, because a wide variety of PostScript language jobs use filenames that exceed common file system limits (such as those of MS-DOS).

GGS has defined that the Harlequin Core device implementations must support the following minimum restrictions:

• Filenames (not including any preceding device name) can be up to 2048 bytes long and contain any characters other than 0 (ASCII NUL ). Filenames are case sensitive. If the underlying operating system imposes further restrictions on these limits (such as the MS-DOS 8.3 filename limit), a rigorous device implementation should provide a way of mapping PostScript language file names to and from the device-dependent names in a way that is transparent to the Harlequin Core.
• Device names can be up to 50 bytes long (excluding percent-sign delimiters) and may contain any characters other than 0 (ASCII NUL ).

NOTE: The Extensions manual describes these limits on file and device names and their variation between versions of the Harlequin RIP in more detail. Also in the Extensions manual, see the discussion of file name mapping.

You should also bear in mind that the eventual user of the product may wish to access from the Harlequin Core any file on the underlying file system; such files may have been created independently of the Harlequin Core. Any mapping scheme used should preferably allow some PostScript language filename to map to any possible underlying name, and the rules for this mapping should be part of the user documentation of your product.

The PostScript language does not treat any characters in a filename as special. In particular, “/ ”  is not a directory separator, although it often makes sense to treat it as one in the underlying file system. The corollary to this is that directories on the underlying file system must be created (and possibly deleted) automatically, since the PostScript language provides no way of performing these operations.

If there is no underlying operating system, it may be simplest to implement a “flat” file system to support the Harlequin Core.

Wildcard matching in the PostScript language operator filenameforall also does not treat “/ ” or “. ”  specially; in particular, “* ”  will match a string that includes either or both. This is different from some common operating systems; for instance, UNIX shell “* ”  matching will not match a “/ ” , and MS-DOS “* ”  matching will not match a “. ” .