golden-luckyの日記

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

なんでドキュメントといったらXMLが出てくるのか

昨日は、ドキュメントにおける構造というのはセマンティックな構造である、という話をしました。 今日は、そのセマンティックな構造をどう扱うか、という話です。

ドキュメントの構造は一般にXMLを使って表されている

結論から言うと、ドキュメントの構造は、XMLで扱うのが一般的です。 ドキュメントの構造を表すのにXMLがよく使われているのには理由があって、それは、ドキュメントが木構造だからです。

本当はここで「XMLとは何か」みたいな話をする必要があると思うんですが、ここではXMLというのは「木構造のデータを表現するときの標準的な構文」くらいの意味で使います。 つまり、表現する「木構造のデータが具体的にどんなか」については別の問題ということにして、木構造で表せるようなデータにとって共通で必要そうな構文だけを定めたものが、（ここでいう）XMLです。

ちなみに、「木構造のデータが具体的にどんなか」のほうは、「XMLアプリケーション」と呼ばれます。 XMLアプリケーションとしては、HTML（正確にはXHTML）とかMathMLとかDocBookとかがあります。 XMLアプリケーションを定義するには、一般にはDTDとかXML SchemaとかRELAX NGとかいった「スキーマ」を使います。 上の段落で言いたいことは、そういったスキーマを使って定義されたXMLアプリケーションが何であるかを本記事では気にしない、ということです。

ドキュメントの木

よくわからないと思うので、ドキュメントの木構造を例に説明します。 ドキュメントの木構造といって想像するのは、たぶんこんなのでしょう（適当に描いたのでツッコミはなしで）。

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

緑色の葉に相当するのがインライン要素、そのインラインの要素が集まったものが茶色の節に相当するブロック要素、ブロック要素が集まってドキュメントになる、という感じです。

ただ、この単純なイメージだと、「インライン要素にどんなものがあるか」、「ブロック要素にどんなものがあるか」、「それらをどう組み合わせていいか」といった具体的な木の形状までは説明できてません。 実際に必要な要素が何であるか、要素の組み合わせとして何を認めるかは、ドキュメントの用途や種類によってまちまちです。

とはいえある程度までは、ドキュメントが必要とされる分野ごとに「汎用性のある要素の組み合わせ」みたいなものは考えられるでしょう。 そういう「汎用性のある要素の組み合わせ」を考えるということは、木構造を制限するということです。 その手段がXMLアプリケーションです。

言い換えると、ドキュメントがどんな形状の木になりうるかをXMLアプリケーションとして制限する、という世界観です。 たとえば、技術書のために必要な制限を課したXMLアプリケーションとしては、DocBookがあります。

（木構造ではないドキュメントもありうるとは思うんですが、それはここではドキュメントではないものとします。どう考えても木構造とみなすのが適切でなさそうなドキュメントがあったとして、それをコンピューターでどう扱えばいいかという話も面白そうだけど、そういう話はどこかにあるのかなあ。）

XMLは山かっこでなくてもいい

ここまでの話を整理すると、こうなります。

  • ドキュメントは木構造
  • どんなドキュメントかに応じて木構造を制限したい
  • それに都合がいい仕組みとしてXMLがある

どうでもいい話に聞こえるかもしれませんね。 なんでわざわざこんなことをくどくど書いてるかというと、これらの話にはXMLの象徴である「山かっこの記法」が出てこないことを強調したいからです。 実際、こういう枠組みを実現するのに、記法が山かっこタグである必要はありません。

XMLで表せる木構造は、文字通り「構造」であり、記法とはレイヤが違います。 XMLの世界観だと、「XMLアプリケーションごとにスキーマで定義した構文」のほうが記法に相当します。

もっとも、この「XMLアプリケーションごとにスキーマで定義された構文」もXMLと見た目は同じ、つまり、通常は山かっこタグになります。 記法についてはドキュメントの構造とは別に考えるべきだけど、XMLでは両方とも同じ記法を採用している、みたいな感じです。 ドキュメント屋さんとして、XMLを使うときはこの辺りの事実からは逃れられない感じです。

ただ、ぶっちゃけ木構造を表すなら、山かっこタグよりも優れたシンタックスがあります。そう、S式です。 S式をシンタックスとするXMLをSXMLといいます。

というわけで、明日はLispの時間です。

ドキュメント技術とプログラミング言語の相似について

よく知られているように、ドキュメントには「構造」があります。 WebページではHTMLとCSSにより構造とスタイルを分離するべきとか、Wordでは書式設定をスタイルとして定義して使うことで構造とスタイルを分離するべきとか、ドキュメントの「べき」論で必ず言及される「構造とスタイルの分離」における「構造」です。

昨日までの話ではPDFにもドキュメント構造というのが出てきました。あれは、この「構造とスタイルの分離」というときの「構造」とは別物なので注意してください。 たぶん、PDFのドキュメント構造には、「ドキュメントを表すデータ構造」くらいの意味合いくらいしかありません。

一方、ドキュメントの話において「構造とスタイルの分離」というときの「構造」は、もうちょっとこうなんていうか、セマンティックな話です。 データをどう構成するかではなく、ドキュメントで表したい意味をどう構成するか、という話。

したがって、ドキュメントの話をするときは、「ドキュメントで表したい内容」を「ドキュメントの最終的な見た目」みたいなフワフワから切り離すことで、前者の可搬性を高めていくことが目指されます。

話はちょっとずれるんですが、コンピューターで扱うドキュメントの話をするときって、「可搬性を持たせたい部分がどこか」という点がわりと曖昧なままになってることがあるので、その点に注意して聞くといいと思います。 PDFは、見た目の可搬性から出発していました。 「構造とスタイルの分離」の話では、構造の可搬性を目標にします。まあ、あんまりこっちの話をするときは「可搬性」という用語は使わず、再利用可能性とかいうことが多いので、混乱はないと思うけれど。

構造とスタイルと記法

コンピューターでドキュメントを扱う話をするときは、「構造とスタイルの分離」がどれくらいかっちりできてるかで、技術の素性の良さみたいなのが語られがちです。 つまり、構造とスタイルの分離っていうのは、ドキュメント技術においてはある種の金科玉条です。

まあ最近だと、「金科玉条でした」と過去形で書くほうが正解なのかもしれませんね。 いまの流行りは構造とスタイルの分離でなく、書式とか記法、つまりシンタックスに移っているようなので。

しかしドキュメントにおけるシンタックスって、結局のところ、ドキュメントのセマンティックな構造を暗に埋め込むためにどんな表現を使うか、という話なんですよね。

ドキュメントの構造を暗に表現するシンタックスの話については、このアドベントカレンダーでいつか話す予定です。 いまは何が言いたいかというと、構造とスタイルの分離を重視する立場だと、「人間の直観を裏切らない記法」みたいな観点はそれほど重視されません。 一方で、人間が編集しやすい記法が何かという話に注力してしまうと、それはそれでドキュメントにおける構造とスタイルの分離の伝統とは違う話をしてしまう可能性が高い。

なにが言いたいかというと、これからのドキュメント技術について語るときの前提は、「記法」「構造」「見た目」の3つのレイヤを意識したモデルに依拠するといいのかな、ということです。

ドキュメント技術の3階層モデル

だんだん与太話っぽくなってきましたが、「シンタックス（記法）」→「セマンティクス（構造）」→「スタイル（見た目）」という3つの階層でいろんなドキュメント技術を考えるのは、わりと建設的なモデルなんじゃないかなと個人的には考えています。

個人的にこのモデルが特に気に入ってるのは、プログラミング言語における「ソースコード」→「抽象構文木」→「実行ファイル」の関係によく似ている点です。 プログラミング言語に似ているということは、コンピューターでドキュメントを扱う方法について考察するときに都合がいい。

たとえば、プログラミング言語だと、この階層の矢印を逆方向にたどるのが無理筋だということをみんながよく知っています。 ふつうの人が直接触れるのは最下層のみだけど、階層を下にいくにつれて、その中身は人間が理解しにくいモノになっていく。 これがドキュメント技術の話になると、どの階層を見ても人間が読む文字が見えるので、似たような階層があることに気が付きにくい。 意識的に層の違いを強調してあげる必要があると思うんですが、そこで「プログラミング言語における「ソースコード」→「抽象構文木」→「バイナリ」の階層みたいな感じ」といえば、なんとなく伝わりそうな気がします。

階層を下に降りるほど編集の自由度がなくなるという点も、ドキュメントの3階層がプログラミング言語に似ているところだと思います。 PDFを直接いじることが煩雑かつ（ドキュメントの可搬性にとって）危険であることは何となく昨日までの記事で伝わってると思うんですが、これはドキュメントの「シンタックス（記法）」→「セマンティクス（構造）」→「スタイル（見た目）」という階層で考えれば「プログラムの実行ファイルを直接いじる」のと同じ話なわけで、なんとなく当然の成り行きであることが伝わりやすい気がします。 大変かつ危険だけど、条件によっては安全に実行するすべがないわけでもないので、その必要がある場合にはそのためのPDF編集ツールを導入してください、という話がしやすいでしょう。

編集者の仕事は各階層をそれぞれがんばること

この見方でポジショントーク的に説明しやすいことがもう一つあって、それは、プログラミング言語で実行環境に相当する部分はドキュメント技術では人間の脳である、という点です。 そう考えると、編集者の仕事っていうのは、「人間の脳におけるドキュメントの実行を最適化するために各階層で手を尽くすこと」に見えてこないでしょうか？

プログラミングにおいては、シンタックス、セマンティクス、スタイルの各階層だけでなく、その上、つまりアルゴリズムの改良とかデータ構造の工夫も重要です。 たぶん、ドキュメントの仕事でそれに近いのは、文章のリライトとか、いわゆるトンマナの調整、それに校正なんかなんでしょう。

さらに上の階層、そもそも現実の問題をどんなアプリケーションとして作ればいいのかを含めた設計に相当する部分は、ドキュメントでいうと企画ですね。

最後はちょっと強引に編集者の仕事論っぽい話をしてみました。 明日は構造化文書の本丸、XMLの話です。

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

去年に引き続き会社の近況報告をしようと思って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から文字を取り出せます。

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