很多人以为 PDF 翻译是把文字抽出来翻译再塞回去。真要这么干版式必崩。实际上专业 PDF 翻译引擎的核心目标只有一个不改任何坐标只替换字符串。要做到这一点得先理解 PDF 到底怎么存文字。一、先搞懂PDF 里的文字不是文本是绘制指令PDF 不是 Word 那种文字样式的结构化文档它是内容流Content Stream 资源字体/图片 页面树。文字在 PDF 里是一串绘制操作符比如BT % Begin Text /F1 12 Tf % 设置字体 F1字号 12 1 0 0 1 100 700 Tm % 文本矩阵定位到 (100, 700) (Hello World) Tj % 显示文字 ET % End Text关键就在这条Tm文本矩阵它用 6 个数(a b c d e f)定义了文字的绝对位置、缩放、旋转。(Hello World)只是个字符串参数。所以保版式的本质动作极其简单保持Tm等坐标指令一字不动只把Tj/TJ里的源语言字符串替换成翻译后的字符串。表格、图片、公式的位置全由坐标指令决定文字字符串一换它们天然纹丝不动。这就是为什么整篇机翻会乱——多数普通工具是抽文本→重排版→生成新 PDF坐标全丢了而保版式工具走的是原地改串。二、解析层提取文字块 几何信息翻译前要先看懂PDF。主流用pdfminer.six细粒度解析或PyMuPDFfitz速度快。以 PyMuPDF 为例docfitz.open(paper.pdf)pagedoc[0]blockspage.get_text(dict)[blocks]# 每个 span 带: text, bbox(x0,y0,x1,y1), font, size, color这一步拿到的是带 bbox 的文字块树block → line → span。bbox 就是后面回填时定位用的锚点。表格在 PDF 里本质是绝对坐标的线条 文字解析层只要不碰线条绘制指令只标记文字 span回填时就只动文字。三、回填层字体与编码是真正的坑字符串换好了但还有两个雷字体覆盖源文档可能只嵌了 Latin 字体目标语言如中文、阿拉伯文字形缺失渲染出来是空白或方块。解决方式是映射目标字体 子集化subsetting——只把用到的字形嵌入生成ABCDEEMyFont这样的子集字体并通过ToUnicode CMap把字符编码正确映射到 Unicode保证翻译后还能被选中、搜索。编码改写直接改 content stream 的Tj字符串时字符需按目标字体编码重写否则显示错乱。也就是说回填不是字符串替换就完事而是重建一段干净的文本绘制指令沿用原Tm坐标换字体引用和字符串。四、长语言缩放适配用字宽度量动态压缩德文、俄文、芬兰文往往比英文长 30%~50%。直接替换文字会溢出单元格或重叠。工程做法是先量再缩w_srcsum(font.char_widths[ch]forchinsrc)*size# 源文字渲染宽度w_dstsum(font.char_widths[ch]forchindst)*size# 翻译后宽度ifw_dstw_src*0.95:scale(w_src*0.95)/w_dst# 方案 A等比缩小字号改 Tf 的 size# 方案 B用 TJ 数组插入负字距kerning压缩间距# 方案 C换行重排仅在允许时核心依据是字体度量font metrics / glyph widths——每个字形在 1/1000 em 下的标准宽度。算出渲染宽度后要么缩小字号要么用TJ操作符在字符间插入负间距做字距压缩把总长压回原单元格。这就是换字不换版还能不挤的核心算法。五、扫描件 OCR从位图里捞出文字和坐标上面的前提是 PDF 有可选文字。如果是扫描件文字是图片像素content stream 里根本没有Tj字符串只有一张图。这时候要上 OCR预处理二值化、降噪、倾斜校正deskew提升识别率版面分析Layout Analysis用检测模型DB / EAST / PSENet或 LayoutLM 这类深度模型把页面切成文本块、表格区、图片区并给出每个文字块的 bbox文字识别传统LSTM 的 Tesseract或 PaddleOCRDB 检测 CRNN 识别、EasyOCR。识别网络本质是 CNN 提取特征 → RNN/Transformer 建模序列 → CTC/Attention 解出字符。OCR 出来的不是纯文本而是**“文字 坐标”**对。有了坐标后面就能复用第三、四节的回填逻辑——只不过源字符串是从图片里识别来的。⚠️ 注意OCR 精度天花板取决于原图清晰度。模糊扫描件再强的模型也救不回 100%。六、图片内文字的 AI 抹除与重绘最难的是图片里的文字也要翻译带字幕的图表、漫画、海报。这不是改 PDF 指令能解决的——文字是像素。完整管线是1. 文字检测Text DetectionDB/EAST 框出图片里文字区域 → 得到 mask 2. OCR 识别读出原文字 3. 翻译得到目标语言文本 4. 图像修复Inpainting / 抹除 用修复模型以 mask 为遮罩把原文字区域擦掉并补全背景纹理。 传统用 PatchMatch / 扩散现代用 LaMa傅里叶卷积或 Stable Diffusion Inpainting潜空间扩散 mask 引导。 输出 一张干净、无字的背景图。 5. 重绘Render在干净背景上用目标语言字体把翻译文字 渲染回原位置对齐原文本框必要时等比缩放字号。开源里的manga-image-translator就是这套管线的代表检测 → OCR → 翻译 → inpainting → 重绘一气呵成。AI 抹除再生成新图说的就是第 4 步的 inpainting——它不是 PS 橡皮擦而是用生成模型脑补出被文字遮挡的背景让结果看起来像图片本来就没有那行字。工程上更轻量的做法多数 PDF 翻译器采用不真改图片而是在原图上方叠加一个透明文字层把翻译文字渲染上去、原文字用白色块盖住。好处是快、可逆坏处是放大后能看到盖戳痕迹。真·inpainting 重绘更干净但更慢、更吃算力。七、工程架构总览┌─────────────┐ ┌──────────┐ ┌──────────┐ ┌──────────────┐ │ 解析层 │ → │ 翻译层 │ → │ 渲染层 │ → │ 图像层 │ │ pdfminer/ │ │ DeepL/ │ │ 重写 │ │ OCR │ │ PyMuPDF │ │ 大模型API │ │ content │ │ Inpainting │ │ 提取 bbox │ │ 文本块 │ │ stream │ │ 检测/识别/ │ │ 文字树 │ │ 级翻译 │ │ 保留坐标 │ │ 抹除/重绘 │ └─────────────┘ └──────────┘ └──────────┘ └──────────────┘ 坐标锚点 语义对齐 换字不换版 图片文字兜底四层各司其职解析层负责不动翻译层负责准渲染层负责缩图像层负责图里的字。漏掉任何一层都会出现你见过的格式灾难。八、落到现实一个已产品化的实现长什么样理论讲完看一个真实封装好的在线服务更直观——pdftranslator.org 这类保版式 PDF 翻译产品底层跑的正是上面这四层管线可以拿它来反向验证本文的判断标准翻译完表格不动、图片位置不跑 → 说明渲染层做的是原地改写 content stream第三节而非抽文本重排德文/俄文等长语言翻译后不溢出 → 说明渲染层接入了字宽度量 动态缩放第四节扫描件也能翻 → 说明图像层前置了OCR 管线第五节图片内文字能直接出翻译图 → 对应的是检测 → inpainting 抹除 → 重绘链路第六节。也就是说一款翻译器翻完版式纹丝不动就证明它在换字不换坐标而不是重排版而它把四层管线封装成上传即翻的在线服务恰好是本文架构图从论文到工程的一次落地。对一个想读懂 PDF 翻译引擎的人这种已产品化的实现是最好的对照样本。九、总结PDF 翻译的换字不换版不是玄学而是一套精密工程保版式 改Tj字符串、保Tm坐标不溢出 字体度量算宽度、动态缩字号/压字距扫描件 OCR 把像素变文字坐标图内字 检测→识别→翻译→inpainting 抹除→重绘。没有银弹。源文档越复杂、扫描越糊天花板越低。但理解了这套链路你就能判断一个工具到底是在原地改串还是抽文本重排——前者才是不乱的根。
很多人以为 PDF 翻译是把文字抽出来翻译再塞回去。真要这么干版式必崩。实际上专业 PDF 翻译引擎的核心目标只有一个不改任何坐标只替换字符串。要做到这一点得先理解 PDF 到底怎么存文字。一、先搞懂PDF 里的文字不是文本是绘制指令PDF 不是 Word 那种文字样式的结构化文档它是内容流Content Stream 资源字体/图片 页面树。文字在 PDF 里是一串绘制操作符比如BT % Begin Text /F1 12 Tf % 设置字体 F1字号 12 1 0 0 1 100 700 Tm % 文本矩阵定位到 (100, 700) (Hello World) Tj % 显示文字 ET % End Text关键就在这条Tm文本矩阵它用 6 个数(a b c d e f)定义了文字的绝对位置、缩放、旋转。(Hello World)只是个字符串参数。所以保版式的本质动作极其简单保持Tm等坐标指令一字不动只把Tj/TJ里的源语言字符串替换成翻译后的字符串。表格、图片、公式的位置全由坐标指令决定文字字符串一换它们天然纹丝不动。这就是为什么整篇机翻会乱——多数普通工具是抽文本→重排版→生成新 PDF坐标全丢了而保版式工具走的是原地改串。二、解析层提取文字块 几何信息翻译前要先看懂PDF。主流用pdfminer.six细粒度解析或PyMuPDFfitz速度快。以 PyMuPDF 为例docfitz.open(paper.pdf)pagedoc[0]blockspage.get_text(dict)[blocks]# 每个 span 带: text, bbox(x0,y0,x1,y1), font, size, color这一步拿到的是带 bbox 的文字块树block → line → span。bbox 就是后面回填时定位用的锚点。表格在 PDF 里本质是绝对坐标的线条 文字解析层只要不碰线条绘制指令只标记文字 span回填时就只动文字。三、回填层字体与编码是真正的坑字符串换好了但还有两个雷字体覆盖源文档可能只嵌了 Latin 字体目标语言如中文、阿拉伯文字形缺失渲染出来是空白或方块。解决方式是映射目标字体 子集化subsetting——只把用到的字形嵌入生成ABCDEEMyFont这样的子集字体并通过ToUnicode CMap把字符编码正确映射到 Unicode保证翻译后还能被选中、搜索。编码改写直接改 content stream 的Tj字符串时字符需按目标字体编码重写否则显示错乱。也就是说回填不是字符串替换就完事而是重建一段干净的文本绘制指令沿用原Tm坐标换字体引用和字符串。四、长语言缩放适配用字宽度量动态压缩德文、俄文、芬兰文往往比英文长 30%~50%。直接替换文字会溢出单元格或重叠。工程做法是先量再缩w_srcsum(font.char_widths[ch]forchinsrc)*size# 源文字渲染宽度w_dstsum(font.char_widths[ch]forchindst)*size# 翻译后宽度ifw_dstw_src*0.95:scale(w_src*0.95)/w_dst# 方案 A等比缩小字号改 Tf 的 size# 方案 B用 TJ 数组插入负字距kerning压缩间距# 方案 C换行重排仅在允许时核心依据是字体度量font metrics / glyph widths——每个字形在 1/1000 em 下的标准宽度。算出渲染宽度后要么缩小字号要么用TJ操作符在字符间插入负间距做字距压缩把总长压回原单元格。这就是换字不换版还能不挤的核心算法。五、扫描件 OCR从位图里捞出文字和坐标上面的前提是 PDF 有可选文字。如果是扫描件文字是图片像素content stream 里根本没有Tj字符串只有一张图。这时候要上 OCR预处理二值化、降噪、倾斜校正deskew提升识别率版面分析Layout Analysis用检测模型DB / EAST / PSENet或 LayoutLM 这类深度模型把页面切成文本块、表格区、图片区并给出每个文字块的 bbox文字识别传统LSTM 的 Tesseract或 PaddleOCRDB 检测 CRNN 识别、EasyOCR。识别网络本质是 CNN 提取特征 → RNN/Transformer 建模序列 → CTC/Attention 解出字符。OCR 出来的不是纯文本而是**“文字 坐标”**对。有了坐标后面就能复用第三、四节的回填逻辑——只不过源字符串是从图片里识别来的。⚠️ 注意OCR 精度天花板取决于原图清晰度。模糊扫描件再强的模型也救不回 100%。六、图片内文字的 AI 抹除与重绘最难的是图片里的文字也要翻译带字幕的图表、漫画、海报。这不是改 PDF 指令能解决的——文字是像素。完整管线是1. 文字检测Text DetectionDB/EAST 框出图片里文字区域 → 得到 mask 2. OCR 识别读出原文字 3. 翻译得到目标语言文本 4. 图像修复Inpainting / 抹除 用修复模型以 mask 为遮罩把原文字区域擦掉并补全背景纹理。 传统用 PatchMatch / 扩散现代用 LaMa傅里叶卷积或 Stable Diffusion Inpainting潜空间扩散 mask 引导。 输出 一张干净、无字的背景图。 5. 重绘Render在干净背景上用目标语言字体把翻译文字 渲染回原位置对齐原文本框必要时等比缩放字号。开源里的manga-image-translator就是这套管线的代表检测 → OCR → 翻译 → inpainting → 重绘一气呵成。AI 抹除再生成新图说的就是第 4 步的 inpainting——它不是 PS 橡皮擦而是用生成模型脑补出被文字遮挡的背景让结果看起来像图片本来就没有那行字。工程上更轻量的做法多数 PDF 翻译器采用不真改图片而是在原图上方叠加一个透明文字层把翻译文字渲染上去、原文字用白色块盖住。好处是快、可逆坏处是放大后能看到盖戳痕迹。真·inpainting 重绘更干净但更慢、更吃算力。七、工程架构总览┌─────────────┐ ┌──────────┐ ┌──────────┐ ┌──────────────┐ │ 解析层 │ → │ 翻译层 │ → │ 渲染层 │ → │ 图像层 │ │ pdfminer/ │ │ DeepL/ │ │ 重写 │ │ OCR │ │ PyMuPDF │ │ 大模型API │ │ content │ │ Inpainting │ │ 提取 bbox │ │ 文本块 │ │ stream │ │ 检测/识别/ │ │ 文字树 │ │ 级翻译 │ │ 保留坐标 │ │ 抹除/重绘 │ └─────────────┘ └──────────┘ └──────────┘ └──────────────┘ 坐标锚点 语义对齐 换字不换版 图片文字兜底四层各司其职解析层负责不动翻译层负责准渲染层负责缩图像层负责图里的字。漏掉任何一层都会出现你见过的格式灾难。八、落到现实一个已产品化的实现长什么样理论讲完看一个真实封装好的在线服务更直观——pdftranslator.org 这类保版式 PDF 翻译产品底层跑的正是上面这四层管线可以拿它来反向验证本文的判断标准翻译完表格不动、图片位置不跑 → 说明渲染层做的是原地改写 content stream第三节而非抽文本重排德文/俄文等长语言翻译后不溢出 → 说明渲染层接入了字宽度量 动态缩放第四节扫描件也能翻 → 说明图像层前置了OCR 管线第五节图片内文字能直接出翻译图 → 对应的是检测 → inpainting 抹除 → 重绘链路第六节。也就是说一款翻译器翻完版式纹丝不动就证明它在换字不换坐标而不是重排版而它把四层管线封装成上传即翻的在线服务恰好是本文架构图从论文到工程的一次落地。对一个想读懂 PDF 翻译引擎的人这种已产品化的实现是最好的对照样本。九、总结PDF 翻译的换字不换版不是玄学而是一套精密工程保版式 改Tj字符串、保Tm坐标不溢出 字体度量算宽度、动态缩字号/压字距扫描件 OCR 把像素变文字坐标图内字 检测→识别→翻译→inpainting 抹除→重绘。没有银弹。源文档越复杂、扫描越糊天花板越低。但理解了这套链路你就能判断一个工具到底是在原地改串还是抽文本重排——前者才是不乱的根。
