译文排版为什么不会破RetainPDF 字体缩放与文本密度估算算法完整指南【免费下载链接】retain-pdf在保留版面、公式与结构的前提下进行 PDF 翻译适用于科研与技术文档项目地址: https://gitcode.com/gh_mirrors/re/retain-pdf一、PDF 翻译最大的难题版面不能破用 RetainPDF 翻译一篇英文论文时最直观的体验是译出来的 PDF 像一份本来就印成中文的文档——双栏还在、公式还在、图注位置没动没有文字溢出、重叠或被挤到页外。这背后藏着一个极难的排版问题在保留原文版面、公式与结构的前提下把变长或变短的译文塞回原来的文字框里。中文比英文挤得多——同样一句话翻译成中文后字符数往往翻倍。字号写大了就溢出写小了又显得别扭同一页上百个文字框每个框宽宽窄窄、高高低低根本没有一个通用字号能应付。这就是 RetainPDF 自研的字体缩放与文本密度估算算法要解决的问题字号不能是常量必须跟着页面和文字框一起动态变化。相关文档位于 docs/reference/font-scaling/核心代码在 backend/pipeline/retainpdf_pipeline/render/layout/ 目录下。二、为什么固定字号注定失败第一次做保留排版翻译的人都会想原文大概 10pt翻译后我也统一用 10pt 不就行了只要拿几页论文试一下就会发现不行因为 PDF 里的文字块千差万别有的在双栏正文里有的在图注里有的框很宽、有的只有 100 多 pt 宽有的原文只有一句话有的翻译成中文后明显膨胀。同样的 9pt 字号在宽框里换行压力小绰绰有余在窄框里会疯狂换行迅速堆满框高所以 RetainPDF 的思路不是求一个字号而是在放得下和看起来像原稿之间为每个块动态找平衡点。三、三层字号决策从页面基准到贴框实测RetainPDF 的字号不是一步算出来的而是分三层逐步收敛思路详见 字体随页面变化的算法第一层页面基准字号 先观察整页正文的节奏——平均行高、行距紧不紧、每行能容纳多少字符——给这一页定一个锚点字号。密集页基准偏小如 9.2pt宽松页基准偏大如 10.4pt。这一步解决这页整体该偏紧还是偏松。第二层块级修正 再看具体这个框框是不是特别窄高度是不是很有限翻译后是不是明显变长公式多不多如果偏向挤就在页面基准上往下调偏向松就允许往上走。第三层真实渲染贴框检查✅ 前两层的估算再聪明也有误差——某些字形比预期宽、行内公式把一行撑宽、标点分布导致换行更差。所以渲染前会做最后一次实测拿当前字号真实测一下超了就按比例再缩。一个典型过程的数字页面基准 9.4pt → 块级修正到 8.7pt → 实测贴框后收口到 8.5pt。这就是随页面变化的字号。四、深度解析文本密度估算框到底是松还是挤4.1 长度密度译文比原文膨胀了多少代码在 text_common.py核心逻辑一句话中文字符数 ÷ 原文词数。原文 20 个词译文 18 个中文字符 → 比值 0.9进入偏紧区间原文 20 个词译文 24 个中文字符 → 比值 1.2属于重度紧凑块必须保守处理代码中COMPACT_TRIGGER_RATIO 0.9、HEAVY_COMPACT_RATIO 1.0就是这两道阈值。它的作用不是精算排版而是快速判断这段译文会不会比原文更容易变挤。4.2 布局密度当前字号下框会被塞满吗光看内容变长了没有不够还得看框的容量。同样是比值 1.0 的两段话放在 400pt 宽的正文档里完全没问题放在 160pt 宽的图注框里可能马上爆掉。layout_density_ratio(...)的估算链非常直观按字号估单字宽度约 0.92 倍字号推出每行能放多少字估算译文要占几行算出占用高度除以框高得到的比值一眼可读小于 1 放得下接近 1 很紧超过 1 理论上已经超框。拿官方文档 密度.md 里的例子算一遍72 个中文字符、9pt 字号、12pt 行距——放进 180×90pt 的框布局密度约0.44很宽松放进 110×48pt 的窄框密度飙到1.35当前字号一定太大。4.3 真实容量与真实需求不只是数数快速估算是第一步更严谨的计算在 capacity.pybox_capacity_units(...)按字号和行距推算能放几行 × 每行能放多少字得到框的总容量。关键细节是会参考 OCR/版面结构给出的视觉行数避免把容量想得过于乐观text_demand_units(...)把文本拆成 token 逐段计价公式占位符不按 1 个字符算而是按更接近真实视觉成本的方式加权——两段字符数差不多的文本带公式的那段排版压力会明显更高4.4 视觉行数修正别全信 OCR 给的行数还有一个容易忽略的坑OCR 有时会把 4 行段落粘成 1 行。如果直接相信这个1 行框的容量就会被严重高估。所以 typography/line_count.py 里的visual_line_count(...)会做交叉验证根据文本长度、框宽和单行承载能力预测正常换行应该是几行如果明显高于 OCR 行数就用预测值修正。这一步防的是密度判断被假数据带偏。五、密度如何最终影响字号密度指标不会直接输出9.2pt它决定的是要不要缩、缩多少步、是只缩字号还是连行距一起压。在 fit_metrics.py 的fit_translated_block_metrics(...)中判断链很朴素译文是不是明显变长了长度密度当前字号下这段内容会占掉框内多少高度布局密度框真正能装多少单位内容容量OCR 行数可信吗视觉行数修正需求 vs 容量需求没逼近容量且密度不高 → 保留当前字号否则进入每步缩小字号、必要时压紧行距的收敛循环直到放得下一句话概括整个算法先看这页的平均节奏再看这个框的几何压力再看这段内容的密度最后用真实渲染结果做收口。它不追求数学上最优只追求在真实 PDF 里稳定、自然、不炸框。六、这套算法最容易踩的四个坑过度相信 OCR两行被识别成一行整页基准字号就会系统性偏大过度依赖字符数真正决定排版压力的是能不能断行、断成几行、有没有特别宽的内容把最小字号卡死全局硬下限会让极端窄框直接失败下限最好带动态性只做估算不做实测不贴框实测就总会遇到估得差不多、实际还是溢出七、总结RetainPDF 的排版不破靠的不是某个神奇的公式而是把字号该多大拆成四个可验证的问题这页整体什么节奏这个块相对整页是更难排还是更容易排译文内容比框的容量超出了多少真实渲染后到底放进去没有四个问题都回答了字号才是算出来的而不是猜出来的。想深入阅读建议按顺序看字体与排版密度文档 → 字体随页面变化的算法 → 密度算法说明再对照 payload 模块 的源码实现即可完整还原这条密度 → 容量 → 缩字号的决策链路。【免费下载链接】retain-pdf在保留版面、公式与结构的前提下进行 PDF 翻译适用于科研与技术文档项目地址: https://gitcode.com/gh_mirrors/re/retain-pdf创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
译文排版为什么不会破RetainPDF 字体缩放与文本密度估算算法完整指南【免费下载链接】retain-pdf在保留版面、公式与结构的前提下进行 PDF 翻译适用于科研与技术文档项目地址: https://gitcode.com/gh_mirrors/re/retain-pdf一、PDF 翻译最大的难题版面不能破用 RetainPDF 翻译一篇英文论文时最直观的体验是译出来的 PDF 像一份本来就印成中文的文档——双栏还在、公式还在、图注位置没动没有文字溢出、重叠或被挤到页外。这背后藏着一个极难的排版问题在保留原文版面、公式与结构的前提下把变长或变短的译文塞回原来的文字框里。中文比英文挤得多——同样一句话翻译成中文后字符数往往翻倍。字号写大了就溢出写小了又显得别扭同一页上百个文字框每个框宽宽窄窄、高高低低根本没有一个通用字号能应付。这就是 RetainPDF 自研的字体缩放与文本密度估算算法要解决的问题字号不能是常量必须跟着页面和文字框一起动态变化。相关文档位于 docs/reference/font-scaling/核心代码在 backend/pipeline/retainpdf_pipeline/render/layout/ 目录下。二、为什么固定字号注定失败第一次做保留排版翻译的人都会想原文大概 10pt翻译后我也统一用 10pt 不就行了只要拿几页论文试一下就会发现不行因为 PDF 里的文字块千差万别有的在双栏正文里有的在图注里有的框很宽、有的只有 100 多 pt 宽有的原文只有一句话有的翻译成中文后明显膨胀。同样的 9pt 字号在宽框里换行压力小绰绰有余在窄框里会疯狂换行迅速堆满框高所以 RetainPDF 的思路不是求一个字号而是在放得下和看起来像原稿之间为每个块动态找平衡点。三、三层字号决策从页面基准到贴框实测RetainPDF 的字号不是一步算出来的而是分三层逐步收敛思路详见 字体随页面变化的算法第一层页面基准字号 先观察整页正文的节奏——平均行高、行距紧不紧、每行能容纳多少字符——给这一页定一个锚点字号。密集页基准偏小如 9.2pt宽松页基准偏大如 10.4pt。这一步解决这页整体该偏紧还是偏松。第二层块级修正 再看具体这个框框是不是特别窄高度是不是很有限翻译后是不是明显变长公式多不多如果偏向挤就在页面基准上往下调偏向松就允许往上走。第三层真实渲染贴框检查✅ 前两层的估算再聪明也有误差——某些字形比预期宽、行内公式把一行撑宽、标点分布导致换行更差。所以渲染前会做最后一次实测拿当前字号真实测一下超了就按比例再缩。一个典型过程的数字页面基准 9.4pt → 块级修正到 8.7pt → 实测贴框后收口到 8.5pt。这就是随页面变化的字号。四、深度解析文本密度估算框到底是松还是挤4.1 长度密度译文比原文膨胀了多少代码在 text_common.py核心逻辑一句话中文字符数 ÷ 原文词数。原文 20 个词译文 18 个中文字符 → 比值 0.9进入偏紧区间原文 20 个词译文 24 个中文字符 → 比值 1.2属于重度紧凑块必须保守处理代码中COMPACT_TRIGGER_RATIO 0.9、HEAVY_COMPACT_RATIO 1.0就是这两道阈值。它的作用不是精算排版而是快速判断这段译文会不会比原文更容易变挤。4.2 布局密度当前字号下框会被塞满吗光看内容变长了没有不够还得看框的容量。同样是比值 1.0 的两段话放在 400pt 宽的正文档里完全没问题放在 160pt 宽的图注框里可能马上爆掉。layout_density_ratio(...)的估算链非常直观按字号估单字宽度约 0.92 倍字号推出每行能放多少字估算译文要占几行算出占用高度除以框高得到的比值一眼可读小于 1 放得下接近 1 很紧超过 1 理论上已经超框。拿官方文档 密度.md 里的例子算一遍72 个中文字符、9pt 字号、12pt 行距——放进 180×90pt 的框布局密度约0.44很宽松放进 110×48pt 的窄框密度飙到1.35当前字号一定太大。4.3 真实容量与真实需求不只是数数快速估算是第一步更严谨的计算在 capacity.pybox_capacity_units(...)按字号和行距推算能放几行 × 每行能放多少字得到框的总容量。关键细节是会参考 OCR/版面结构给出的视觉行数避免把容量想得过于乐观text_demand_units(...)把文本拆成 token 逐段计价公式占位符不按 1 个字符算而是按更接近真实视觉成本的方式加权——两段字符数差不多的文本带公式的那段排版压力会明显更高4.4 视觉行数修正别全信 OCR 给的行数还有一个容易忽略的坑OCR 有时会把 4 行段落粘成 1 行。如果直接相信这个1 行框的容量就会被严重高估。所以 typography/line_count.py 里的visual_line_count(...)会做交叉验证根据文本长度、框宽和单行承载能力预测正常换行应该是几行如果明显高于 OCR 行数就用预测值修正。这一步防的是密度判断被假数据带偏。五、密度如何最终影响字号密度指标不会直接输出9.2pt它决定的是要不要缩、缩多少步、是只缩字号还是连行距一起压。在 fit_metrics.py 的fit_translated_block_metrics(...)中判断链很朴素译文是不是明显变长了长度密度当前字号下这段内容会占掉框内多少高度布局密度框真正能装多少单位内容容量OCR 行数可信吗视觉行数修正需求 vs 容量需求没逼近容量且密度不高 → 保留当前字号否则进入每步缩小字号、必要时压紧行距的收敛循环直到放得下一句话概括整个算法先看这页的平均节奏再看这个框的几何压力再看这段内容的密度最后用真实渲染结果做收口。它不追求数学上最优只追求在真实 PDF 里稳定、自然、不炸框。六、这套算法最容易踩的四个坑过度相信 OCR两行被识别成一行整页基准字号就会系统性偏大过度依赖字符数真正决定排版压力的是能不能断行、断成几行、有没有特别宽的内容把最小字号卡死全局硬下限会让极端窄框直接失败下限最好带动态性只做估算不做实测不贴框实测就总会遇到估得差不多、实际还是溢出七、总结RetainPDF 的排版不破靠的不是某个神奇的公式而是把字号该多大拆成四个可验证的问题这页整体什么节奏这个块相对整页是更难排还是更容易排译文内容比框的容量超出了多少真实渲染后到底放进去没有四个问题都回答了字号才是算出来的而不是猜出来的。想深入阅读建议按顺序看字体与排版密度文档 → 字体随页面变化的算法 → 密度算法说明再对照 payload 模块 的源码实现即可完整还原这条密度 → 容量 → 缩字号的决策链路。【免费下载链接】retain-pdf在保留版面、公式与结构的前提下进行 PDF 翻译适用于科研与技术文档项目地址: https://gitcode.com/gh_mirrors/re/retain-pdf创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
