Skip to main content
Skip table of contents

Non-volatile settings: eerom


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

Adobe hardware RIPs record their system settings in erasable non-volatile memory (eerom). Jobs sometimes assume this can be accessed directly using the seteescratch and eescratch procedures in statusdict, so these are provided for compatibility.

Also, various defaults for factors controlled by many of the set... procedures are stored in non-volatile memory. These values are accessed by corresponding procedures setdefault... (to set a value) and default... (to examine a value) in statusdict. The RIP implements these as calls to seteescratch and eescratch respectively, to specific “byte locations” in non-volatile memory.

Eerom is modeled in the RIP as a non-relative device called %eerom%. This is usually mounted as a type 10 “absolute” device see The absolute device type, 10 so that it actually becomes a file called eerom in the SW directory. However, in custom implementations it could be modeled as real non-volatile memory. Each consecutive byte of the file is assumed to represent a byte location in non-volatile memory.

Note these procedures only set and read eerom. They do not actually initialize the values of page size, negative printing and so on as implied by Adobe definitions because the RIP provides alternative ways for these to be set up (for example via Page Setup in GUI versions). Where this is important in a custom implementation, the effect can be achieved during initialization by calling the appropriate default... operators and building a dictionary which is passed to setpagedevice with corresponding keys and values.

The specific eerom procedures are listed in the table below (the operands and results are the same in each case as for the corresponding non-default procedures namely setpageparams and so on), followed by implementation details for seteescratch.

procedure to set value(s) in eerom

procedure to examine value(s) in eerom

byte locations in eerom affected

setdefaultpageparams

defaultpageparams

102, 104–111

and 117–120

setdefaultpagemargin

defaultpagemargin

117–120

setdefaultmirrorprint

defaultmirrorprint

116

setdefaultblackoverprint

defaultblackoverprint

225

setdefaultprocesscolors

defaultprocesscolors

224


index value seteescratch -

The statusdict procedure seteescratch first attempts to find a device called %eerom% by calling currentdevparams on it. If this fails, a warning is emitted. Otherwise the first 512 bytes (the nominal size of the nonvolatile memory being modeled) are read into a string from a file opened on the device, the byte value is placed in the string at the given index (0 (zero) to 511), the file is closed and reopened for writing, and all 512 bytes written back to it. The file is then closed.

If %eerom% is being modeled with real non-volatile memory, it may be wise to check to see which locations have changed and only re-write those, since the memory is only reliably re-usable a finite number of times (typically around 10,000).

index eescratch value

The statusdict procedure eescratch first attempts to find a device called %eerom% by calling currentdevparams on it. If this fails, a warning is emitted. Otherwise the first 512 bytes (the nominal size of the nonvolatile memory being modeled) are read from a file opened on the device, which is then closed, and the byte value at the given index is returned as an integer on the operand stack. Note that all the bytes are read every time: no seek is attempted.

JavaScript errors detected

Please note, these errors can depend on your browser setup.

If this problem persists, please contact our support.