Example output from the clrip -! 3 option

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

This section contains example output from the clrip when given a test file that causes errors.

clrip -! 3 Example 1

                        [0:M:38000802] Initial RIP virtual memory: 5 MiB (5084 KiB) used, 16
                        GiB
                      (16674816 KiB) commit limit, 32 GiB (33359872 KiB) reserved

This has a Timeline reference of zero (0 )(because it is the initial RIP report and does not relate to any particular job). It's on the Monitor Channel (M ) which is primarily for the benefit of the Compatibility Handlers and for those who want to create their own Channels. The Type is 0x38000802 : MON_TYPE_PSINITIALRIPVM defined in interface\monitor\monps.h.

This Type indicates that it's informational. That is, it's not an Error, Warning or Debug (type & MON_MASK_CLASS == MON_CLASS_INFO : begins 2 or 3 ); it's a Control message. That is, it's about the operation of the RIP rather than some feature of a particular job (type & MON_MASK_SUBCLASS == MON_INFO_CONTROL : begins 38 ); that it's from the PostScript language interpreter (type & MON_BASE_LIMIT==MON_BASE_PS : the 08 , (though you would rarely need to examine that); as well as specifically being the initial RIP VM status (type ==MON_TYPE_PSINITIALRIPVM ).

clrip -! 3 Example 2

>          [0:E:48000000] **** PostScript asserts enabled ****

This error is emitted through %stderr for some reason (E ), and is a Warning (MON_CLASS_WARNING : starts 4 or 5 ) specifically of subclass MON_WARNING (starts 48 ), but it is not unique (the rest is zero). This is the UID attached to anything output through %stderr .

clrip -! 3 Example 3

                        [Timeline 197: JOB]
                        [197:P:38000100] Starting Job On Tue Nov 25 12:13:48 2014

This is the first message with a valid Timeline reference, which is for the job, though there is no title yet. 38000100 is MON_TYPE_JOBSTART defined in monjob.h. It is MON_INFO_CONTROL as above (38 ) so appears as white on blue.

clrip -! 3 Example 4

                        [Timeline 198: "Interpreting page 1"]
                        [198:M:20000000] About to cause error
                        [198:M:20000000] this_is_undefined
                        [198:M:20000000] About to handle error

These three are lines of text output by the PostScript language job, this is because type & MON_MASK_SUBCLASS == MON_INFO_JOB (starts 20 ).

Because it is coming from interpretation it carries the INTERPRETPAGE timeline reference, which has a title of "Interpreting page <n>" .

20000000 is the default UID for anything output through %stdout , though jobs (unlikely) or procsets (more likely) can use the metaexec operator to set their own UID. For example:

                      (This has a unique UID!) {=} 16#20001234 statusdict/metaexec get exec
                        [<tlref>:M:20001234] This has a unique UID!

clrip -! 3 Example 5

>          [198:M:68140000] %%[ Error: undefined; OffendingCommand: this_is_undefined; File: %console% ]%%

There has been an error! You can tell without looking for "%%[ Error:" because type & MON_MASK_CLASS == MON_CLASS_ERROR (starts 6 or 7 ); it is a normal error not a fatal one (type & MON_MASK_SUBCLASS == MON_ERROR : starts 68 ); it is an UNDEFINED error (MON_PSERROR(type) == UNDEFINED : the 14 ); but it is not a unique one (the rest is zero).

NOTE: Errors that come from PostScript language syntax are never unique there is no point discerning between TYPECHECK from “add” and TYPECHECK from “sub”, though we do want to recognize TYPECHECK due to a broken font.

MON_CLASS_ERROR is definitive in that it informs us this text comes from (or appears to come from) the PostScript language error handler. It tells us that we can use MON_PSERROR(type) to find what kind of error it was. If it's not MON_CLASS_ERROR , it does not have an error number in it and it does not indicate that the PostScript language error handler was called.

clrip -! 3 Example 6

                        [198:M:20000000] Back after error
                        [198:M:20000000] And now the same outside a stopped

These are normal lines of text emitted by the job it is still running because it generated the above error in a “stopped” and then called “handleerror” itself yet everything was correctly labeled.

clrip -! 3 Example 7

>          [198:M:68140000] %%[ Error: undefined; OffendingCommand: this_is_also_undefined; File: %console% ]%%

The job has errored again, and it is another generic UNDEFINED . However, this one didn't happen inside a “stopped”. This can be determined because:

>          [198:M:58000800] %%[ Flushing: rest of job (to end of file) will be ignored ]%%

The job is being flushed. You can tell without parsing the text because type == MON_TYPE_FLUSHINGJOB (monps.h). This is a Warning (type & MON_MASK_CLASS == MON_CLASS_WARNING : starts 4 or 5 ); it's a Failure Warning (type & MON_MASK_SUBCLASS == MON_WARNING_FAILURE : starts 58 ); it's from the interpreter (type & MON_BASE_LIMIT == MON_BASE_PS : the 08 ) though that's not very important.

clrip -! 3 Example 8

>          RIP refused data for job error.ps

Note that this line has no metadata because the skin emitted it directly without issuing a Monitor Event.

clrip -! 3 Example 9

                        [Timeline 197: "error.ps"]
                        [197:P:38000114] Total time: 0.168 seconds (00:00:00.168)

This is a timing message for the job, so it's back to the job timeline. Note that the JOB timeline now has a valid title. 3 means MON_CLASS_INFO ; 38 means MON_INFO_CONTROL ; and 38000114 is MON_TYPE_TOTALTIME (monjob.h). The timing messages are detected by:

                      if (type >= MON_TYPE_TOTALTIME && type <= MON_TYPE_FINALTIME) {
                      /* It's a timing message */
                      ...

clrip -! 3 Example 10

>          [197:P:38000113] Job Not Completed: error.ps

This is MON_TYPE_JOBEND regardless of whether the job completed or not.