原位 PDF 重构 — 为何这是 DTP 中最艰难的工作
最艰难的 DTP 工作是没有源文件的情况。法语纳税申报表、德语 CE 安全传单、临床患者信息传单(PIL)、专利文件——所有这些都是客户从监管机构或代理机构收到的 PDF,背后没有可编辑的 InDesign 或 Word 原文件。大多数翻译机构的处理方式是将文本提取到 Word 文档中进行翻译,然后将译文作为新文档发回,该文档与监管机构的模板不匹配。这对于备案提交是不可接受的——监管机构期望收回原始表格的目标语言版本,看起来与原件完全一致。
技术难题
PDF 不以文本形式存储文本。它们将文本存储为一系列字形操作:「在坐标 (123, 456) 处用 Helvetica 字体绘制字符 67」。大多数机构使用 PDF 到 Word 转换器,这会丢失坐标信息和字体引用;结果虽然可编辑,但在视觉上与源文件无关。更高级别的机构使用 Adobe Acrobat 的「导出到 InDesign」——这保留了更多布局,但在三类内容上会出现问题:
- 轮廓字形。许多监管表格(impots.gouv.fr、德国 Steuererklärung、AEMPS)在发布时将文本标签转为矢量路径轮廓。Acrobat 的提取器将轮廓文本读取为图形而非字符串。译者看不到字段标签,监管机构也看不到其模板的译文。
- 表单字段。AcroForm 和 XFA 字段有其自己的文本和字体引用。提取周围文本但不提取字段标签会产生半翻译文档。
- 扫描混合文档。部分矢量、部分光栅的 PDF(典型情况是监管机构提供的带有扫描签名块的文档)需要对光栅部分进行 OCR,并对矢量部分进行保留坐标的提取。单一工具无法同时处理两者。
我们的引擎
我们专门为此类别构建了 PDF 引擎。它枚举 PDF 中的每个文本绘制操作,包括轮廓字形(通过检测常见标签字体并将路径反向映射回字符)、读取表单字段标签和工具提示、对光栅区域运行 OCR,并生成逐跨度翻译清单。译者在清单中工作;引擎将译文写回源坐标处。表单字段得以保留;监管机构看到的是相同表格的目标语言版本,带有正确的字段标签。
交付成果
看起来像法语纳税申报表的法语纳税申报表。符合德国监管机构模板的德语 CE 传单。EMA 首次审查即可接受的患者信息传单。我们为此而生;大多数机构并非如此。