PDFMiner读取TCPOS生成的“相同”PDF文件出现提取差异问题

场景 #

• 大量PDF由TCPOS自动生成，每个PDF对应一类汇总信息，标题显示在首页。
• 所有PDF为自动生成，假设文件结构完全一致。
• 为分类整理，使用Python脚本根据PDF内容将文件归类到对应文件夹，第一步是读取每个PDF的标题，代码如下：

with open(file, 'rb') as pdf_file:
    output_string = StringIO()
    doc = PDFDocument(PDFParser(pdf_file))
    rsrcmgr = PDFResourceManager()
    device = TextConverter(rsrcmgr, output_string, laparams=LAParams())
    interpreter = PDFPageInterpreter(rsrcmgr, device)

    for page in PDFPage.create_pages(doc):
        interpreter.process_page(page)
        break

pdf_text_form = output_string.getvalue()
pdf_title = pdf_text_form.split()[0]

• 上述代码提取PDF文本的第一个单词，此前对所有PDF都有效，仅一个文件例外。
• 正常PDF的pdf_text_form示例：

Title_of_some_summary

Location_of_facility
1 Full visibility

Shops:
Registers:
Waiter:
Visibility:

Registers
Register
Shop

...

• 异常PDF的pdf_text_form示例：

Location_of_facility
1 Full visibility

Title_of_some_summary

Shops:
Registers:
Waiter:
Visibility:

Registers
Register
Shop

...

• 视觉上异常文件与正常文件完全一致，但正常文件中pdf_title能正确获取汇总标题，异常文件却获取到设施位置（视觉上的第二行，却是PDFPageInterpreter识别的第一行）。
• 推测是TCPOS生成的PDF格式异常，将两类文件转为XML对比，除内容外仅发现字体FamilyName前缀不同（TPLTAU vs VRASAU），XML示例如下：

<Glyphs OutlineWidth="0.5" CharSpace="0" RenderTransform="1 0 -0 1 35.7165 62.340027">
    <Font SizePoints="36" Style="Regular" FamilyName="TPLTAU+Calibri,Bold" Capitals="Normal" ResourceId="1" />
    <Origin X="0" Y="0" />
    <Text>Title_of_some_summary</Text>
    <Size Width="265.81628" Height="36" />
    <Brush>
        <SolidBrush Color="#FFEA0000" />
    </Brush>
    <Tag>convertedFont</Tag>
</Glyphs>

• 除字体前缀和实际文本内容外，其余XML内容完全一致。

问题 #

究竟是什么原因导致该异常？怀疑是PDFMiner的bug，但也不排除TCPOS的问题或人为错误。

原因分析 #

这种异常的核心原因大概率是TCPOS生成PDF时，文本内容的绘制顺序与视觉顺序不一致，而非PDFMiner的bug。

PDF的文本提取逻辑依赖于内部的内容流顺序：PDFMiner是按照PDF文件中内容对象的写入顺序来提取文本的，而非视觉上的从上到下顺序。视觉上的排版是通过坐标定位实现的，但内容流的写入顺序可以和视觉顺序完全无关。

你观察到的字体前缀差异只是表象：TCPOS在生成这个异常PDF时，先写入了设施位置的文本内容，再写入标题文本，虽然通过坐标设置让标题显示在视觉最上方，但内容流的顺序是反的，导致PDFMiner提取时先拿到了设施位置的文本。

字体前缀的不同可能是TCPOS在生成该PDF时调用了不同的字体嵌入逻辑，但这和文本提取顺序异常没有直接关联，只是巧合出现的差异。

人为错误的可能性极低，因为是批量自动生成的文件，更可能是TCPOS的生成逻辑在某些特定条件下（比如特定设施名称、汇总标题长度等）出现了内容流顺序错乱的bug。

内容的提问来源于stack exchange，提问作者Mantas Kandratavičius