手短に:
PDF 内のすべての情報は、ダッシュとして表示される PDF 内のグリフが実際に2を表していることを示しています。したがって、これらのグリフを別の方法で解釈するには、PDF のフォントでその文字の値から Unicode へのマッピングを根本的に変更するか、光学式文字認識に頼る必要があります。
詳細に:
PDF pg_0001.pdf のコンテンツ ストリームの、あなたがマークした単語が含まれている部分を調べてみましょう。
作成されます:
0 -1.1065 TD
[(Fibroblast)-241.2(growth)-234.1(factor-21)-237.3(\(FGF-21\))-242.3(activity)-233.9(in)-237(High-fat)-237.9(diet)-234.9(\(HFD\))-238.3(fed)-234(ApoE)]TJ
/F6 1 Tf
6.7246 0 0 5.9768 357.3354 542.4944 Tm
(2)Tj
/F4 1 Tf
.8346 0 TD
(/)Tj
/F6 1 Tf
.3372 0 TD
(2)Tj
/F4 1 Tf
8.9663 0 0 8.9663 372.9826 538.5259 Tm
[(mice)-235.6(with)-233.5(adiponectin)-240.8(\(Acrp30\))-237.6(knockdown.)]TJ
ここでの特殊文字は、実際にはそれぞれフォント/F6の文字 '2' (= 50 = 0x32) で表されます。
ここでの文字列の文字から実際に印刷されたグリフへのマッピングは非常に恣意的であり、正しい解釈のヒントがあるかもしれないため、そのページのフォント/F6の定義を調べる必要があります。
<<
/FirstChar 44
/ToUnicode 21 0 R
/Encoding 22 0 R
/FontDescriptor 23 0 R
/BaseFont /KAHBDA+AdvP7DA6
/Subtype /Type1
/LastChar 50
/Type /Font
/Widths [833 0 0 0 0 0 833]
>>
そのため、テキスト抽出プログラムがコンテンツ ストリーム内の文字を解釈するために使用する/ToUnicodeマッピングによって、フォントが拡張されます。そのマッピングを見てみましょう。
/CIDInit /ProcSet findresource begin 12 dict begin begincmap /CIDSystemInfo <<
/Registry (F6+0) /Ordering (T1UV) /Supplement 0 >> def
/CMapName /F6+0 def
/CMapType 2 def
1 begincodespacerange <2c> <32> endcodespacerange
2 beginbfchar
<2c> <002C>
<32> <0032>
endbfchar
endcmap CMapName currentdict /CMap defineresource pop end end
したがって、ここでの '2' = 0x32 は <0032> にマップされ、Unicode コード 0x0032 を表し、再び '2' になります。
/ToUnicodeマッピングが存在しない場合、テキスト抽出プログラムは代わりに PDF オブジェクト 22 0 の/Encoding定義を使用できたはずです。
22 0 obj
<<
/Type /Encoding
/Differences [44 /comma 50 /two]
>>
ここで '2' = 50 は/twoという名前のグリフにマッピングされ、これにより再びそのグリフはtwoになります。
したがって、グリフ描画定義自体を除いた PDF 内のすべての情報 (理論的には OCR で確認できます) は、破線グリフが実際に2であることを示しています。
テキスト抽出プログラムがそのグリフを好みに合わせて解釈するようにするには、<32> の/ToUnicodeマッピングを、たとえば <002D> に置き換える必要があります。残念ながら、そのマッピングは (フィルター/FlateDecodeを使用して) エンコードされているため、簡単な 16 進エディターの仕事ではなく、代わりにデコードなどが必要です...