PostScriptのエラーの場所を探す

https://www-cdf.fnal.gov/offline/PostScript/BLUEBOOK.PDF

これの147ページのProgram 5 / Centered Dash Patternsを実行するとエラーがでました。

GPL Ghostscript 9.26 (2018-11-20)
Copyright (C) 2018 Artifex Software, Inc.  All rights reserved.
This software comes with NO WARRANTY: see the file PUBLIC for details.
GPL Ghostscript 9.26: Unrecoverable error, exit code 1
Error: /typecheck in --idiv--
Operand stack:
   n   276.0   60
Execution stack:
   %interp_exit   .runexec2   --nostringval--   --nostringval--   --nostringval--   2   %stopped_push   --nostringval--   --nostringval--   --nostringval--   false   1   %stopped_push   2045   1   3   %oparray_pop   2044   1   3   %oparray_pop   2025   1   3   %oparray_pop   1884   1   3   %oparray_pop   --nostringval--   %errorexec_pop   .runexec2   --nostringval--   --nostringval--   --nostringval--   2   %stopped_push   --nostringval--   --nostringval--
Dictionary stack:
   --dict:968/1684(ro)(G)--   --dict:0/20(G)--   --dict:91/200(L)--
Current allocation mode is local
Current file position is 1006

Execution stackとDictionary stack、Current file positionはエラー箇所の特定には役立ちませんでした。

Errorにでている/typecheckはリファレンスマニュアルをみると、、、いろいろ書いてあってわかりにくいですけど、idivオペレータが出しているので値の型を間違えていると推測できます。

idivをリファレンスマニュアルでみるとidivは2つの整数を受け取ることになっています。

オペランドスタックをみると、n 276.0 60となっています。

オペランドスタックは右に追加されていくので、idivが受け取る数値は276.0と60ということになります。

ということで、エラーの原因は276.0という実数型をidivに渡しているから、とわかりました。

オペランドスタックの先頭がnになっているので、これは名前とわかります。

/n pathlen last sub patternlength idiv def

なので、エラーの箇所はpsファイルをリテラル名の/nで検索してこの行とわかりました。

/n pathlen last sub cvi patternlength idiv def 

cviで実数型を整数型に変換して解決しました。

今回はたまたまオペランドスタックにリテラル名があったのですぐ場所がわかりましたが、手続きの括弧の位置が間違っていたりするときは、とても探しにくいです。

コードが短ければデバッガでステップ実行すればよいのですけど、コードが長いとかなり面倒です。