(v13) systemdict file and device operators
This page applies to Harlequin v13.1r0 and later; both Harlequin Core and Harlequin MultiRIP.
The file operator
filename mode file file
The file
operator operates as described in [RB2]. However, there are some extensions to the mode operand. The reading mode may be qualified by an @
sign. For example:
(Futura-Bold) (r@) file
This identifies the file as a possible font file and if the file is not a simple ASCII file, the RIP tries to interpret the contents of the file in a record-structured way appropriate to the platform. Though Type 1 fonts are described by PostScript-language files, they are not usually delivered in this form; a font downloader extracts the font data from a structured file and converts it to the raw PostScript-language form. By using the (r@)
mode, the RIP can read the structured file directly without the intervention of a downloader. (For many composite fonts, use of the vendor’s downloader is still required, because the structure is less standardized.)
The structure is platform specific:
- On Macintosh platforms, the structure is a resource in the resource fork of the file.
- On PC platforms, two special file formats have been defined. Macintosh versions with skins implemented by Global Graphics can also read PC-format font files. Core-RIP customers will see this qualifier as the
SW_FONT
flag in the file open function and choose to implement it as they wish. This qualifier is mostly used by operators such asfindfont
andfindresource
to read such files, but it can be used also when developing PostScript-language jobs to install fonts.
Reading and writing modes may also be qualified by the &
sign. For example:
(%D%X.TXT) (w&) file
This causes the file
operator to use the same, static memory for the file object it creates as was used by the previous file opened in this way (there is one area of memory for reading and one for writing). This is principally so that files opened outside the outermost save
/restore
context in the server loop do not repeatedly consume memory during a session, and is therefore only relevant when programming the config
device in a core-RIP implementation. Clearly, another file in this mode must not be open at the same time, and since the job source and destination (stdin
and stderr
—see (v13) Pseudo-devices ) are both opened in this way, it would be very unusual to use this qualifier directly.
The devmount operator
device
devmount bool
The devmount
operator is present, documented in [EXTN2015], in most PostScript language implementations but differs in its interpretation in the Harlequin RIP: it makes the device named device, a string in device name form including percent signs (see (v13) File names, device names, and relative devices), available to those operators that deal with files and devices. The operation of mounting a device is not complete until it has been assigned a device type using setdevparams
. Until then, the device exists in limbo and though the name is recognized, operations on it (except for the setdevparams
that gives it its type) fail.
The bool result is always true
. This is present only for compatibility reasons. The operator is present in both systemdict
and statusdict
also for compatibility. Note that unlike Adobe’s devmount
operator (which requires execution in an exitserver
context), it has no restrictions on when it can be called: this is so that comment parsing procedures can mount a device if required.
Device mounting is not subject to save
and restore
or the operation of the server loop. A device remains known to PostScript language until the end of the session or until it is explicitly dismounted. Initially only %os%
, the SW
directory, is mounted; additional devices are mounted during the bootstrap process in the file Sys/ExtraDevices
. Others are mounted dynamically as required. A common method for introducing new devices dynamically is to test for their existence using devstatus
and mount them if they do not exist.
If device
is already mounted, devmount
does nothing (in particular it does not produce an error).
The devdismount operator
device devdismount -
The devdismount
operator is present, documented in [EXTN2015], in most PostScript language implementations. In the Harlequin RIP, it makes the device identified by the string device
no longer available to PostScript language operators. The operator may also have side effects on any associated hardware or software, depending on the device type: for example, an operating system lock might be discarded, or a network printer name might disappear from Macintosh choosers.
The operator is present in both systemdict
and statusdict
for compatibility. Note that unlike Adobe’s devdismount
operator (which requires execution in an exitserver
context), it has no restrictions on when it can be called.
Trying to dismount a device that is not mounted produces an invalidaccess
error. Some devices cannot be dismounted: namely %os%
, and any absolute device type (type 10) devices—see (v13) The absolute device type, 10. Attempting to dismount them also provokes an invalidaccess
error.
You cannot dismount a device while any file exists that is or has been open on the device. Attempting to do so produces an invalidaccess
error. A file object still refers to a device even when it is closed. Therefore, any such objects must have been discarded, typically by a restor
, before the device can be dismounted. Consider the following:
(%opiserver%) dup devmount pop dup << ... >> setdevparams
dup (r) file cvx exec
dup devdismount
This fails because the file, though closed (implicitly at end-of-file), still exists in PostScript language VM. Instead, the following is needed:
(%opiserver%) dup devmount pop dup << ... >> setdevparams
save
1 index (r) file cvx exec restore
dup devdismount
In this case, any PostScript language objects created by the exec
that need to be preserved across the restore
must be created in global memory. Side effects, such as painting, are not lost, so this works correctly if in this example the file contains an image to be painted, acquired from some OPI server hardware.
The devstatus operator
device devstatus false
device devstatus searchable writable relative enabled removable searchorder
freesize totalsize true
The attribute names used here differ from those used in Adobe documentation. This difference is not significant because the meanings are the same—the names are not part of the language.
The devstatus
operator is present, documented in [EXTN2015], in most PostScript language implementations. It takes the device identified by the string device
from the stack. If the device is not mounted (that is the device name is not known), only false
is left on the stack. If the device is known, various file system attributes for the device are pushed on the stack followed by true
. The attributes are as follows:
Searchable | Boolean | Indicates whether the device is searched when looking for a file not qualified with an explicit device name, and whether |
Writable | Boolean | Indicates whether files can be written on the device. This is a property of the device type and cannot be changed. |
Relative | Boolean | Indicates whether the device supports named files. This is a property of the device type and cannot be changed. See (v13) File names, device names, and relative devices for more details. |
Enabled | Boolean | Indicates whether the device is enabled. A device that is not enabled is not available for any filing operations. This is the value associated with the |
Removable | Boolean | This value is redundant and should be ignored; it is provided for compatibility. |
Searchorder | integer | The index in the list of mounted devices, indicating the order in which devices are searched for files not qualified by a device name. Searching starts at the device numbered zero (which is always the |
Freesize | integer | The amount of free space on the device, measured in kibibytes (KiB), where this is meaningful. |
Totalsize | integer | The total amount of space on the device, measured in KiB, where this is meaningful. |
The devforall operator
proc scratch devforall -
proc pattern scratch devforall -
The devforall
operator enumerates all storage devices that do not have negative SearchOrder
(see (v13) Searching for files); by default, on GUI implementations, %disk0%
and %fontset%
are the only such devices.
In its first form, which is compatible with Adobe’s implementation, it only enumerates those devices having a /Type
device parameter whose value is /FileSystem
. PostScript language device implementations that do not provide a /Type
device parameter are treated as having one with a value of /Parameters
.
In its second form, devices with names matching the string pattern are enumerated. pattern may contain wildcard characters: star or asterisk ( *
), meaning any sequence of characters, and question mark ( ?
), meaning any one character (as for filenameforall
); the percent signs are optional. To enumerate all devices with a non-negative search order, use the second form of devforall
with a pattern of (*
).
For each (matched) device, devforall
copies its name (including percent signs) into the supplied string scratch, pushes a string object that is the substring of scratch that was actually used, and executes proc. devforall
does not return any results of its own, but proc may do so, and may use the exit
operator as required to terminate prematurely.
The result is not defined if devices are mounted or dismounted in proc.
The devformat operator
device int int
devformat -
The Harlequin RIP implementation of this operator always prints a message to standard output and then executes stop
. Because the Harlequin RIP is generally superimposed on an operating system, it is not considered safe to give a user the ability to format disks, which is the intention of Adobe’s specification of this operator.
The =print operator
any
=print -
The =print
operator is a procedure, present though undocumented in most PostScript language implementations. It is identical to = , in that it converts the given value to a string (where there is a natural representation) and prints it to %stdout%
, except that it does not append a newline afterwards.
The defineresource operator
name dict category
defineresource resource
The defineresource
operator operates as described in [RB2]. However, it is also capable of operating on the Filter
category that is specified as an implicit resource. In this case dict is a dictionary containing the keys FilterType
and FilterNumber
which identify whether the filter being defined is for encoding or decoding, and the implementation of the filter. name is the name of the filter being defined.
(v13) Filters describes details of defining Filter
resources.