PDF：異なるToUnicode Cmapsでフォント名が重複する

Question

PDFファイルを解析して一部のテキストを抽出していますが、「C2_0」という名前のフォント辞書に遭遇しました。この辞書にはCIDFont（タイプ0）にToUnicode CMap。だから問題はありません。ToUnicode CMapを解析し、2バイトの文字コードをUnicode値にマップするツールがあります。

しかし、PDFファイル、後で別のToUnicodeのCMapを含んでも「C2_0」と呼ばれるある別フォント辞書オブジェクトを含みます。私は2番目のCMapをどのように処理すべきか、実際には思いつかなかったので、両方のCMapsからのエントリを推測して組み合わせました。これは実際に働いて、テキストを正しく抽出しました。

しかし、これは許可されているか、この状況に対処しているものはPDFリファレンスマニュアルには見つかりません。私は重複したフォント名が不特定の動作につながると思っていたでしょう。私は長時間の推測としてそれらを組み合わせることを試みた - それは実際に働いて驚いた。

誰もこの経験がありますか？ PDFがTfオペレータによって呼び出されたときに「結合」する異なるCMapsを持つ異なるオブジェクトを参照する重複フォント名を持つことが許可されているかどうかは知っていますか？

Answer 1

C2_0は/ Fontリソースディクショナリのシンボリック名であり、ローカルスコープを持ち、リソースディクショナリが属するコンテンツストリームでのみ使用されます。 C2_0が別の/ Fontリソース辞書にも現れても問題はありません。あなたに
は、フォント/同じリソースディクショナリに2件のC2_0のエントリーがあります。
/C2_0 X 0 R
/C2_0 Y 0 R
を振る舞いが定義されていないので、あなたは問題を抱えているとどのようにそれはあなた次第です状況を処理する。
シンボリック名解決は次のように動作します。ページコンテンツストリームにある場合は、ページのリソースディクショナリのフォントシンボル名（Tfオペランド）を検索します。見つけられない場合は、ページツリーに移動して、各親ページノードのリソースディクショナリ（存在する場合）を検索します。ページツリーの上部に達していて、フォントが見つからなかった場合、その動作は未定義です。この時点で、さまざまなフォールバック戦略を実装できます。デフォルトのフォントを使用したり、ページ上のフォームXObjectsに含まれるリソースを検索したり、他のページのリソース辞書を検索したりすることができます。

Answer 2

あなたがpdftkのようなツールを1に2つのPDFファイルを連結する場合は簡単に起こるかもしれない記述何...あなたは「完璧」ではない野生で多くのPDFファイルを見つけること

残念です。

重複したフォント名は、必ずしも不特定の動作につながるわけではありません.PDFリーダーの巧みさによって異なります。 PDFリーダーは、コンテンツをレンダリングするときに各フォントのオブジェクトIDを考慮に入れることができます。または、フォント名のみに依存することでそれを混乱させることができます。