そうそう、リニアライズされたPDFがあって、これはフルファイルをダウンロードせずに最初のページを表示できるように整理されてるんだ。今はそのことを要約から省いたけど、彼らには独自の付録があるからね。

銀行がもっとわかりやすい形式で記録を提供してくれたらいいのに。でも、それまでは仕方ないね。

ほんとだよね。その間違いをしたことがあるから、もう二度とやらないよ。

残念ながら、これはある意味納得できるね。PDFはテキスト内の文字をフォントへのオフセットとして表現していて、しばしばフォントが不完全なんだ。だから、PDF内の'A'は古き良きASCII 65じゃないことが多い。理論的には、'A'だと教えてくれる2つのオプションシステムがあるはずなんだけど、うまくいかないこともあるから、結局はフォントを使って描画するしかないんだ。

知ってるPDF作成者がいないなら、PDFコンテンツを安全に扱うにはこれが唯一の方法だね。Type 3フォントだけでも、テキストを取り出すのが信頼できないか、無理な場合が多いし、スキャン画像が含まれてるPDFに至る前に問題が出る。今のLLMは、Tesseractみたいな以前の方法よりもかなり改善されてると思うんだけど、画像入力を与えた場合、モデルの能力をテストする方法って知ってる？

その通り、これはサンプルセットでよく見られた失敗状態だね。前の参照や参照チェーンのものがオフセット0を指したり、ファイルの範囲外を指したり、単に間違ってることもあった。この記事を書こうと思ったのは、私のプロジェクトPdfPigの初期解析ロジックを書き直そうとしたからなんだ。最初はJavaのPDFBoxのコードを移植したけど、もっとパフォーマンス良く書き直せるはずだと思ったんだ。新しいロジックは、単一のxrefテーブルやストリームを見逃した場合、ファイル全体を強引にスキャンすることに戻って、その回復パスのオフセットに頼ってるんだ。でも、前のコードよりかなり遅くなってしまって、変更に自信を持つのが難しい。今は1万ファイルのテストセットを通してエッジケースを特定しようとしてるところだよ。

つまり、PDFを画像としてレンダリングするために使っているソフトウェアにパースをアウトソースしてるってことだね。

「これが、PDFを解析するためのコンピュータビジョンアプローチが現実世界でうまく機能する理由なんです。」でも、PDFの一番の利点は、見えないデータを含められることだよね。例えば、私の履歴書には、私が働いていた会社で働いていた証明を埋め込むことができるんだ。でも、ビジョンベースのアプローチでは、それをキャッチするのは無理だよね。

「これが、PDFを解析するためのコンピュータビジョンアプローチが現実世界でうまく機能する理由なんです。」まあ、正直言うと、問題の文書はスキャンされた画像だけだから、どうしようもない場合も多いよね。そこで見た一番難しい問題は、ナラティブなタイポグラフィアートブックや、複雑なテキストと写真が混ざったデパートのカタログ、古い都市地図なんだ。

これ、OPにはほとんど関係ないね。

ここにPDF内部の専門家がいるけど、ちょっと聞きたいことがあるんだ。mupdf-glが他のソフトよりもずっと速いのはなんでだろう？（バニラのデスクトップLinuxで）大きなPDFの検索速度が、試した中で圧倒的に速いんだよね。他のソフトもmupdf-glみたいに速くできないのはどうしてなんだろう？何かヒントがあれば教えて！

ちょっと面白いね。PDFを印刷して、それをスキャンしてメールに送るなんて、普通は大バカにされることだよ。でも、実際にはそれを解析するためにやってるんだよね。わかるよ、他にも同じことしてる人がいるって聞いたことあるし。ただ、そんなことが必要だなんて、本当にイライラするよね。世の中、HTMLをそんな風に解析することはないのに！

これをやっている間に、PDFファイルの作成をやめるようにみんなに言ってもらえませんか？最終的には新しいPDFの数がゼロになるように。マネージャーたちが「コンピュータに紙を入れる方法」と決めてしまってから、このフォーマットには希望がなくなったよね。本来の出版中間フォーマットじゃなくて、デジタル化の曖昧な模倣が広まってしまった感じ。

ちょっと気になったんだけど、君の方法って最終的には最初にPDFを解析して表示するために使ったプログラムよりも、より良い解析を生み出すの？それとも、異なる入力パーサーの解析を統一することに価値があるのかな？

馬鹿げてるように聞こえるかもしれないけど、理論的にはこれが問題に対する最良のアプローチだと思う。PDFは人間が消費するための出力を生成することを意図しているはずで、フォーマットはデータを人間が（できれば）簡単に読めるように表示することに焦点を当てているように見える。ここでは、人間のアプローチを模倣する技術を使っているみたいで、理にかなっていると思う。ただ、30年以上経っても機械がPDFを読みやすくするための一貫した方法を追加できなかったのは悲しいね。何が足りなかったのか、ちょっと気になる。誰か知ってる人いる？

私も同じことをやってるけど、ドキュメント検索のためにね。ColqwenとClaudeみたいなVLMを使ってるよ。

そうだね、これが単純なxrefテーブルを超えて、ストリームや圧縮にまで入っていかないのはちょっと驚いたよ。欲しいオブジェクトが、変なPNG圧縮のリフで使われているストリームの中にあるって気づくまでは、そんなに悪くないように思えるんだ。オフセットがxrefストリームの中にあって、それが文書に後から追加されたフレート圧縮のものだから、ファイルの最後にあるプレーンなものから始めて、どのオブジェクトのどのバージョンがどこにあるかを考えなきゃいけない。1.7のドキュメントは簡単に見つかるけど、2年前までは2.0のドキュメントは有料だったからね。

たぶん、ffが合字として表示されるからじゃないかな。

PDFを解析するのと、PDFの内容を解析するのでは大きな違いがあるよ。PDFファイルの解析は本当に地獄だけど、PDFは基本的に「特定の位置にあるもの」であって、「境界ボックス内の整形されたテキスト」ではないから、テキストを単語として解析したいなら、どの文字が一緒に属するのかを推測しなきゃいけない。履歴書のパーサーを手伝いたいなら、アクセシビリティツリーを見てみて。すべてのPDFレンダラーがアクセシブルなPDFを生成するわけじゃないけど、アクセシブルなPDFはクソみたいなAIパーサーが名前を正しく取得するのに役立つよ。ffの問題については、おそらく履歴書アナライザーがffの合字のような非ASCIIテキストに対応できていないんだと思う。PDFレンダラーにそういう合字を生成しないように影響を与えられるかもしれないけど、その分、見た目が悪くなることが多いよ。