停止在渲染时解析 PDF
大多数前端 PDF 提取工具都失败了。
开发者试图从视觉输出中猜测文档结构。他们观察渲染后的像素来寻找列、表格或列表。他们利用计算机视觉或像素邻近度来决定一个框的起始位置。
这种构建方式是错误的。
PDF 的操作流（operator stream）中已经包含了明确的结构化数据。表格不仅仅是一组相邻的像素。它是通过特定的命令（如 moveTo、lineTo 或 rectangle）绘制出来的。你想要寻找的边界已经编码在源文件中了。
如果你的提取器在 100% 缩放和 150% 缩放时给出的列不同，那么你提取的就不是结构，而是在对视觉伪影进行模式匹配。
停止使用视觉启发式方法。开始解析操作流。
为什么操作流更好：
- 它是确定性的。无论缩放比例或字体微调（font hinting）如何，其工作方式都是一致的。
- 它使用真实数据。你使用的是由创建者定义的实际路径和坐标。
- 它避免了数学错误。例如，使用文本中心点之间的中点来寻找区域会导致舍入错误（rounding bugs）。使用边界框（bounding box）的实际顶边才是唯一正确的方法。
难走的路才是正确的路。
你必须理解 CTM 栈。你必须跟踪矩阵状态并对子路径（subpaths）进行分类。你必须阅读 PDF 规范和源代码才能掌握它。
这在前期需要投入更多精力。但它适用于用户上传的每一个 PDF。基于像素的工具只能对你测试套件中的少数文件有效。
构建一个真正的提取器，而不是一个演示 Demo。