Limitations of comment parsing

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

• Because the names of the dict and actions dictionaries begin with percent signs, it is not possible to write:

            %%dict /%%actions get begin
              ...

as the interpreter would treat the line as comment. However, names and strings are interchangeable when used as dictionary keys, so the following can be used instead (as in the example above for %%CreationDate ):

            (%%dict) load (%%actions) get begin
                ...

• Keys are limited to 64 characters.
• Some comments defined by Adobe’s document structuring conventions, as defined in [ATNDSC3.0], have a keyword that is optionally followed by a colon. It is wise not to assume the colon unless text appears afterwards, even where the specification says there must be one. Also where there is a colon, there may be zero, one, or more spaces depending on the whim of the application (the Red Book says “There should be one space character between the ending colon of a keyword and its subsequent arguments”, but do not believe it—the procedure should be written to cope with any amount of white space). Also sometimes the text argument is enclosed in parentheses and / or quotation marks.
• The %%Creator: comment cannot always be relied on. The Print Manager on Macintosh systems (and other spooling software) intercepts the original creator and helpfully replaces it with %%Creator: PrintManager in all cases!
• As mentioned in Comment parsing overview, it is perfectly possible to define both a %%CreationDate comment parsing procedure, and one for %%CreationDate: with the trailing colon. If both such procedures are defined, only one is ever called. You should take care to discover what other parsing routines are already in place when designing new parsing code.