内容中心 › 排版
结论先放前面：noam@google.com 断在 noam@g 后面不是随机的。它断在第 8 个字符，因为那个作者框宽 78.6pt，「谷歌大脑」四个汉字吃掉 39.8pt，剩下的只够 8.6 个拉丁字符。换别的框，断点会平移，算法一样：框宽 ÷ 字符宽。
把两版 PDF 的作者区坐标拉出来对比：
| 项目 | 原文 | 译文 |
|---|---|---|
| 文本块总数（15 页） | 484 | 204 |
| 8 个作者框宽度 | 75.1–120.3 pt | 74.8–119.9 pt |
| 作者框高度 | 33.6 pt | 35.2 pt |
框宽最大偏差 1.5pt，正文块左边界两边都是 108.0pt。重排过的话不可能这么接近——重排后的行宽取决于字号和断词策略，不会是「原文多少就是多少」。块数 484 掉到 204 是相邻块合并，不是内容少了。好处是表格、图注、双栏能对上原版式，代价是框宽成了硬约束，译文只能往框里塞。
把两版的文字 span 全抽出来算单位宽度（宽度 ÷ 字符数，取中位数）：
| 字符类型 | 原文 | 译文 |
|---|---|---|
| 拉丁字符 | 4.15 pt/字符 | 4.53 pt/字符 |
| 汉字 | — | 9.96 pt/字符 |
汉字宽度约等于两个拉丁字符。而这一格的内容变了：原文三行纯英文，译文里姓名保留英文、机构译成中文（Google Brain → 谷歌大脑），机构后面直接接邮箱。
「谷歌大脑」占 4 × 9.96 = 39.8pt，剩 78.6 − 39.8 = 38.8pt，38.8 ÷ 4.53 ≈ 8.6，于是这一行放下 8 个字母就满了：谷歌大脑 noam@g，剩下的 oogle.com 换到下一行。8 个邮箱断在 8 个不同位置也是这个原因：框宽从 75.1 到 120.3 不等，机构中文长度也不同（「谷歌大脑」4 字、「多伦多大学」5 字）。
让邮箱报废的不是折行，是粒度。正常排版引擎遇到 noam@google.com 会整体换行，它算不可分割的单词；译文把它当 15 个独立字符流，逐字符累加宽度，cursor_x + char_w(ch) > box_right 就换行——不管切在 @ 前还是 g 中间。
没有「单词」这个概念，就没有断词点，也就没东西保护邮箱、URL、DOI、文件名。全篇 15 页里，从词中间被切断的还有 LayerN|orm（第 3 页正文）、dro|pout（第 9 页表格）、Ole|ksii（第 11 页文献）。
会议名那句原文 78 个字符，译文 38 个字符、其中 21 个汉字——它被当正文译了。页码反而是好的：15 页里 14 页有页码，位置和原文一致，纯数字没被动手。规律可以推广：页眉页脚里凡「有语义的字符串」都可能被翻译，凡「纯符号、纯数字」都能活下来，会议名、期刊名、版权行属于高危。
顺带说旋转块：首页左边那条竖排 arXiv 编号方向 dir=(0,-1)，原文是一个 line、93 个字符的整块，译文变成 9 个块、每块 2 到 8 个字符且倒序——还是同一个填充算法，只是堆叠方向按旋转后的坐标算。
算一遍：量一下出问题的框有多宽，除以 4.5，就是这行能放几个拉丁字符。断点落在那附近，说明是框宽问题，不是翻译漏字。
搜一遍：Ctrl+F 搜邮箱、搜 DOI、搜机构英文名。搜不到就是被折断了，从原文 PDF 抄。
档位能规避吗？版式精排（6 积分每页）做的是按原始边框重排表格、图注、双栏，解决「结构对不对」，不解决「不可分割的串会不会被切」——那是折行策略，跟档位无关。翻呗翻译支持 24 种语言、单文件 300MB / 1500 页，扫描件按语种走独立 OCR 通道、准确率比电子版低一档。
数字由 fitz（PyMuPDF）对同一份 15 页样本实测，脚本 csdn_measure_columns.py 可复现。
[整份 PDF 保留公式与表格的做法](https://trans.sunnytranslation.com/pdf-fanyi)