mupdf (http://mupdf.com/)内のmutoolで作ったextractbbが不正とされてしまうようです．xref tableに空行が含まれているのがまずいようなので，とりあえず場当たり的に対処をしてみました．添付してみます．
別所で議論があったのですが、PDF Reference sixth edition (1.7) の Example G.1 などでは
「trailer」直前に空行があります。このような空行自体は不正ではないと思われます。
「trailer」直前に空行があります。このような空行自体は不正ではないと思われます。
xref 0 7 0000000000 65535 f 0000000009 00000 n 0000000074 00000 n 0000000120 00000 n 0000000179 00000 n 0000000300 00000 n 0000000384 00000 n trailermutool や Java (FreeHEP) もこのような構造の PDF を作り、dvipdfmx にはじかれます。
> xref テーブルの終端をどう決定するかは明記されてないように思います。
同意します。とはいえ、それが逆にいえば「終端が空行でも違反ではない」と解釈できるため
mutool は違反していない → はじかれるのはおかしい
というのが阿部 紀行さんのパッチの思惑だと思います。
ほんとうの Invalid xref table は「Adobe Reader で開いただけで保存を求められる場合」ですかね。
ただ、私自身も PDF は詳しくありません。
本トピックは「どうするのが正しいのか」というたたき台的に考えていただければと思います。
# GeoGebra ユーザから PDF が読めないという指摘をしばしば受けてきたのが背景にあります。
# 一例が岩崎 隆盛さんの test.pdf です。
同意します。とはいえ、それが逆にいえば「終端が空行でも違反ではない」と解釈できるため
mutool は違反していない → はじかれるのはおかしい
というのが阿部 紀行さんのパッチの思惑だと思います。
ほんとうの Invalid xref table は「Adobe Reader で開いただけで保存を求められる場合」ですかね。
ただ、私自身も PDF は詳しくありません。
本トピックは「どうするのが正しいのか」というたたき台的に考えていただければと思います。
# GeoGebra ユーザから PDF が読めないという指摘をしばしば受けてきたのが背景にあります。
# 一例が岩崎 隆盛さんの test.pdf です。
そうするとこんな感じでどうでしょう？正規表現で書くと[ \t]*(%.*)?にマッチするような行をスキップするようにしてみたつもりです．
ここで議論するのはふさわしくないでしょうし、私もメンテナからは外れているので
回答するのにふさわしくないですが、一応。
0x00 (NULL), 0x09 (Tab), 0x0a(LF), 0x0c (FF), 0x0d (CR), 0x32 (Space)
です。
また、空行を許容するのであれば、仕様解釈上は
- xref キーワードに（同一行で）続く空白文字とコメント
- trailer の（同一行の）前の空白文字
- サブセクションの開始の二つの数字の前後の空白文字等
（間はスペース1個と仕様書に記載があります）
も特に許されないことはないと思います。
こんな仕様で固定長フォーマットを導入する意義があるのか疑問ですが。
dvipdfmx に関しては、ファイル IO は mfileio.c に、PDF のパースに関しては
pdfparse.c にということになっているので、ふさわしい場所に置かれたほうが
いいかと思います。
書き出し側は厳しく、読み込み側は緩くというのが好ましい態度だと思いますの
で、mutool などの書き出し側にも、余計な空行など書かないようにさせるのが
いいのではないでしょうか。