PDFをテキストに変換

文字はどこから来て、どんな順番で出てくるのか

PDFの文字はテキストとして保存されているわけではありません。埋め込みフォントを指すグリフ番号として保存されており、それを文字に戻せるかどうかは、各グリフがどの文字を表すかを記したファイル内の対応表しだいです。ほとんどのソフトはこの表を含めます。含めない場合（一部のデザインソフトが作る切り詰めたサブセットフォントがよくある原因です）、画面では完璧に見えるのに、抽出すると意味不明な文字列になります。読み取りに必要な情報が最初から書かれていないからです。どんな抽出ツールでも直せません。難しい問題なのではなく、データがないのです。

出力を信用する前に確認すべきなのは、読み取り順です。 テキストはページが描画される順、つまりPDFを作ったソフトがたまたま書き出した順に出てきます。それは人が読む順番と一致しないことがよくあります。2段組みのページは、左右の段が正しく分かれて出てくることもあれば、行が交互に入り混じることもあり、すべては生成方法しだいです。ヘッダー、フッター、ページ番号、サイドバーは描画された位置に入るため、たいてい本文の途中に紛れ込みます。

いくつかの細かな現象は、戸惑う前に知っておくと役立ちます。合字はフォントが実際に使った1文字として出てくるため、「find」がfとiではなく1つのグリフになり、「find」で単純に検索すると見つからないことがあります。行末でハイフネーションされた単語は、ファイル内で実際に改行されているのでハイフン付きのまま残ります。また、ストレートな引用符がカーリーな引用符になっていることがよくあり、テキストをコードやCSVに使う場合は注意が必要です。

スキャンしたページからは何も取り出せず、ツールは空のファイルを渡すのではなく、その旨を表示します。文書を撮影した写真には文字はなく、ピクセルしかないからです。アウトライン化されたテキストも同じです。デザイナーはどこでも同じように印刷されるよう意図的にアウトライン化するので、その時点で文字はもう完全にイラストです。どちらも抽出ではなくOCRが必要です。

ほかの目的には

段組みが重要なら、Popplerのpdftotext -layout in.pdf out.txtはブラウザでできるどんな処理よりも優れています。見た目の間隔を実際の空白で再現するので、段組みは段組みのまま、表は読める表のまま残ります。pdftotext -rawはその逆で、描画順をそのまま出力します。スクリプトで扱うにはそれが都合のよい場合もあります。

何百ものファイルからテキストを取り出すなら、mutool draw -F txtやPythonのpdfplumberを土台にしましょう。特にpdfplumberは各文字を座標・フォント・サイズ付きで渡してくれるので、ヘッダーやフッターを勘ではなく位置で除外できます。それはこのページにはできない作業であり、大量処理で本当に重要になるのはその作業です。