golden-luckyの日記

ツイッターより長くなるやつ

一人でアドベントカレンダーを書いている

去年に引き続き会社の近況報告をしようと思ってpyspaアドベントカレンダーにエントリしたけれど、今年は会社の話はやめて、メタアドベントカレンダーを書きます。

今年は一人でアドベントカレンダーをやることになり、とりあえず6日間、必至で書き続けました。毎日、2時間くらいは溶けています。著者の人はこういう気持ちなのかなと思いました。

もっとも、この一週間はたまたま本業のほうでも執筆仕事を2つ抱えていて、アドベントカレンダーの執筆はそのための格好の素振りになっていた気がします。 みなさんも経験があると思いますが、文章を書くときには、とにかく書くしかありません。 書かない時間が少しでもあると脳が止まってしまう。 しかし、同じ内容についてずっと考えているのは無理なので、なんでもいいから書き始めて、なんでもいいから書き続けるしかありません。 この状況をぼくは「素振り」などと呼んでいます。

今週は、アドベントカレンダーを素振りにすることで、執筆のお仕事を乗り切れました。それがさっき終わったところ。

来週の本業は編集制作の佳境なので、たぶんアドベントカレンダーの執筆とは両立できません。 今週末にどれくらい書きためられるかで、この一人アドベントカレンダーの成否は決まりそうです。

さて、そもそもなんで一人アドベントカレンダーをやることになったかというと、渋川さんが「会社のアドベントカレンダーが一瞬で埋まった」という話をしているを聞いて、Qiitaのアドベントカレンダーには企業という概念があることを知り、「それなら当社も一瞬で埋められるのでは？」と変な気を起こしたからなのです。

ただ、これは理由の半分でしかありません。 さらにもとをたどると、「ラムダノートは良い本を作ってはいるけれど、本の売り上げだと経済的な基盤が危ういので、もうちょっと手堅い仕事ができるってことをアピールしろよ」という大株主の意向があったのです。 この意向が下されたのは夏過ぎに開催された臨時株主総会（という名のランチ奢られ）の日のことでした。

実際、年度末になって会社の現金が本気でまずい状況になりそうな状況が発覚してしまい、まだ予断を許さないのだけど、読者の皆様のおかげで少しだけ息を吹き返しました。 いやほんと正直なところ夏ぐらいのぼくの皮算用だと前年よりも順調に推移している感触だったのですが、今年の4月に創刊した『n月刊ラムダノート』に全力投入しすぎて受託のお仕事を取らなかったからか、あるいは単純に5年目の危機というやつなのか、大株主の予感どおりになり、大株主やっぱすごいなと思いました。

で、いわゆる「手堅い」お仕事を増やせばいいかというと、それはそれでまずくて、なぜなら出版業界は単価の相場が低いからです。 低めの単価でたくさん仕事を受けてしまうと、自社の出版活動が本気で滞ってしまう。

つまり、当社（というかぼく）が実際に請け負える仕事はというと、ドキュメントに関する「人海戦術が効かないような力仕事」ということになります。 適当なツールや知見が存在しないので腕力がいるけれど、業務フローに落とし込めるわけでもないので人手を増やしても解決できないような仕事です。

で、株主の人は「そういう仕事やれよ」といいました。 加えて、そういうお仕事を営業で取りに行く余裕がないのも知っているので（なぜなら『n月刊ラムダノート』の編集に忙しいから）、「ブログとか書いてアピールしろよ」みたいに言いました。

個人的にも、自分が企画する本ばかり作っているとスキル（それがあったとして）がたこつぼ化するので、特殊な挑戦が必要になるような仕事を積極的にやってみたいという気持ちがあります。

そんなところで渋川さんの会社の話を聞いたのがトリガーになり、Qiitaの企業カテゴリーでアドベントカレンダーを立ち上げて一瞬で埋めるに至りました。 今日までは低レイヤの話をしたので、明日からはもうちょっと高レイヤでドキュメント技術の話を続けます。 ラムダノートの技術 アドベントカレンダーを見て、なんか相談できるかなと思った方は、ご相談ください。

明日のPyspaアドベントカレンダーはあきすて氏です。

PDFから「使える」テキストを取り出す（第6回）

今日まで延々と「PDFからテキストデータを取り出すのは大変」という話を続けてきましたが、その構造を見るにあたっては、 hpdft という自作のツールを使ってきました。 大変とはいっても、まあ実現困難な話ではなく、この程度のPDFパーザであれば趣味プログラミングで自作できる範囲です。

しかし、べつにわざわざ自作しなくても、「PDFからテキストデータを取り出す」ためのツールなら世の中にはすでにいくつもあります。 特に有名で昔からよく使われているのは、Xpdf由来のpdftotextでしょう。

XpdfからはPopplerが分派しているので、Poppler版のpdftotextもあります。

また、pdfminerというツールもあります。

pdfminerが面白いのは、行間などを細かく指定して読み方をユーザがある程度まで制御できるところです。ちなみにhpdftはpdfminerにちょっとだけ影響を受けています。

有償の製品まで幅を広げるともっといろいろな選択肢があります。 いずれも使ったことはないですが、個人的にいちばん気になるのは、アンテナハウスのPDFXMLです。 これ、たぶん同社のPDF編集アプリの応用で、あのアプリを実現するためにPDFのテキストを認識する部分だけを切り出した製品であるような気がするんですが、だとするとかなり構造化されたデータが取れたりしそう。

Acrobatのようなビューワーからテキストを範囲選択してコピペすることもできます。「テキストとして書き出し」みたいなオプションがある場合もあるでしょう。

PDFからHTMLを作る

hpdftを作り始めたのは、もともとは「PDFの中身を直接読みたい」という単純な好奇心からでした。 しかしながら、既存のツールに頼らず自作したことで実際に仕事に役立った事例があるので、最終回はそれを紹介だけして締めたいと思います（その後でちょっとだけエモい話もするよ）。

さて、ここに当社で発行している『定理証明手習い』という本があります。

『定理証明手習い』www.lambdanote.com f:id:golden-lucky:20191205214620p:plain

この本、翻訳書なんですが、使える原書のデータがPDFしかありませんでした。 翻訳の版権を購入すると、原書のDTPデータやTeXソースを原書出版社から提供してもらえることが多いんですが、どういうわけか本書については印刷所に入稿されたPDFしかもらえず、それをベースに翻訳作業を開始することになりました。

しかしこの本、そこそこ特殊で微妙な色分けなどが施されていて、既存のPDFテキスト抽出ツールでは翻訳に使えるようなデータが得られません。 というか、膨大な目視による手作業が必要になる有様でした。 そんなのはいやだ。

そこでどうしたかというと、hpdftを本書専用に改造し、それでテキストだけでなくグラフィックスに関する情報をなんとなく読み取ってHTMLを吐き出すようにしました。 たとえばPDFのコンテンツストリームにはCSとSCというオペレータがあるのですが、これらでPDF上の色が決まります。 /PANTONE285PC CSとか/PANTONE153PC CSで色空間を決めて、数値 SCでその強度を設定するという感じです。 ここから取得した値を使って、<font color="">...</font> を組み立てるようにします。

また、PDFを生成したツールが一冊の書籍中でまちまちということはないので、テキストに関するオペレータからインデントの分量もある程度までは読み取れます。 もちろん人間による確認と細かい調整は必要ですが、それは自分で原書を見つつ一次翻訳をするので、その過程でついでにやりました。

最終的に、こんな感じのオリジナルのPDFから…

f:id:golden-lucky:20191205214122p:plain

こんな感じにレンダリングされるようにCSSをあてがったHTMLを半自動で出力しています。 （ちなみに、このHTMLでは英日を対訳で表示できるようになっていますが、これはhpdftの出力とは別に後処理でやりました。）

f:id:golden-lucky:20191205214325p:plain

このHTMLの状態で監訳の中野さんにみっちり直してもらい、そのHTMLを最終原稿としてそこからLaTeXを介してPDFにすることで、翻訳版の書籍が次のようなページとして完成しています。

f:id:golden-lucky:20191205214344p:plain

つらいのはPDFではなく人間

今日まで6回に分けて、「PDFファイルからのテキスト抜き出しは単純な作業ではないけれど、条件さえ合えば、PDFからうまくテキストを取り出して再利用できないこともない」という話をしてきました。 結局、「PDFファイルからのテキスト抜き出しは単純な作業ではない」の部分だけが強調されてしまった気もしますが、これはPDFの出自にさかのぼった第1回の記事のことを考えると、ある意味では「予想された結末」だったような気もします。

そもそもPDFは、紙に印刷された状態を再現するためのデータ形式であり、そこに埋め込まれたテキストを再利用できる条件は限られています。 本文では紹介しませんでしたが、/ActualTextというエントリに「実際の文字列」を含めるようなこともPDFの仕様上は可能です。 さらに進むと、タグ付きPDFといって、ページ上のテキストに対する構造を伴ったPDFも仕様化されています。 そういったPDFであれば、データの再利用を目的とした用途にも有効でしょう。 最終回の記事で紹介した事例のように、書籍のような「それなりに同じパターンの見た目のページが数百ページくらい繰り返す」ドキュメントであれば、そのパターンに合わせてコンテンツストリームからテキストを取り出す処理を書くこともまったくのおとぎ話というわけでもありませんでした。

ようするにPDFのつらさとは、その仕様からくるテキスト抜き出しの煩雑さではなく、「ドキュメントの見た目」と「データとしてのドキュメント」をごっちゃにしている人間の残念さだといえます。

ドキュメントの見た目という観点では、人間向けにプラットフォームをまたいだ見た目の再現に関してPDFは本当に考え抜かれたフォーマットなので、当社の商品である書籍のようなメディアにはうってつけです。 一方で、データの再利用を前提としたドキュメント、たとえば行政機関による統計データの配布などにはまったく不向きです。 後者にPDFを使うのはやめましょう。

さて、PDF編はこれでおしまい。 明日からは「HTMLからLaTeXを介してPDFにする」部分を何回かに分けてお話する予定です。

（そう考えると、『定理証明手習い』の事例は、PDF→HTML→LaTeX→PDFという円環を閉じる物語だったとも言えそうですね。）

PDFから「使える」テキストを取り出す（第5回）

昨日の記事では、PDFのコンテンツストリームから文字を読めたことにして、その文字をテキストとして再構築する話をしました。 今日は昨日までの話の締めくくりとして、「PDFごとにカスタムなテキスト取り出し」の話をするつもりだったのですが、その前に文字とコンテンツストリームについて落穂拾いをしておくことにしました。

というのは、昨日までの記事への反応を見ていて、この本のことをちょっと思い出したからです。

この本、PDFのドキュメント構造を知りたい人が最初に読むにはぴったりだと思います。 自分で簡単なPDFを手書きしながら「PDFの中身がどうなっているのか」を学べるように書かれているので、ドキュメント構造やコンテンツストリームの雰囲気を手軽に体験できる良書です。

しかし、この「自分で簡単なPDFを手書きしながら」って部分に、実用上はどうしても難があるんですよね。 特に、テキストに関していうと、英文の例でも和文の例でも「コンテンツストリームにリテラル文字列を書く」というアプローチをとっているので、これが誤解を与えやすいと思います。 この本のサンプルコードだけでPDFを理解した気になってしまうと、「世の中のPDFには文字データがそのまま含まれている」ような錯覚にとらわれてしまい、この連載で1回目に強調した「PDFの文字は文字ではない」ということが意識できなくなる気がします。

PDFファイルを開いてドキュメント構造をパースし、そこで得られたコンテンツストリームを通常のテキストデータと同じ感覚で読んでも、期待される「文字」は手に入らないのです。 CID/GIDを表現する値からUnicodeの文字を変換して手に入れる必要があります。

そして、実を言うと、罠はこれだけではありません。 PDFのコンテンツストリームにおいて「CID/GIDを表現する値」がそもそも単純ではなく、PDF生成エンジンの実装に依存しているのです。

PDFのコンテンツストリームでテキストを表す方法は生成エンジンごとに違う

たぶん、この記事を読んでいるような人は、PDFのコンテンツストリームを自分で開いてみたことがあるように思います。 そこで目にしたのは、ほとんどの場合、昨日までの例に出てきたのと同じような16進表記のCIDの値の列だと思います。

BT
  /F1
  12.4811 Tf
  125.585 -462.55 Td
  [(#1)] TJ
  /F2
  13.2657 Tf
  19.932 0 Td
  [<0b450a3a0c2403c3029403bb0715037103cd03bb029403ef03da03bf03bd0377062c0ac5>] TJ
ET

この例の0b450a3a0c24...というやつですね。このような方法でコンテンツストリームのテキストが表現されたPDFは「もっともよく見かける」タイプです。 言い換えると、コンテンツストリームにおけるテキストの表現方法はこれだけではありません。

ぼくが今まで遭遇したものだけで、世間には少なくとも次の3種類のテキストの表現方法をもったPDFが存在しています。

  • PDFのコンテンツストリームでは、16進表記で文字列を表現することになっています。なので、この方法でテキストを表現する実装が一般的です。
  • PDFのコンテンツストリームではリテラルを使えるという話をしましたが、このリテラルの一種で「8進表記の3桁の数字で任意の文字を表せる」というチートがあります。このチートを使ってテキスト中の文字を表現してくる実装があります。
  • PDFでは、スラッシュで始まる文字列を「名前」として使うという話を昨日か一昨日かにしたのを覚えているでしょうか。/Nameみたいなやつです。この表現を使ってコンテンツストリームのテキスト中でUnicode文字を表現してくる実装があります。利用する名前についてはどこかで決められていた気がしますが、忘れました。名前がない文字も、XXXXをUnicodeのコードポイントとして/uniXXXXというふうに表現されます。

個人的にはじめて見たときに特に驚いたのは、このうち2つめの「ASCIIの印字可能文字と「エスケープ＋8進3桁」によりCID/GIDをテキストとして指定してくるPDF」の存在でした。 わりと歴史が古いPDF生成エンジンの中には、そういう実装になっているものがあるようです。 まあ、どのみち/CIDSystemInfoを確認してから文字列を見くので、リテラル文字の扱いを仕様どおりに実装していれば混乱はないのですが、ぼくは最初にhpdftを作り始めたときリテラル文字をそのままASCIIとして読むという怠惰なことをしていたので、この手のPDFを始めて見たときには混乱しました。

なんにしても、まず「文字」の原料となる値の取り出しだけで、少なくともこれだけの方法に対応したパーサを書く必要があります。

CMapをどこで手に入れるか

次に、適切なCMapを見つけるという問題があります。

/CIDSystemInfoで具体的なCMapの種類が指定されている場合には、そのCMapをどこかで入手して参照できるようにしておかなければなりません。 Adobe Japan-1などであれば、Adobeが公開しているものが使えるので、この辺から手に入れておきます。

もし、こういう形で入手できない独自のcmapを利用しているTrue TypeフォントがPDFの中で使われていたりしたら、一体どうすればいいでしょうか？ わかりません。たぶん、どうしようもない気がします。

さらにやばいのはType 3フォントです。Type 3、まじやばい。 これは「グリフの形状を表現した完全なPostScript命令」がそのままフォントとして使えるという仕組みで、つまり出自からしてグリフしか存在せず、「文字」がない。 TeX界隈だと、DVIPSというソフト経由で生成されたPDFではType 3フォントが使われることになっているので（DVIPSの仕様のはず）、この理由で文字が取れないPDFファイルはわりと目にします。

一方、PDFに/ToUnicodeが埋め込まれている場合にはむしろ楽で、そこで指示されている材料からCMapを自分で復元するだけです。 まあ、自分でCMapを復元しないといけないので、PDFの中を眺めるだけだと限界がありますが。

ただ、ここにも罠があって、/ToUnicodeエントリから復元したCMapではコンテンツストリームのテキストから文字を取れないことがあります。 たとえば、昨日の例でうまく取れなかった「κ」の文字。 コンテンツストリームではこんなふうに表現されています。

BT /F4 10.5206 Tf 395.991 -462.55 Td[(\024)]TJ...

フォントリソース/F4を使って、\024という8進表記の値から、Unicodeの文字を解決すればよさそうですよね（余談ですが、こんな感じでカジュアルに「8進表記の数字3桁によるリテラル」は身近なPDFに登場します）。 そこで、/F4を表すオブジェクトを見てみると、こんな感じになっています。

$ hpdft -r 59 NML-book.pdf
[
/Type: /Font
/Subtype: /Type1
/ToUnicode: 2309
/Widths: 2310
/FirstChar: 20.0
/LastChar: 110.0
/BaseFont: /SRDEOM+LucidaNewMath-AltDemiItalic
/FontDescriptor: 2353]

2309に/ToUnicodeがあるらしいので、当然、これを見てUnicodeの値を解決できそうな気がします。

$ hpdft -r 2309 NML-book.pdf
[
/Filter: /FlateDecode
/Length: 247.0,
  /CIDInit /ProcSet findresource begin
12 dict begin
begincmap
/CMapName /SRDEOM+LucidaNewMath-AltDemiItalic-UTF16 def
/CMapType 2 def
/CIDSystemInfo <<
  /Registry (Adobe)
  /Ordering (UCS)
  /Supplement 0
>> def
1 begincodespacerange
<00> <FF>
endcodespacerange
1 beginbfchar
<5D> <266F>
endbfchar
endcmap
CMapName currentdict /CMap defineresource pop
end
end
]

これがCMapの材料です。これから、CMapの仕様にしたがってCMapを再構築すると、こういう対応関係が1つだけ得られます。

(93,"\9839")

これは、「10進表記で93のテキストはUTF-16の9839として読めばよい」という意味です。 UTF-16の9839というのは、「♯」のことで、実際、このPDFの別の場所のコンテンツストリームには10進表記で93に相当する8進表記を含むテキストが出てきて、それは文字「♯」として読むことになります。

しかし、このCMapには、\024つまり10進表記の20に対応する変換表がありません。 そのため、たとえばAcrobatで開いてこの「κ」をコピペしても「κ」は得られず、10進表記の20に対応する文字（ASCIIの制御文字のひとつ）しか得られません。

こうなると、なんでpdftotextでこれを文字「κ」として読めるのか、のほうが謎に見えてきます。 いまのぼくにはほんとに謎なんですが、XPdf系の実装は何か特殊なことをしているのかもしれない。 でも、Sumatraでも「κ」が取れるので、ぼくの理解（とAcrobatの実装）がダメなだけかもしれない。

追記：たぶんぼくが手を抜いてるからで、埋め込まれているTrueTypeフォントの中に入ってるcmapを見れ、との情報をいただきました。ありがとうございます。

そもそもPDFのコンテンツストリームの表現方法に生成エンジンの実装による癖がある

昨日の記事では、「どこに文字が配置されるか」を表現するのにTdオペレータとTJオペレータを使っているPDFの例を見ました。 あのPDFはdvipdfmxというPDF生成エンジンで生成したものなんですが、dvipdfmxはこのような比較的単純なコンテンツストリームの表現でPDFを出してくるようです。

これがmacOS標準のQuartzというエンジンだと、比較的単純なドキュメントであってもTmというオペレータを多用してくるように見えます。 なのでちょっと「いい感じの改行とスペーシングでテキストを取り出す」のがうまくいかないことがあります。

今日の記事で最初のほうに説明したテキストの表現やCMapの埋め込み方がまちまちなのも、生成エンジンのクセみたいな感じで、いろんなPDFの中身を見ているとなんだかPDFソムリエ的な気分になってきます。

明日はPDFからHTMLを作って本の原稿にした話です

というわけで、今日は「気が向いたら明日の記事で話すつもりだった話」をしました。 明日こそは、ほんとうは今日話すつもりだった、PDFからHTMLを作った話をしたいと思います。

PDFから「使える」テキストを取り出す（第4回）

昨日までで、PDFからテキストを取り出すにあたり、グリフから文字を手に入れるところまでを説明しました。

いや本当のことを言うと、まだ全然説明できてないんです。 でも、文字の話ばかりしていても先に進めないので、今日は（可能な場合には）PDFから文字を入手できるものとし、そこからテキストを再構築する話に進みます。

文字については改めて明後日にでも補足記事を書くかも（このシリーズはいちおう今日と明日で終わる予定）。

PDFオペレータを読むとグリフを置く場所がわかる

昨日に引き続き、次のようなテキストセクションで考えます。 グリフから文字の解決は済んでいるということにして、TJオペレータの引数は文字そのものに置き換えました。

BT
  /F1
  12.4811 Tf
  125.585 -462.55 Td
  [(#1)] TJ
  /F2
  13.2657 Tf
  19.932 0 Td
  [(代数的データ型とパターンマッチの基礎)] TJ
ET

一般にPDFビューワーでは、「ページ上のどこにグリフを置くか」を、ページを抽象化した「テキスト空間」の座標として計算しています。 そして、テキスト空間における現在の位置を更新するオペレータや、テキスト空間を変形させるオペレータがいくつか用意されています。 スタックマシンを実行すると、そうしたオペレータにより、テキストの現在の位置が更新されていきます。 その途中でTJのようなテキスト描画のためのオペレータがあれば、そこに引数のテキストが配置されます。

人間がペンで紙に文字を書くときは、腕の位置を移動させたり、逆に紙を移動させたりしながら、互いに重ならないように文字を配置していくわけですが、それと同じようなことをスタックマシンの実行によりやっている感じです。

で、上記のうちTdというオペレータが、腕の位置を動かす役目のやつです。 引数を2つ取っていることがわかると思いますが、これらが動かす先のxy座標におおむね相当します。

どういうことなのか、上記の例で見てみましょう。

1つめのTdは引数として125.585と-462.55を取ります。 これは直観的に解釈すると、「横方向に125.585単位、縦方向に-462.55単位だけ腕を動かす」という感じになります。 そうやって腕を動かした場所に、その次に出てくるTJオペレータによって「#1」というテキストが描画されます。

同様に、2つめのTdの引数は19.932と0です。 これは2つめの引数がゼロなので、縦方向には動かないっていうことだな、というのが読み取れます。 横方向に少し移動し、そこで次に出てくるTJオペレータによって「代数的データ型とパターンマッチの基礎」というテキストの各文字が描画される、という具合です。

ちなみにTfというオペレータは、描画するフォントのサイズを変える働きをします。 この例だと、最初の「#1」というテキストの各文字は、「フォントリソース/F1のフォントをサイズ12.4811単位で描画する」ということがわかります。 同様に、次の「代数的データ型とパターンマッチの基礎」というテキストの各文字は、「フォントリソース/F2のフォントをサイズ13.2657単位で描画する」ということがわかります。

グリフを置く場所からテキストを推測する

さて、ここで注意してもらいたいんですが、ここまでに説明したPDFオペレータの動作は「PDFのページにテキストを描画する」ために用意されています。 つまり、そうやって描画されたテキストをどう読めばいいのかは、この仕様からはわかりません。 「各文字の座標からテキストを意味がある順番に再構築」って、いったいどうやればいいんでしょう？

それほど自明な解決方法はないような気がしますが、とりあえずPDFの仕様に戻って考えてみます。

先ほどは、TDオペレータの動きを、「xy座標に沿ってテキストを描画する位置を動かす」という、なんとなくタイプライターっぽいモデルで説明しました。 実は、PDFの仕様では、こういうタイプライターモデルは使われていません。 代わりに、「各文字が描画されるべき座標」を、「テキスト行列」と呼ばれる3x3行列でぐるぐる変換していくことになっています。 Tdオペレータも、実際には、このテキスト行列を更新するためのオペレータとして考えるべきです。

行列計算といっても、テキスト行列のほとんどの要素はゼロで、実際に計算に必要な値は3x3行列の9つある要素のうち6つだけです。 仕様でも、これら6つの値を[a, b, c, d, e, f]という配列で管理するものとしています。

たとえば、コンテンツストリームにt1 t2 Tdというオペレータが登場したとしましょう。 これにより、[a, b, c, d, e, f]というテキスト行列が、[a, b, c, d, a*t1 + c*t2 + e, b*t1 + d*t2 + f]というテキスト行列へと更新されることが単純な手計算でわかります。 なので、このような行列の更新としてTdオペレータの挙動を定義できます。

さらに、こちらのほうがむしろテキストを取り出すという目的にとっては重要なんですが、このテキスト行列の更新を観察することで、「改行が発生するかどうか」を推測できます。 何を根拠にして推測するかというと、とりあえずPDFが横書きだと想定し、「次の2つのいずれかの状況になったら、このTdオペレータによって次のテキスト描画のタイミングで改行が発生する」と決めます。

  • 現在のテキストの横方向の位置が、行列変換によって、それまでよりも小さくなった（改行が発生していなければ右になるはず）
  • 現在のテキストの縦方向の位置が、行列変換によって、それまでと極端に変わった（改行が発生していなければほぼ同じになるはず）

テキスト行列に変化をもたらすオペレータは、TdのほかにTmなどがあります。 それらのオペレータの仕様の記述をにらみながら、同様の推測をすることで、「人間が期待するような順番でテキストを再構築」しようというわけです。

ちなみに今の話に直接は関係ないですが、文字を取り出すのにOCRするアプローチでも、この「人間が読む順番を表現したメタ知識をどうやって与えてあげるか」という問題の解決策は必要になりますね。 コンテンツストリームから取り出すのとは別のヒューリスティックが必要になるような気がします。

PDFのページ上のテキストをhpdftで取り出す

グリフから文字を取り出せるようになり、テキスト行列をだいたい制御できるようになったら、いよいよPDFのページからテキストを取り出せます！

hpdftでは-pオプションでページ番号を指定してテキストを抜き出せるようにしてあります。

$ hpdft -p 1 NML-book.pdf

#1 代数的データ型とパターンマッチの基礎 3een
#2 パターンマッチ in Ruby 辻本 和樹
Vol.1, No.3
Nov . 2019

だいたい期待どおりの改行位置とスペーシングでテキストが抜き出せてますね！ ただ、3eenという文字列は本当ならκeenとなってほしいので、CMapの扱いはもうちょっと詰める必要がありそうです。

ちなみに、このくらいであれば、pdftotextのような既存のツールでもだいたい意図したとおりに改行とスペーシングを見つけ出してくれます。 さすが、「κ」もちゃんと変換できてますね。

$ pdftotext -f 1 -l 1 NML-book.pdf
$ cat NML-book.txt
#1 代数的データ型とパターンマッチの基礎 κeen
#2 パターンマッチ in Ruby 辻本 和樹

Vol.1, No.3
Nov . 2019

ただ、もうちょっとテキストが多いページになると、pdftotextの出力結果はわりと破綻してきます。 同じPDFの7ページはこんな感じ。

$ pdftotext -f 7 -l 7 NML-book.pdf
$ cat NML-book.txt
Lambda Note

1.2 SML♯ の REPL で速習 SML

3

本記事には、特に断りがない限り、処理系依存のコードは登場しません。そのた
め、本記事を読むうえでは、規格を満たす処理系であれば上記に限らず何を利用して
も問題ないはずです。
C と SML 以外の言語の話も少しだけ出てきます。それらについては、想定する処理

系をそのつど個別に記載します。

1.2 SML♯ の REPL で速習 SML
パターンマッチの話題に入る前に、SML の基本的な挙動を確認しておきましょう。
幸い SML♯ には REPL（対話的実行環境）があるので、これを利用して以降の解説に必
要な最低限の情報をまとめます。
シェルから smlsharp として SML♯ を起動すると、下記のように REPL が立ち上が
ります。 # が SML♯ のプロンプト記号です。
1
2
3

$ smlsharp
SML# 3.4.0 (2017-08-31 19:31:44 JST) for x86_64-pc-linux-gnu with LLVM 3.7.1
#

hpdfだと同じ範囲はこうなります。

$ hpdft -p 7 NML-book.pdf

Lambda Note 1.2 SML ♯のREPL で速習 SML 3
Vol.1, No.3(2019)-#1
? SML: SML ♯?33.4.0
? C: GCC 8.3.0
本記事には、特に断りがない限り、処理系依存のコードは登場しません。そのた
め、本記事を読むうえでは、規格を満たす処理系であれば上記に限らず何を利用して
も問題ないはずです。
C とSML 以外の言語の話も少しだけ出てきます。それらについては、想定する処理
系をそのつど個別に記載します。
1.2 SML ♯のREPL で速習 SML
パターンマッチの話題に入る前に、 SML の基本的な挙動を確認しておきましょう。
幸い SML♯には REPL （対話的実行環境）があるので、これを利用して以降の解説に必
要な最低限の情報をまとめます。
シェルから smlsharp として SML♯を起動すると、下記のように REPL が立ち上が
ります。 #がSML♯のプロンプト記号です。


1 $smlsharp ?
2 SML# 3.4.0 (2017-08-31 19:31:44 JST) for x86_64-pc- linux-gnu with LLVM 3.7.1
3 #

よく見るとpdftotextには欠けている情報があることもわかるでしょう。

この例だと「κ」の問題などがあるのでどっちもどっちですが、ここまで自力でPDFからのテキスト抜き出しができると、ちょっと工夫して自分に都合よく改行の推測ルーチンを変更したりできます。 さらに、テキストに直接関係しないPDFの他のオペレータなんかも利用して、メタ情報を付加でき足りできます。

明日は、そんな感じに自作のPDFテキスト取り出しツールを実用して売り物の書籍を作った話をします。

PDFから「使える」テキストを取り出す（第3回）

昨日の記事では、PDFのページに表示されるコンテンツはPDFのドキュメント構造を掘っていくと手に入れることができて、それはこんな姿をしているぞ、というところまで話が進みました。

$ hpdft -r 66 NML-book.pdf
[
/Filter: /FlateDecode
/Length: 381.0,
   q .913 0 0 .913 0 595.276 cm q 462.33906 0 0 655.95015 -3.064 -652.208 cm
/Im24 Do Q 1 G 1 g BT /F1 12.4811 Tf 125.585 -462.55 Td[(#1)]TJ /F2 13.2657
Tf 19.932 0
Td[<0b450a3a0c2403c3029403bb0715037103cd03bb029403ef03da03bf03bd0377062c0ac5>]
TJ ET 0 G 0 g 1 G 1 g BT /F4 10.5206 Tf 395.991 -462.55 Td[(\024)]TJ /F5
10.5206 Tf 7.302 0 Td[(een)]TJ ET 0 G 0 g 1 G 1 g BT /F1 12.4811 Tf 125.585
-485.638 Td[(#2)]TJ /F2 13.2657 Tf 19.932 0
Td[<03cd03bb029403ef03da03bf03bd>]TJ /F1 12.4811 Tf 96.842 0
Td[(in)-318(Ruby)]TJ ET 0 G 0 g 1 G 1 g BT /F6 11.0547 Tf 302.652 -485.638
Td[<0bf0>]TJ /F7 11.0547 Tf 11.055 0 Td[<0e8a>-296<0fe80925>]TJ ET 0 G 0 g
0.925 0.945 0.745 RG 0.925 0.945 0.745 rg BT /F8 25.1057 Tf 83.065 -615.417
Td[(Vol.1,)-301(No.3)]TJ /F8 12.4811 Tf 0 -15.392
Td[(Nov)-301(.)-373(2019)]TJ ET 0 G 0 g Q
]

今日は、ここから「文字」（グリフじゃないよ）を手に入れる話です。

PDFのコンテンツストリーム

ドキュメント構造をルートからたどっていって、最後に/Contentsが指し示す参照番号のオブジェクトに含まれている上記のような文字列は、PDFの「コンテンツストリーム」と呼ばれています。 コンテンツストリームは、PDFに表示されるべき「テキスト」とか「グラフィックス」とかを格納するための仕組みだといえます。

じゃあ、これをどう読めば描画結果になるかというと、簡単に言えばスタックマシンで実行します。 第1回のPDFの歴史のあたりの話から丁寧に読んでいる人はここでピンとくるかもしれませんが、「PDFがPostScriptのバイナリ版」みたいな説はここに由来します。

ただし、PostScriptとPDFのコンテンツストリームとでは、スタックマシンで扱う命令の種類はけっこう違います。 上記の文字列の中に見えるqとかQとかcmとかBTとかみたいなのがPDFの仕様で定義されている「オペレータ」です。 それ以外の数字とかは変数や定数で、これらを先頭からPDFコンテンツストリーム用のスタックマシンで実行すれば、描画結果が得られるという仕掛けになっています。

なお、コンテンツストリームは、ふつうは全体が何らかのアルゴリズムで圧縮されています。 圧縮のアルゴリズムが何であるかは、このオブジェクトの/Filterエントリで指定されています。 この例の場合は/FlateDecodeで、これは、いわゆるZIPの圧縮に使われているアルゴリズムです。

圧縮されてるので、そのままの姿を端末で表示すると端末が死んだりします。 なのでhpdftではコンテンツストリームについては圧縮を復元した状態を表示するようにしていて、したがって、上記の文字列をそのままPDFの仕様に沿って読めばPDFのページ上のコンテンツを復元できるはず、です。

PDFのテキストセクション

いま興味があるのは、コンテンツストリームのうち、「テキスト」を表現している部分だけです。 PDFの仕様では「BTオペレータからETオペレータまで」の部分を「テキストセクション」と呼んでおり、テキストとして取り出すべき情報はすべてそこにあります。

そこで、まずは上記のコンテンツストリームから、先頭のテキストセクションだけ手作業で抜き出してみます（見やすいように改行とインデントを施しました）。

BT
  /F1
  12.4811 Tf
  125.585 -462.55 Td
  [(#1)] TJ
  /F2
  13.2657 Tf
  19.932 0 Td
  [<0b450a3a0c2403c3029403bb0715037103cd03bb029403ef03da03bf03bd0377062c0ac5>] TJ
ET

このうち、テキストをページ上に書き出す機能を担うオペレータは、TJというやつです。 ページ上にテキストを描画するオペレータは、TJ以外にもたくさんあるんですが、このテキストセクションでは幸いにもTJしか使われていないみたいですね。

TJは、引数として配列を1つとり、その配列に含まれているテキストをいい感じにページに描画する、というオペレータです。 PDFのスタックマシンはPostScriptと同様に後置記法なので、TJの前にあるのが引数の配列です。 このテキストセクションには2つのTJオペレータがあり、それぞれ[(#1)]および[<0b450a3a0c..（省略）>]が引数の配列です。

さて、勘の良い人は気づいているかもしれませんが、最初の[(#1)]については、#および1という2つの「文字」からなるテキストそのものが引数として指示されているように見えます。 一方、2つめの[<0b450a3a0c..（省略）>]は、ちょっとこれだけを見てもどうやって文字を読み解けばいいのかわかりません。 つまり、同じテキストセクションにあり、同じオペレータの引数でありながら、両者では「文字」の読み方がぜんぜん異なるということです。

PDFのフォントリソース

実は、コンテンツストリームでTJオペレータなどで描画を指示されるテキストをどうやって読むかは、そのときのスタックマシンの状態に依存します。 したがって、上記のような文字列からTJの前にある[...]の部分を読み取ればテキストが得られる、というわけではありません。 スタックマシンを実装してコンテンツストリームをまじめに読むことになります。

説明だけすると、上記のテキストセクションに出てくる/F1とか/F2とかが「フォントリソース」を示しており、これによって以降のテキストの読み方が変化します。 そして、フォントリソースはコンテンツストリームの中を探しても見つからず、そのコンテンツストリームの場所を間接的に指示していたオブジェクトの中で、やはり間接的に指示されています。

ちょっと複雑に聞こえるかもしれませんが、要するに参照番号を逆向きに1つ戻るだけです。 いま見ているテキストセクションがあるコンテンツストリームがあるのはオブジェクト66で、その場所を示しているのはオブジェクト3でした。 オブジェクト3はこれです。

$ hpdft -r 3 NML-book.pdf
[
/Resources: 67
/Type: /Page
/Parent: 2151
/Cotents: 66]

見てのとおり、/Resourcesというエントリがあります。 このエントリが指し示しているオブジェクト67が、テキストセクションに登場するフォントリソースを探しに行くべきオブジェクトということです。

オブジェクト67を見てみましょう。

$ hpdft -r 67 NML-book.pdf
[
/ColorSpace: 4
/XObject:
  /Im24: 55
/Font:
  /F1: 56
  /F2: 58
  /F4: 59
  /F5: 60
  /F6: 62
  /F7: 64
  /F8: 65
/ProcSet: /PDF, /Text, /ImageC, /ImageB, /ImageI]

なんかそれっぽいのが出てきましたね！ どうやら、/F1については参照番号56、/F2については参照番号58をそれぞれ見ればいいようです。

まずは/F1のほうから調べます。

$ hpdft -r 56 NML-book.pdf
[
/Type: /Font
/Subtype: /Type1
/Widths: 2307
/FirstChar: 2.0
/LastChar: 121.0
/Encoding: 2351
/BaseFont: /IPQGNU+LucidaSans-Demi
/FontDescriptor: 2352]

いろいろな情報が含まれているんですが、いま知りたいのは「テキストの読み方」で、これを知るには/Encodingで示されているオブジェクト2351をあたります。

$ hpdft -r 2351 NML-book.pdf
[
/BaseEncoding: /WinAnsiEncoding
/Differences: 2.0, /fi, 30.0, /grave, /quotesingle, 39.0, /quoteright, 96.0, /quoteleft]

オブジェクト2351には、/BaseEncodingと/Differencesという2つのエントリがありました。 これらの情報が、/F1というフォントリソースで示されている「テキストの読み方」、つまりこの場合には、「[(#1)]を文字にする方法」になります。

まず、/WinAnsiEncodingというのは、Windowsの標準的なエンコーディング方式を示す名前として、PDFの仕様で定義されているものです。 ちなみに、いままで説明をさぼっていますが、スラッシュで始まる文字列はPDFの仕様では定義済みの名前を表します。詳しいことはPDFの仕様を見てね。

/Differencesとして示されている数字や名前が何かというと、これは/BaseEncodingに対する差分を表します。 つまりこの場合には、Windowsの標準的なエンコーディング方式を使うけど、いくつかの文字については個別に指定しておくからそっちを使ってくれ、という指示です。 /Differencesエントリの読み方を説明するのはめんどくさいので、これも詳しいことは仕様を見てね。

さて、/WinAnsiEncodingというのは、たまたま主要部分がASCIIの印字可能な文字のコードとほとんど一緒なエンコーディング方式です。 そのため、この例のフォントリソース/F1では、TJなどの引数に指定されている値はおおむねASCIIの文字コードそのものになります。 [(#1)]が#および1という「文字」そのものに見えたのは、TJにASCIIのような文字コードが指定できるからではなく、このような背景による結果です。

PDFの「テキスト」はフォント中のグリフの場所

そろそろ今なにをしていたのかわからなくなってきたと思うので、いま読もうとしているテキストセクションを再掲しておきます。

BT
  /F1
  12.4811 Tf
  125.585 -462.55 Td
  [(#1)] TJ
  /F2
  13.2657 Tf
  19.932 0 Td
  [<0b450a3a0c2403c3029403bb0715037103cd03bb029403ef03da03bf03bd0377062c0ac5>] TJ
ET

[(#1)]のほうはなんとなく読めたということにして、次は[<0b450a3a0c..（省略）>] TJのほうを見てみます。 こちらは16進表記の何かに見えますが、UnicodeのコードポイントでもUTF-8でエンコードされた値でもなさそうだし、いったいどう解釈すればいいのでしょうか？

とりあえず、/F2というフォントリソースがあるとされているオブジェクト58のようすを確かめます。

$ hpdft -r 58 NML-book.pdf
[
/Type: /Font
/Subtype: /Type0
/BaseFont: /LPZEOE+HiraKakuPro-W6-Identity-H
/Encoding: /Identity-H
/DescendantFonts: 57

今度は/Encodingが参照番号ではなく/Identity-Hという名前になっています。 実は、この/Identity-Hというのがなかなか曲者で、これは「フォントの指示そのままにテキストを描画してね」という意味合いになります。「そのまま」なので"Identity"なのです。

ここで再び、「文字」は「グリフ」ではない、という話を思い出してください。 /Identity-Hで指示されているのは、文字の読み方ではなく、「テキストを描画するときのグリフの見つけ方」です。 「フォントにおけるグリフの場所」は、いわゆる文字コードではなく、一般にはCIDとかGIDといった値として、フォントごとに定められています。 「そのフォントが定めているやり方で、TJみたいなオペレータによって指示されている数値をCIDとかGIDとみなし、その場所にあるグリフをPDFのページに描画すればよい」、というのが/Identity-Hの意味というわけです。

CID/GIDからUnicodeの値を知る

ここまでのおさらい。

  1. フォントリソースを見ることで、/Identity-Hというエンコーディング方式に従えばテキストが再現できるとわかった
  2. /Identity-Hでは、TJなどのテキスト描画のためのオペレータの引数の値をそのまま、フォントからグリフを見つけ出すときの値として使える

これって、「テキストセクションを解析して文字を手に入れたい」という要望にとってはデッドエンドに思えますよね。 フォントからグリフを取り出せるとして、それが何の「文字」なのか、どうやって知ればいいのでしょう？

この状況を打破するには、フォント中のグリフを指す値から文字コードを解決する方法、より狭く言えば「CID/GIDとUnicodeの対応関係のテーブル」が必要です。 そのような対応関係のテーブルは、一般にはCMapとかcmapと呼ばれていて、やはりAdobeが仕様を公開しています。

ここで気が付いてほしいのは、文字からグリフを探すとき、つまりPDFの生成時にもCMapが必要だということです。 つまり、PDF生成時に使ったCMapがわかれば、そのPDFのコンテンツストリームから「文字」を探し当てられます。

PDFから制作に使われたCMapを探し当てるには、大きくわけると次の2つの方針があります。

  1. PDFの中から生成に使ったCMapの名前を探す
  2. PDFの中に埋め込まれたCMapに相当する情報を探す

言い換えると、PDFの中を探って文字を取り出せるかどうかは、これらの情報を「PDFの制作者がPDFのどこかに用意してくれているか」によって決まるということです。 逆にいうと、このへんを考慮せずに作られたPDFでは、どんなに内部を解析しても意図通りには文字を取り出せません。

1の方針で作られているPDFでは、フォントリソースの/CIDSystemInfoというエントリでCMapが指示されています。 いろいろな種類があるのですが、日本語だとまあだいたいAdobe-Japan1というやつです。

2の方針で作られているPDFでは、フォントリソースの/ToUnicodeというエントリに、そのような対応表の「材料」を示したオブジェクトの参照番号が指示されています。 その材料をもとにCMapを再現することで、そのPDFから「文字」が取り出せます。

昨日の記事で触れた『PDFリファレンスマニュアル』の§5.9は、このへんの話をひととおり整理した内容なのでした。 PDFのストリームコンテンツを処理するスタックマシンを実装し、§5.9に従ってCMapをなんとかすれば、PDFから文字を取り出せます。

長くなってしまったので、今日はここで終わります。 まだ「文字」の話しかしていないことからわかるように、ここから「文字列」を取り出すにはもうひとがんばり必要になります。 明日はその話をする予定です。

PDFから「使える」テキストを取り出す（第2回）

昨日は、PDFの本来の用途は「人間がPDFをビューワーで開いて読む」ことなので、そこから文字を抜き出すのは一筋縄ではいかない、という話をしました。 ではどうすればPDFファイルの中からテキストを取り出せるの、というのが今日の話の出発点です。

まず昨日の記事で、「PDFには国際的な規格があり、これはAdobeから『PDFリファレンスマニュアル』という形で無償で入手できる」という話をしたことを思い出してください。 昨日は話のついでみたいな感じで書きましたが、実を言うと、このリファレンスの中に、「PDFファイルの中に書き込まれているグリフを表示するための情報からUnicodeなテキストを取り出す手法」がちゃんと書いてあるのです。 具体的には、『PDFリファレンスマニュアル第6版』の §5.9 "Extraction of Text Content"に、その情報が一応整理されています。

ただし、言うまでもないんですが、そこだけ読んでも何もわからないと思います。 何をどうすればいいと書いてあるのかを多少でも読み取るためには、そもそもPDFファイルの構造がどんなふうになっているのかを知る必要があります。

そこで、今日は「PDFファイルの構造」について話をします。 リファレンスマニュアルの§5.9に照らしてPDFからテキストを抜き出す方法についてはまた明日。

PDFのドキュメント構造

この記事を読んでいるような人にはよく知られているように、PDFファイルの主要部分は「ドキュメント構造」と呼ばれる論理構造です。 モノの本を読むと、ほかにもごちゃごちゃした話がいっぱい登場しますが、それらは効率的な描画とか一部分の変更とかに必要になる話で、ビューワーを作ったり、あるいはPDFを書き出すアプリケーションを作る人にとって意味があるやつです。 PDFのページの上に表示されている要素が欲しいだけなら、この「ドキュメント構造」の部分を読み解くことでだいたい手に入ります。

で、そのドキュメント構造、全体に「木構造」をしています。 木構造の「葉」や「節」にあたるのが、実際のページの中身や、その表示に必要なリソース、あるいはメタ情報なんかです。

これら「葉」や「節」は、まとめて「オブジェクト」と呼ばれます。 すべてのオブジェクトには「参照番号」がついており、その参照番号でオブジェクトからオブジェクトへのリンクが表現されていて、これにより木構造が形作られるという感じです。

わかったような、わからないような感じだと思うので、以降ではPDFのドキュメント構造のようすを実際に覗いてみましょう。

PDFのドキュメント構造をpdfToolboxで見る

PDFファイルはバイナリです。なので、テキストファイルを開いて構造を見てみる、というわけにはいきません。 なんらかのツールが必要になります。ぼくが知っているドキュメント構造を眺められるツールとしては、Callasソフトウェア製のpdfToolboxというアプリケーションがあります。

このpdfToolboxで「PDFの調査」というコマンドを実行すると、ドキュメント構造をこんな感じに閲覧できます。

f:id:golden-lucky:20191202111802p:plain

「文書ルートカタログ」という文字列が見えると思いますが、これが木構造のルートに相当します。 そのルートの下にある「Pages」が、各ページの中身となるコンテンツにつながるパスです。その下に「Kids」が何階層かあって、それらを幅優先で集めると、その順番でPDFの全ページが再現できます。 面白いですね。

PDFのドキュメント構造をhpdftで見る

pdfToolboxは有料です。けっこういいお値段がしますが、ドキュメント構造を眺める以外にもたくさんの実用的な作業ができるので、PDFを仕事で使う人、PDFに興味がある人なら買って損はないはずです。

とはいえ、昨日の記事でもふれたように、PDFは仕様がすべて公開されています。しかもPDF 1.x系なら無料です。 ドキュメント構造を眺めるくらいなら、この仕様を片手に自分でパーサを書くこともできます。 なので、書きました。

以降では、このhpdftでPDFのドキュメント構造を探訪していきます。

まずはルートを表示してみましょう。 ルートにも参照番号があるので、それを見つけることが自力でドキュメント構造を探訪するときの出発点です。

ルートの参照番号は、PDFファイルの末尾付近にあるトレイラーという部分を読み解くと見つかります。 hpdftでは--trailerというオプションでトレイラーのようすを表示できます。

$ hpdft --trailer NML-book.pdf
[(/Type,/XRef),(/Root,1),(/Info,2),
(/ID,43361acc723afdc07c2f55c7a56ebea9, 43361acc723afdc07c2f55c7a56ebea9),
(/Size,2401.0),(/W,1.0, 3.0, 2.0),(/Filter,/FlateDecode),(/Length,6232.0)]

中身を細かくは説明しませんが、 (/Root,1) というエントリがあるので、なんとなく「ルートの参照番号は1」とわかりますね。 ちなみに、常にルートの参照番号が1というわけではないので注意してください。 ルートの参照番号を知るにはトレイラーを読み解くしかありません。

参照番号がわかれば、その参照番号を持ったオブジェクトを見つけ出して、その中身を取り出せます。 hpdft でも、-rオプションで参照番号を指定することで「オブジェクトのようす」を観察できるようになっています。

参照番号1のオブジェクトのようすを覗いてみましょう。

$ hpdft -r 1 NML-book.pdf
[
/OpenAction: 3, /Fit
/PageMode: /UseOutlines
/PageLabels:
  /Nums: 0.0,
    /S: /D, 4.0,
    /S: /D
/Names: 2124
/Outlines: 2125
/Pages: 2149
/Type: /Catalog]

やはり中身を細かくは説明しませんが、いくつかの「名前と値の組」からなっている雰囲気が読み取れると思います。 さきほどpdfToolboxのGUI画面で見たルートの状況と同じ構造になっていることがなんとなくわかりますよね。

ここで注目してほしいのは、「/Pages: 2149」の部分です。 ルートオブジェクトからは、/Pagesエントリで示される参照番号をたどることで、PDFのページを構成する中身を見つけ出せます。 これが2149を指し示しているので、次は参照番号2149のようすを見てみます。

$ hpdft -r 2149 NML-book.pdf
[
/Type: /Pages
/Count: 122.0
/Kids: 2150, 2186, 2230, 2270
/MediaBox: 0.0, 0.0, 419.53, 595.28]

次は /Kids です。 /Kids には複数の参照番号が並んでいますが、それぞれの下に、PDFのページを構成する中身がまた入れ子になっています。 とりあえず参照番号2150を見てみましょう。

$ hpdft -r 2150 NML-book.pdf
[
/Type: /Pages
/Count: 30.0
/Parent: 2149
/Kids: 2151, 2159, 2169, 2178]

また /Kids が出てきましたね。 参照番号2151のパスを見にいくことにします。

$ hpdft -r 2151 NML-book.pdf
[
/Type: /Pages
/Count: 7.0
/Parent: 2150
/Kids: 3, 2152, 2154, 2156]

まだ /Kids です。 先頭の参照番号3を見てみます。

$ hpdft -r 3 NML-book.pdf
[
/Resources: 67
/Type: /Page
/Parent: 2151
/Contents: 66]

ついに /Kids がなくなり、代わりに /Contents という、それっぽい名前のエントリが出てきました！ ためしに、/Contentsが指し示す参照番号66を見てみます。

$ hpdft -r 66 NML-book.pdf
[
/Filter: /FlateDecode
/Length: 381.0,
   q .913 0 0 .913 0 595.276 cm q 462.33906 0 0 655.95015 -3.064 -652.208 cm
/Im24 Do Q 1 G 1 g BT /F1 12.4811 Tf 125.585 -462.55 Td[(#1)]TJ /F2 13.2657
Tf 19.932 0
Td[<0b450a3a0c2403c3029403bb0715037103cd03bb029403ef03da03bf03bd0377062c0ac5>]
TJ ET 0 G 0 g 1 G 1 g BT /F4 10.5206 Tf 395.991 -462.55 Td[(\024)]TJ /F5
10.5206 Tf 7.302 0 Td[(een)]TJ ET 0 G 0 g 1 G 1 g BT /F1 12.4811 Tf 125.585
-485.638 Td[(#2)]TJ /F2 13.2657 Tf 19.932 0
Td[<03cd03bb029403ef03da03bf03bd>]TJ /F1 12.4811 Tf 96.842 0
Td[(in)-318(Ruby)]TJ ET 0 G 0 g 1 G 1 g BT /F6 11.0547 Tf 302.652 -485.638
Td[<0bf0>]TJ /F7 11.0547 Tf 11.055 0 Td[<0e8a>-296<0fe80925>]TJ ET 0 G 0 g
0.925 0.945 0.745 RG 0.925 0.945 0.745 rg BT /F8 25.1057 Tf 83.065 -615.417
Td[(Vol.1,)-301(No.3)]TJ /F8 12.4811 Tf 0 -15.392
Td[(Nov)-301(.)-373(2019)]TJ ET 0 G 0 g Q
]

なにやら何か謎の文字列が出てきました。 これが、PDFのページ上に表示されているものの正体です。 ここまで、常に/Kidsのいちばん左側に指示されているオブジェクトをたどって木構造を降りてきたので、これはPDFの1ページめに相当します。

さて、この文字列をよーく眺めていると、何か察しがつくのではないでしょうか。 そう、この文字列の中には、「PDFのページ上に表示されているテキストっぽいもの」が紛れています。 いかにも文字っぽいアルファベットのようなものも見えますが、それだけでなく、16進表記された数値や、バックスラッシュを前置された8進表記の数値なども、文字を表しているような感じがします。

『PDFリファレンスマニュアル第6版』のセクション5.9 "Extraction of Text Content"には、ここからUnicodeの文字をどうやって取り出せばいいかが書かれているのです。 明日は、いよいよ、その情報を使いながらPDFからテキストを取り出す方法について考えます。

PDFから「使える」テキストを取り出す（第1回）

PDFからテキストを取り出すのは、意外と大変です。 それにはいくつかの理由があるのですが、もっとも根本的な点で真っ先に解決が必要になるのは、人間が雑に文字としてみなしている絵（「グリフ」）をコンピューターで扱えるような「文字」にする方法です。

これには2つのアプローチが考えられます。

  1. PDFビューワーでファイルを開いた状態から何とかしてテキストを読み取る
  2. PDFファイルの中身を解析してテキストを抜き出す

このうち2つめの話は明日以降にして、今日は1つめの話をします。

PDFビューワーでファイルを開いた状態から何とかしてテキストを読み取る方法

この方法は、言ってみれば、人間もしくは人間のように振る舞うソフトウェアによりPDFビューワーの表示を「視覚的に読む」ということです。 これはPDFの本来の使い道に即した手法です。 PDFというのは、グリフ（文字の形）をページ上に表示するための汎用の仕組みだからです。

ここで厄介なのが、グリフは文字そのものではない、という点です。 「文字そのもの」と書くと哲学的に聞こえますが、ここでは「さまざまなコンピューター環境の間でやり取りして文字としての意味が保たれるようなもの」くらいの意味だと思ってください。 ようするに、「コンピューターで扱えるように表現されてる文字」です。

このように「文字」を定義すると、「PDFからテキストを取り出す」という目標は、「PDFファイルをビューワーで開いたときに表示される絵から、文字を手に入れる」と言い換えられます。 「文字」をもうちょっと狭く、「なんらかの符号化方式でUnicodeの文字集合のどれかを表してる情報」だとすれば、「PDFファイルからUTF-8のテキストデータを手に入れる」と言ってもかまわないでしょう。

さて、なんでこんな回りくどい話をしてるんでしょうか。 それは、「人間がPDFをビューワーで開いて読む」というのが、コンピューターにとってはそんなに自明な話ではないことを強調したいからです。 人間は通常、PDFを目で読むわけですが、そのときは「文字」、つまりコンピューターで扱えるような表現としての文字を抜き出しているわけではありません。 そして、PDFはもともと人間が目で見るドキュメントのために作られたデータフォーマットなので、そもそもコンピューターで扱えるような文字を取り出しやすいようにはできていないのです。

人間がPDFを読むように、コンピューターでPDFのページに表れる「グリフ」をいい感じに「文字」にする方法があれば、PDFからテキストを取り出せます。 そのための方法としていま利用できるのは、いわゆるOCRくらいでしょう。

ちなみに、PDFビューワーで開いて文字列を選択してコピペする、みたいな方法は、コンピューターでコピペの操作の対象になるのがそもそも「グリフ」ではなく「文字」なので、人間がPDFを読むのとはまったく違う作業です。 PDFからコピペしたら意図した文字とは違う文字しか取れなかった、という経験がある人も多いと思いますが、これはまさにPDFに表れている「グリフ」は「文字」ではないことによります。 ちなみに、フォントが埋め込まれているかどうかはまた別の話で、フォントは埋め込まれているけど意図通りにコピペできない、みたいな例もよくあります。

というわけで人間のようにグリフから文字を取り出すにはOCRするしかないと思うのですが、これには物理装置の認識精度みたいな手元のパソコンで気軽に手を出しにくい要素も絡むので、あまりちゃんと調査してません。 ただOCRかどうかに限らず、「人間のようにPDFのグリフから文字を取り出す」手法は画像解析やAIの応用が進めばかなり未来がある方法だと思うので、いつか取り組みたいと思います。

PDFの仕様について（ちょっと脇道）

ところで、PDFのビューワーといえばAdobeのAcrobatなんですが、これはみんなが想像している以上にすごいツールです。 PDFファイルをできるだけ正しく閲覧するには、現時点ではAdobe社の技術に頼るしかありません。

で、いま「PDFファイルをできるだけ正しく」と言いましたが、正しいとか正しくないとか言えるのは、PDFに国際的に標準化された仕様があるからです。 国際標準化機構、つまりISOによる現在の最新のPDFに関する仕様はISO 32000-2:2017で、これはPDF 2.0というバージョン名で呼ばれています。

ただ正直なところ、PDF 2.0に準拠して生成されたPDFはぼくの周りにでは滅多に見かけません。 なにより、ISO 32000-2:2017の仕様書はISOから購入しなければならず、ぼくはこれを購入してないので、PDF 2.0についての話はこれでおしまいです。 以降、PDFといったら、それはPDF 1.x系列に準拠したPDFのことを指します。

そのPDF 1.x系列は、最終バージョンがPDF 1.7で、これはISOの標準化としてはISO 32000-1:2008に相当します。 それより前、つまりPDF 1.6よりも若いバージョンの仕様は、ISOによって標準化されたものではなく、Adobeによるプロプラな仕様でした。

そもそもPDFは、「さまざまなシステムで同じ見た目で表示できるドキュメント形式」を目指してAdobeが開発したファイル形式です。 PostScriptと同じことができる軽量で高速なドキュメント形式として考案されたらしいんですが、いつの間にかPostScriptそのものより多機能になってしまいましたね…。 Acrobat以前の歴史はわりと面白いので、みんなこの記事を読むといいと思います。

ありがたいことに、AdobeではPDFの仕様に対するリファレンスを無償で配布してくれています。 PDF 1.7についてAdobeが配布しているのは、PDFリファレンスの「第6版」です。 1.7なら第7版になりそうなものなんですが、PDFのバージョンを1.2にしたときにAdobeではPDFリファレンスを第2版にせず第1.1版にしたので、それからずっと1ずれてしまっています。

というわけで、現時点のPDFについて何か調べたいと思ったら、ISO 32000:1:2008であるところのPDF 1.7の仕様を網羅したPDFリファレンス第6版にあたることになります。 PDF形式で配布されているので、必要に応じてAcrobatで開いて見てもいいんですが、1310ページもあると紙でめくったほうが目的の情報に素早く行き当たるので、当社ではすべて印刷してパラパラ眺められるようにしています。

f:id:golden-lucky:20191201001415j:plain

明日は「PDFファイルの中身を解析してテキストを抜き出す」について書ければと思います。