(v13) Interpreting the error report

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

Errors in PostScript jobs and HHR TestConfigs

The first step in using the error report will usually be to determine the point in the file that the interpreter had reached when the error occurred. Both the line and the byte reported in the file stack are those to which the interpreter had read the file when the error occurred; it is entirely possible, indeed highly probable, that the cause of the error is not at that point in the file, but finding which procedure is called at that point may well be of assistance in further investigations.

The line number reported takes note of all line end formats which are valid in a PostScript language file (line feed, carriage return or carriage return/line feed), not including those within binary data. If a file contains mixed line ends or images in binary format, then line numbers in a text editor may not coincide with the numbers reported here. It is often easiest to find the correct place in the file by searching for the code which is reported as immediately following the error. In the example file we can find only one such section:

            T T 0 0 1584 1080 0 0 1584 1080 100 72 72 1 F F F F T T T F psu
            (HX3fx; document: MT class page)jn
            0 mf od
            %%EndDocumentSetup
            %%Page: ? 1 op
              0 xl
              1 pen
              0 gm
            (nc 0 0 1584 1080 6 rc)kp
            0.64314 0 0.24705 setrgbcolor
              1 xppen
            0 xpsg
            64 xpgr

The error report shows that the next token to be read from the file is op on a line of its own. Thus, the error will probably have occurred during the execution of od , just before the comments. If any comment parsing is in effect, then it’s possible that parsing the %%EndDocumentSetup or %%Page: comments could have triggered the error.

While most programmers will use their own techniques, and different techniques may prove most appropriate for different errors, a productive next step is often to search for code matching that reported as the top item in the execution stack. In this instance we can find:

  /xpappendod{bind /xpappndary 4 array def xpappndary 2 3 -1 roll put
  xpappndary 0 [/od load /exec load] putinterval xpappndary 3
  [/exec load] putinterval
  /od xpappndary cvx store}def
  {statusdict begin
  userdict 0 false 27.66666 wibble
  1080 1584 0 1 setpageparams {}settransfer end pxs pys scale ppr aload pop por
  {pop exch neg exch translate pop}
  {translate pop pop 270 rotate}ifelse 1 -1 scale
  }xpappendod

The offending command in the error handler report was wibble , and the top entry in the execution stack report matches the code immediately following the wibble in this piece of code. In addition, the code immediately preceding it will leave items on the operand stack which match the report. Finally, it appears that the code in question is being added to the end of an existing procedure named od , which ties back to the position to which the interpreter had read the file. It would appear that we have found the code which triggered the error.

This example is a very simple one, where at least the final cause of the problem could be found rapidly and easily. In many cases considerably more detective work is required – even here we would have to ask why wibble was undefined and yet used in the code.

Other techniques such as trace emitted to the System Monitor by debugging code added to the job which reports the value of specific variables, or uses pstack to show the current state of the stack may obviously be used to supplement the information obtained from the error handler.

Once the problem has been found it may also be necessary to correct it, but that is not an area within the scope of this document.

Errors in PDF jobs

Errors arising during the processing of PDF jobs will also trigger an error report.

In these cases, the operand, dictionary and execution stacks will only be relevant if the error is triggered during processing of one of the pieces of functionality that is handled in PostScript. This can include page device call-backs, imposition and potentially some aspects of font handling.

More commonly the key information from the error handler when processing a PDF file are the error name, the offending command and the error info.