简而言之:
PDF 中的所有信息都表明,您在 PDF 中以破折号形式看到的字形实际上代表了一个两个。因此,要以不同方式解释这些字形,您必须从根本上更改 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 映射到 代表 Unicode 代码 0x0032 再次是 '2'。
如果 /ToUnicode 映射不存在,文本提取程序可能会使用 PDF 对象 22 0 中的 /Encoding 定义。但这里又是:
22 0 obj
<<
/Type /Encoding
/Differences [44 /comma 50 /two]
>>
这里的 '2' = 50 映射到名为 /two 的字形,这再次使该字形成为 two。
因此,PDF 中除字形绘图定义本身之外的所有信息(理论上可以通过 OCR'ing 进行检查)表明破折号字形确实是一个两个。
要使文本提取程序更符合您的喜好解释该字形,您应该将 的 /ToUnicode 映射替换为例如。不幸的是,映射是编码的(使用过滤器/FlateDecode),因此这不是一个简单的十六进制编辑器工作,而是需要解码等......