PDF 看着是文档,里面全是坐标

PDF 看着是文档，里面全是坐标

客户发来一个 PDF，附一句「按这个改，版式别动」。

你打开看，排版规整，目录自动生成，页眉页脚都在。文件看起来只差把字换掉。真正丢进解析器才会发现，这份文件里没有段落，没有表格，没有阅读顺序，只有几千条「在某个位置画某个字」的指令。

它记的是画面

PDF 的设计目标很单纯，在任何设备上打开、打印，结果都一样。为此它把「这段文字是什么」让位给「这段文字摆在哪」。

一段话在 PDF 里是若干条独立的绘制指令。每行有自己的起始坐标，行与行之间没有任何字段说明它们属于同一段。居中、缩进、行距，全是坐标算出来的视觉效果。

读者看到的段落感，是人眼根据间距补出来的。 软件看到的只是一堆散落的坐标点。

还有一种情况更彻底。设计师在交付印刷文件前会把文字转成曲线，说是为了避免字体缺失。

转曲之后，屏幕上看到的仍然是一行行漂亮的字，但文件里已经没有字符了，只剩下矢量路径。这种 PDF 用眼睛看毫无异常，丢进解析器读出来是零个字。

解析器只能猜

要把坐标还原成段落，解析器得靠启发式规则。y 坐标接近的归为一行，行距接近的归为一段，x 突然回到左边界就认为换了一栏。

规则本身没问题，遇上真实排版就开始出错。

两端对齐的段落会把词间距拉开，某些行被识别成好几个碎片。双栏论文按坐标排序，左栏最后一行常常接上右栏第一行，读起来像一句莫名其妙的话。跨页的表格在第二页重新开头，表头留在了上一页。

行末的连字符是另一处麻烦。排版软件为了对齐会在词中间加连字符，词本身也可能带连字符，解析器分不清这两种情况。于是一个词被拆成两半，或者两个词被拼成一个不存在的词。

译者拿到的句段因此是错位的。他要么先花时间手工合并，要么在一个本来就不完整的句子里翻译。

表格最容易散

表格在 PDF 里只是一组对齐的文字，框线是另外画的图形。 两者之间没有绑定关系。

带完整网格线的表还能靠线推断列边界。学术论文常用的三线表只有三条横线，列与列的分界要靠字间距的规律去猜。合并单元格在 PDF 里没有对应表达，解析器只能把它拆成空格子，或者把内容全塞进左上角那一格。

数字列的情况更麻烦。一列数字的间距足够均匀时，会被整体识别成一个句段。译者面对的是「12.4 15.8 9.2 31.0」这样一行，记忆库里存下的也是这一行。

跨页的长表还要多一层代价。表头在第二页重复出现，PDF 里那两行表头是两段独立的文字。解析器会把它们当成两个句段，译者翻两遍，两次用词未必一致，术语检查这时才跳出来报错。

扫描件换了一种错法

没有文字层的 PDF 只能走 OCR。这时的错误发生在识别环节。数字 0 和字母 O，数字 1 和小写 l，上下标和连字，都是常见的看错。

错字会跟着进入记忆库。 下次同样的句子匹配上来，错的那一版还在里面。

阅读顺序也常被读乱。双栏扫描件经常输出成「左栏第一段、右栏第一段、左栏第二段」的交替文本。这种文本读起来是通顺的，只是每一段都接错了地方。

识别的下限由扫描精度决定。300 dpi 是小字号的临界线，再低一些，八号字基本靠上下文猜。识别出来的文字也没有字体信息，回填时只能挑一款看着接近的字体顶上。

翻完还要放回去

PDF 里的文字是绝对定位。 译文比原文长，后面的字就会被推出页面边界，或者干脆不显示。

换了字体，字宽跟着变，原有的换行位置全部失效。行距要重算，页眉页脚要重新对齐。

多数工具的处理方式是擦掉原文字，用一款相近的字体把译文贴回原位。远看像，近看处处不对：字重不对，标点前后的间距不对，标题的字距被拉宽或压扁。

文本块本身也有固定宽度。译文长出来一截，超出框的部分会被裁掉，编辑界面里看着还算完整，导出 PDF 才发现句子断在中间。这一步没有任何提示，只能靠人翻到那一页去看。

这道工序在交付清单上叫「排版」，工时按页算或者按小时算，从来不按字算。

报价单里没有这一格

翻译按字数计价。 解析要时间，重排要时间，校对版式还要时间，这三段都不产生字数。

合同上常写一句「保持原格式」。销售写下这句话时想的是客户的期待，译者接到这句话时面对的是一道几何题。

于是 PDF 项目的真实成本总是高于报价，超出的部分散落在每个人的加班里，没有科目可以记。

往回退一步

PDF 是从别的文件导出来的。 docx、InDesign 的 idml、FrameMaker 的 mif、LaTeX 的 tex，源头通常还在客户或者他的设计师手上。

判断源头有一个笨办法。PDF 的属性里有 Producer 字段，写着导出它的软件名和版本。

看到 Word 就去要 docx，看到 InDesign 就去要打包文件。带着软件名去问，比空口说「麻烦给源文件」有效得多。

要源文件这件事，越早提越容易成。等到报价签完、交期定死，再回头要文件，客户只会觉得你在推活。

真要不到，就把重排写成独立工序，单独给工期和价格。有些场景确实只能给 PDF，比如已归档的合同、对外发布的报告，这时的合理预期是内容准确、版式接近。

终点被当成了起点

PDF 被设计成一个不再修改的格式。为了「到哪儿都一样」，它把结构信息一层层剥掉了。

把它当源文件用，等于每次都要从终点倒推回起点。

一个格式的取舍，会在十年后变成一道工序。工具为什么这样设计、哪些限制是原理决定的、哪些只是实现没做好，这类问题在翻译工作里反复出现，值得单独讲清楚。

这个号会持续聊这些。CAT 工具的设计取舍、本地化交付里反复出现的坑、AI 翻译在实际项目里的边界。

如果你也遇到过只能拿到 PDF 的项目，或者对某个工具行为想不通，可以在评论区写下来。

关注一下，下次更新你能看到。