Matrix 首页推荐

Matrix 是少数派的写作社区，我们主张分享真实的产品体验，有实用价值的经验与思考。我们会不定期挑选 Matrix 最优质的文章，展示来自用户的最真实的体验和观点。 
文章代表作者个人观点，少数派仅对标题和排版略作修改。

作者注

本文在创作过程中部分使用了 AI 生成工具辅助，包括事实检索、文本润色和结构建议等。所用 AI 工具为 OpenAI ChatGPT。所有生成结果、包括相关数据和事实，均已经过作者逐项核查，确保内容准确、合规并具备个人原创性。

如有疏漏，欢迎指正。

在学术研究和专业技术领域，我们经常需要翻阅包含大量数学公式和专业术语的英文 PDF 文档。传统的翻译工具往往难以兼顾翻译质量和文档排版，尤其是面对复杂公式和图表时，容易出现格式混乱或内容缺失。

PDFMathTranslate（以下简称 PDFMT）是一款针对这一痛点开发的开源工具。它基于 AI 模型对 PDF 版面进行分析，能够在翻译 PDF 全文的同时完整保留原有的排版结构，包括公式、图表、目录和批注等。该项目在 GitHub 上拥有数万星标，支持多种主流翻译服务（如 Google、DeepL、OpenAI GPT-4、Ollama 等）以及多语言翻译，提供命令行、图形界面、浏览器插件等多种使用方式，方便不同需求的用户使用。

本文将对 PDFMT 的功能完整性、翻译质量、使用性能等方面进行浅浅的评测。采用中立客观的技术评述风格，基于可复现的测试和公开资料，简要分析工具的技术原理和实现方式，并指出目前存在的不足与改进建议。

安装、部署、概览

PDFMT 项目以 pdf2zh 作为 Python 包名称，安装和部署较为灵活。它支持源码安装、Python 封装、便携运行以及容器部署等，根据官方说明，需准备 Python 3.10 - 3.12 环境。工具运行依赖深度学习模型和 PDF 解析库，在安装时会自动下载所需的模型文件（默认从 HuggingFace 获取 DocLayout YOLO 布局分析模型）。

pip 安装：推荐的方式是在已有 Python 环境中通过 pip 安装。只需在命令行执行：

pip install pdf2zh

安装完成后，即可使用 pdf2zh 命令执行翻译（PDFMT 的所有依赖我会整理在文章末尾）。默认情况下，直接运行命令并指定 PDF 文件即可翻译整个文档，会输出双语版本 (后缀 -dual) 以及单语版本 (后缀 -mono) 结果文件会输出在当前工作目录：

pdf2zh input_document.pdf

正常情况下翻译自动采用默认配置（可在配置文件或环境变量中设定默认翻译引擎和语言等），通过命令行参数也可以指定源语言和目标语言，比如在命令中选择翻译服务引擎。

图形界面 (GUI)： PDFMT 内置了交互式 Web 界面，基于 Gradio 实现。安装包就绪后，在终端运行以下命令启动 GUI 服务（或可手动访问 http://0.0.0.0:7860）：

pdf2zh -i

这将会在本地启动一个 Web 应用（默认监听 localhost:7860），并自动在浏览器中打开界面。GUI 界面左侧为文件上传区域（支持拖拽或点击上传），右侧是 PDF 内容预览。下方则提供翻译选项，包括选择翻译服务引擎、目标语言以及翻译页数范围（可以选择全文或仅前几页测试）。配置完成后点击下方「Translate」按钮即可开始翻译，翻译过程中的进度和日志也会在界面中实时更新。

Zotero 插件： 为方便学术用户，PDFMT 提供了 Zotero 文献管理软件的插件 Zotero-pdf2zh。通过该插件，可在 Zotero 中一键将 PDF 文献发送至 PDFMT 翻译，并将翻译结果（如双语对照 PDF）自动导入回 Zotero。这对于需要在文献管理流程中直接查看译文的科研人员非常实用。插件的具体安装与使用可参考项目仓库提供的说明。

便携运行与其他方法： 对于不方便配置 Python 环境的用户，项目还提供了免安装的可执行程序和脚本。一种方式是下载官方提供的 Windows 可执行文件（zip 压缩包），解压后直接运行其中的 pdf2zh.exe 即可启动 GUI；对于 macOS 平台，有社区爱好者封装了 Mac 版的独立应用（例如 .dmg 安装镜像），可直接双击运行，首次启动会自动打开浏览器界面。另外，通过开发者提供的 setup.bat 脚本，Windows 用户也可以一键安装所需的 Python 嵌入式环境及 pdf2zh 包，从而实现「便携式」部署。这些方法降低了使用门槛，使非开发背景的用户也能快速上手体验。

Docker 容器化部署： 项目官方提供了预构建的 Docker 镜像（如 byaidu/pdf2zh），方便在服务器或云端部署。使用 Docker 拉取镜像并运行容器即可启动翻译服务：

docker pull byaidu/pdf2zh
docker run -d -p 7860:7860 byaidu/pdf2zh

容器启动后，同样可以通过 http://服务器IP:7860/ 访问 Web 界面进行操作。容器化方式封装了所有依赖环境，保证了跨平台的一致运行，适用于团队内部部署或私有化服务。项目文档也提供了在 Heroku、Railway、Zeabur 等平台上部署容器的参考配置，对于有私有云部署需求的场景非常有价值。

完成上述安装部署后，我们可根据自身需求选择命令行批处理、GUI 交互翻译或通过 API/插件集成到其它工作流程中。接下来将详细介绍该工具的主要功能及其在翻译过程中的表现。

功能概览

支持的翻译引擎与多语言能力

PDFMT 的一大特点是支持多种翻译引擎和服务接口，我们可以根据需求选择最合适的翻译后端。项目通过模块化设计集成了主流的机器翻译服务，包括：

在线翻译 API： 支持 Google Translate 和 DeepL 等知名翻译服务，通过官方 API 进行翻译。我们需要提供相应的 API Key 才能使用这些商业服务（可通过环境变量如 DEEPL_AUTH_KEY 等配置）。利用 Google/DeepL 通常可以获得比较流畅且专业的译文，适合对翻译质量要求高的场景。

开放模型及本地服务： 支持 OpenAI 的 GPT 系列模型（包括 GPT-4），既可以调用 OpenAI 官方 API，也支持 Azure OpenAI 服务。此外，还支持开源大语言模型的本地部署。项目也集成了 Zhipu AI（智谱）、Tencent 云翻译、Bing 翻译等国内外翻译接口，力求覆盖尽可能广泛的翻译源。这种多引擎集成方式使工具具有很强的灵活性：在联网条件好且有 API 额度时，可调用云端优秀模型获取高质量翻译；在离线或保密需求场景下，也能切换到本地 LLM 模型完成翻译。

多语言方向： 虽名为「pdf2zh」，但实际上 PDFMT 支持多语言互译。几乎所有上述引擎支持的语言对都可以在工具中使用，包括中英互译、英文与法/德/日等多语种翻译等。我们可以自由选择源语言和目标语言。值得一提的是，工具对数学公式中的符号也能做到语言习惯转换，如在中译英时将某些中文数学标注改为英文惯用形式等，以保证译文符合目标语言读者的习惯。这一点在多语言学术交流中非常有用。

实现上，PDFMT 提供了统一的翻译服务接口，开发者可以在配置文件中设定默认使用的引擎，或在运行命令时通过参数指定引擎类型。例如可以在命令行中使用 -e google 指定使用 Google 翻译，或 -e openai 使用 OpenAI 模型。对于需要 API 密钥的服务，则通过环境变量提供（如 OPENAI_API_KEY 等）。这种设计使得翻译引擎的切换和扩展十分方便。

PDF 格式兼容性与排版保留

PDF 解析与重建： PDFMT 的核心能力在于版面重构技术。它采用了基于 AI 的布局分析模型和 PDF 指令流解析，来获取原 PDF 的结构和样式信息。具体而言，工具使用 Python 的 PyMuPDF 来解析 PDF 文档，提取页面上的文本框、字体信息、图像、表格和绘制指令等底层元素。同时，结合训练过的文档布局分析模型（如 DocLayout YOLO），对页面进行分割和区域分类，识别段落、标题、公式区域、图表区域等版块。这种 AI 模型辅助的解析让工具能够理解 PDF 的版面结构，而非仅顺序提取文本，从而为后续精准地将翻译文本放回正确的位置奠定基础。

在遇到 LaTeX 格式排版的数学论文时，工具对公式处理做了特别优化。许多学术 PDF 中的数学公式实际上是以特殊字体或矢量图形嵌入的，直接提取文本可能得到混乱的字符串。PDFMT 集成了第三方的 Mathpix Snip 公式识别接口和 sympy 等库，可以将 PDF 中的公式解析为 LaTeX 或统一的数学表示，然后在翻译过程中保持公式不变。这一过程避免了翻译引擎对公式内容的误处理——也就是说，公式既不会被当作普通文本翻译，也不会在重排版时丢失。对于行间公式、行内公式两种情况，工具均能识别并保留原格式和编号。此外，针对 LaTeX 论文中常见的特殊符号（如希腊字母、数学运算符等），工具也有针对性地确保它们在译文中正确呈现，不会出现乱码或缺失。

完成翻译后，PDFMT 并非简单地在原 PDF 上盖层翻译文本，而是重新生成一个 PDF 文件。为此，项目使用 ReportLab 等 PDF 生成库，根据先前解析得到的布局和样式信息，将译文文本逐段绘制到对应的位置。它会尽量使用与原文相同的字体、字号和颜色，并保持段落对齐、页面边距等一致。比如，如果原 PDF 是双栏排版，重建时译文也会严格按照双栏格式排列；如果原文某段文字是斜体或粗体，译文相应部分也应用相同的样式。

甚至连原文的可点击目录书签结构，工具都会在译文 PDF 中一并保留或更新。这一系列措施确保了翻译后的 PDF 在外观上与原文高度一致，阅读体验良好。正如有用户反馈所说，经过 PDFMT 翻译的论文「内容和版式上与原文高度一致」。读者无需再花时间调整格式，可以直接将译文用于学习和参考。

值得一提的是，PDFMT 还在不断扩展对各种 PDF 格式的兼容。早期版本对非 PDF/A 标准的 PDF 支持不佳，后来通过 -cp 参数增加了对一般 PDF 的兼容模式。此外，对于扫描版 PDF（纯图像）文档，由于缺乏文本层，工具也尝试结合 OCR 来提取文字和公式。目前 OCR 支持尚属实验性质，但已有迹象表明开发者意识到了这方面需求。因此在未来版本中，我们或许能看到对于扫描件的直接翻译支持，使工具应用范围进一步扩大。

使用界面与功能模块

PDFMT 面向不同技术背景的用户，提供了多样的使用接口：

命令行界面 (CLI)：适合批量处理和集成到脚本流程中。CLI 用法相对简单，基本格式为 pdf2zh [选项] <输入PDF文件>。前文我们已演示了基本命令，CLI 支持丰富的选项参数，例如：

  • li 指定源语言，lo 指定目标语言（若不指定，工具可尝试自动检测或使用默认语言对）；
  • e 或 -engine 指定翻译引擎类型，如 google、deepl、openai 等；
  • o 指定输出文件名或路径；不指定则默认输出与源文件同名的译文 PDF 和带 .dual.pdf 后缀的双语对照 PDF；
  • -mono/--dual 强制选择输出单语还是双语 PDF。默认情况下工具会同时生成纯译文和双语两种版本；
  • 以及诸如 p 选择页码范围，t 指定并行线程数等高级选项（依据文档提供）。

使用 CLI 时，只需确保相关 API 密钥已配置在环境变量，即可在终端一条命令翻译完成。例如将英文 PDF 翻译为中文，使用 DeepL 引擎，输出双语对照：pdf2zh research_paper.pdf -li en -lo zh -e deepl --dual

运行上述命令后，工具会在当前目录生成 research_paper_translated-mono.pdf（单语）以及 research_paper_translated-dual.pdf（双语）。命令行模式的优势是可以批处理多个文件并行翻译，对于翻译大量文档的场景非常高效。

图形用户界面 (GUI)： 提供了更直观友好的操作方式，尤其适合不熟悉命令行的一般用户。在 GUI 中，我们可以方便地完成文件上传、参数配置、翻译执行等操作，并在翻译完成后实时预览结果。GUI 还支持实时预览与人工调整，翻译过程中已完成的页面会即时显示在预览窗口中，如果发现某些术语翻译不理想，可以暂停并手动修改，然后继续翻译。这种交互设计可以提升翻译质量和我们的掌控感。（不过需要注意，由于浏览器端预览能力所限，复杂 PDF 的完整预览可能有延迟，实际精细排版最好还是查看导出的 PDF 文件。）

模块化设计：PDFMT 可分为 PDF 解析模块、翻译模块和 PDF 生成模块等。每个模块各司其职：解析模块负责获取文档结构，翻译模块对提取的文本调用翻译引擎，生成模块将译文与原格式合成输出。

值得赞赏的是开发者对这些模块进行了性能优化。例如多线程与缓存机制，翻译时对独立页面或段落并行处理，并将已翻译过的句子缓存以避免重复翻译，从而提高效率。这些细节在大型文档或批量文档处理时能显著提升速度。在实际测试章节我们将对性能方面有更具体的观察。

综上，PDFMT 在功能上非常全面：既涵盖从公式识别、图表保留到目录结构的复杂 PDF 版面处理，也集成了多种翻译后端和使用接口供我们选择。这种完整性使其在众多 PDF 翻译工具中脱颖而出，特别适合作为学术论文、技术手册等资料的翻译利器。

实际测试与评估

翻译质量与术语准确性

首先关注翻译文本本身的质量。

针对数学类论文章节（英文转中文），PDFMT 成功将大段的学术论述翻译为通顺的中文。专业术语基本都能得到准确翻译，例如「posterior distribution」等统计术语均译为恰当的中文，对领域读者非常友好。借助强大的翻译引擎（如 DeepL 或 GPT-4），再加上开发者内置的少量术语库优化，工具在学术语境下的用词相当专业。

我在使用中观察到，句子结构在译文中整体保持良好，可读性高。由于学术论文句子常较长，翻译引擎需要理解整句语义才能正确断句和措辞。从译文看，GPT-4 引擎在这方面表现最佳，翻译后的句子流畅连贯，与人工翻译水平接近。而使用 Google 翻译时，个别长句会拆成数句翻译，导致译文略显琐碎，不过含义仍清晰。总体来说，只要所选引擎性能足够（如 DeepL、GPT 系），PDFMT 对学术文本的翻译质量是令人满意的。

值得一提的是，针对数学公式周边的文字工具也能正确处理。例如一些描述性文字中包含公式编号引用或变量说明，译文很好地保持了这些引用关系，没有出现张冠李戴的现象。这说明在内部实现中，工具将公式视为一个整体标记，对其周围文本的翻译采取了保护措施，避免了引擎因公式符号干扰而误译上下文。同时，对于公式内部偶尔出现的英文标注（比如图表中的标签、坐标轴标题），如果识别为可翻译文本，工具也提供了翻译。这体现了 PDFMT 对细节的把握：不放过应翻译的小片段，同时确保格式位置精准。

当然，翻译质量也取决于所使用的引擎模型。在尝试使用本地开源模型（如 7B 参数量级的模型）进行翻译时，我注意到译文在流畅度和准确度上不及云端大型模型，个别专业词汇会翻译错误或保持英文未译。这可以理解，毕竟小模型知识储备有限。但在无法联网或注重数据私密的情况下，本地模型能够运行本身已是一种取舍。建议对于高精度要求的场合，尽量使用质量较高的翻译服务（如 GPT-4、DeepL）来结合 PDFMT，以保证术语处理和语句自然度。

数学公式和排版结构保留

对于包含大量公式的 PDF 来说，公式完好保留与否往往决定了译文的可用程度。我们详细检查了译文 PDF 中的数学公式、符号、图表和排版结构，结果证明 PDFMT 在这方面的表现堪称其「杀手锏」。

首先，所有数学公式均未受到破坏或篡改。译文中的公式无论是在内容、位置还是样式上，都与原文保持一致。

在译文 PDF 中以完全相同的数学形式出现，只是在其下方的段落文字变为中文描述。而公式编号也保持原位。工具对公式对象采用了跳过翻译、直接复制的策略，并通过精确的版面重建将它们嵌入到正确的位置。这与一些简单 PDF 翻译工具相比是巨大优势——不少简单工具会因为无法识别公式，将其当成乱码处理，从而破坏了整句意义。而 PDFMT 则真正做到了 「数学表达式不被破坏」。

从上图示例可以直观感受到，PDFMT 输出的双语对照 PDF 将译文和原文按页并排显示，方便读者对照查看。双语版式是该工具的一大特色，可选项允许我们生成这种对照格式。在双栏论文的例子中，双语 PDF 将每一页拆分成左右两栏：左侧是原文的一栏，右侧是对应译文的一栏。页眉页脚、页码等也同步复制，使读者可以逐段比对。这对于精读学习或校对翻译非常有帮助。值得注意的是，如果原文本身是单栏，工具可能采取上下对应的方式呈现双语，但无论哪种，对齐关系都处理得很好，我们没有发现错页或者段落错位的问题。

在排版结构方面，译文对章节标题、段落、列表、表格等也都做了很好保留。原文的目录层级若为可点链接，译文 PDF 的目录功能同样有效。对于表格内容，PDFMT 会识别表格结构，将单元格文字翻译后再绘制表格。我们测试文件中有简单的符号对照表，译文表格对齐良好。不过对于极复杂的表格（如跨页大表、含合并单元格的财报表格等），由于测试文档中没有涉及，这里未详细验证。

有用户反馈某些复杂表格可能出现格式问题，但这可能是少数情况，总体来说常规表格能够正确翻译和呈现。

翻译速度与性能

翻译一份包含上百页、诸多公式图表的 PDF 文件，对计算性能是一个不小的考验。PDFMT 在这方面采用了一些优化手段。在我的老古董 Apple M1 Pro 16GB 翻译了一份 20 页的英文数学讲义，使用的引擎为 DeepL。整个过程耗时约 2分 32 秒。考虑到这份 PDF 每页都有公式或图形，这一速度可以接受。更换引擎后耗时略有不同：使用 OpenAI GPT-3.5 API 时由于单次翻译字数更多、网络延迟等因素，总耗时接近 4 分钟。翻译速度以及批量处理我并没有充分进行测试，一份 PDF 翻译效率取决于翻译引擎。

内存和资源占用方面，由于要加载版面分析模型和缓存 PDF 对象，工具运行时内存占用峰值达到了 420MB，CPU 占比峰值达到了 81% 左右。翻译过程中若使用大型模型则占用另计。

总的来说，在合理配置下，PDFMT 能够在几分钟内完成一般学术论文的翻译，这个效率对于个人研究者来说是可以接受的。在高性能服务器上并行处理，则可以胜任批量文档的翻译需求。当然，对于数百页的大部头文献，耐心等待仍是必要的；但相比手工翻译或逐页复制到翻译软件，这种自动化方式已经大大提升了效率。

存在的问题

尽管 PDFMT 功能强大且表现优异，但在实际使用和测试过程中，我们也发现了一些不足之处和可以改进的方面：

  1. 特定 PDF 格式的兼容性问题： 对于一些非常规的 PDF，可能会遇到困难。例如，加密处理 PDF、包含自定义字体、颜色标记的文档、包含矢量绘图或包含多媒体元素的 PDF，解析时可能出错，导致译文排版出现偏差。建议未来版本在解析前可以检测 PDF 的兼容性，针对已知有问题的格式给出提示，或者引入一些容错机制，以尽量减少信息丢失。
  2. 复杂语境下的翻译歧义： 虽然主流翻译引擎对一般技术文本表现很好，但在跨领域交叉的复杂语境中，仍可能出现语义理解偏差。例如「moment」一词在不同领域中可能含义不同，一篇跨领域的论文，可能会出现偏差。建议工具增加领域选项或术语表功能，让我们指定当前文档所属专业领域，从而调用更适合该领域的翻译模型或术语库，减少歧义。此外，一个可能的改进是引入术语记忆和人工校对接口：例如用户可以提供自定义术语表，翻译时优先使用表中翻译，以确保符合特定行业标准。
  3. 对网络和算力的依赖： 正如前文性能评估提到的，PDFMT 的完整运行依赖多方面资源：需要下载模型、调用 API，也需要本地运算。如果网络不稳定或服务器算力不足，翻译过程可能变慢甚至失败。改进建议是增加任务队列与断点续传机制。另外，可考虑优化对低算力环境的支持，例如提供「轻量模式」选项：关闭并行、降低预览刷新频率等，以降低 CPU 占用，防止因资源紧张造成崩溃。
  4. 缺乏深度人工校对交互： 虽然工具提供了实时预览供我们微调译文，但总体而言，这种人工参与是有限的。对于一些需要深度理解文档背景才能决定翻译的情况（比如带有文化隐喻的表述），完全依赖工具可能无法得到最优译文。建议未来增强人与机器的协同，例如提供交互式校对模式：在生成译文 PDF 的同时，输出一个可编辑的双语对照文本（如 Markdown 或 Word 格式），让人工可以针对有疑问的句子进行修改，然后再由工具自动合并生成最终 PDF。
  5. 图表内文字及更复杂的 OCR 支持： 目前版本对图像内嵌文字基本未翻译（因为大部分当作图形处理）。对于一些包含说明性文字的图表，这会使译文不够完整。改进方向可以是集成图像 OCR 识别，在确认图中包含可识别文字时，尝试提取并翻译再嵌回图中。难点在于保持字体和位置，不过哪怕作为图注文字放在图下也是一种方法。
  6. 用户文档和引导： 从用户反馈看，一些新人在配置 API 密钥、解决依赖问题上走了弯路，例如不知道需要安装微软 VC 运行库导致 .exe 启动失败。建议官方提供更详细的使用文档或引入引导 UI。在 GUI 中，可以加入配置检查提醒用户哪些翻译服务需要先设置密钥，以及提供输入界面，而不必让我们手动搞环境变量。这种易用性的提升会让工具被更广泛的人接受。

总体来说，这些不足并不影响 PDFMT 已有功能的实用性，而是对极端用例或用户体验方面的提升空间。

总结

PDFMathTranslate 展现出其作为「PDF 无损翻译神器」的实力：通过 AI 布局解析和多引擎翻译结合，它成功实现了学术 PDF 文档的全文双语翻译，并且几乎毫无损伤地保留了原始排版和数学公式。其功能完整性 —— 从丰富的翻译后端支持，到 CLI/GUI/Zotero插件/容器等多界面提供，以及内部针对公式、图表、目录等细节的处理，均令人印象深刻。性能方面，借助并行和缓存优化，它可以在合理时间内完成大文档和批量文档的翻译任务，对于科研、教育和企业用户都有实用价值。

当然，PDFMathTranslate 也有需要继续打磨的地方，例如对极端 PDF 格式的兼容、跨领域语义的精确把握，以及用户交互体验的优化等。但瑕不掩瑜，这些问题在很大程度上反映了 PDF 文档处理的固有复杂性，并非易事。随着开源社区的推动和 AI 技术的进步，我们有理由期待这些难题被逐步克服。开发团队已经展现了快速迭代的能力，例如不断添加新翻译服务后端、本地模型支持、优化 Windows 发行版等。

如果您正在寻求一款能正确处理数学公式的 PDF 翻译工具，PDFMathTranslate 当之无愧值得推荐。

PDFMathTranslate 依赖

PDF 解析 / 改写

  • pymupdf 1.25.2 (PyMuPDF)
  • pikepdf 9.7.0
  • pdfminer-six 20250416

PyMuPDF 负责低层指令流解析与渲染坐标；pikepdf 处理对象重组与加密；pdfminer-six 用于文本与布局信息抽取。

版面分析 & 视觉/OCR

  • opencv-python 4.11.0 + opencv-python-headless 4.11.0
  • rapidocr-onnxruntime 1.4.4
  • onnx 1.18.0
  • onnxruntime 1.22.0
  • scikit-image 0.25.2
  • shapely 2.1.1

YOLO-DocLayout & RapidOCR 走 ONNX 推理完成段落 / 公式 / 图表区块检测；OpenCV / scikit image 做图像预处理；Shapely、pyclipper 等做几何裁剪

数学公式保持 / 计算

  • sympy 1.14.0
  • mpmath

部分公式转写、符号解析、防止翻译器干扰

翻译引擎 SDK

  • openai 1.82.0
  • deepl 1.22.0
  • azure-ai-translation-text 1.0.1
  • tencentcloud-sdk-python-tmt 3.0.1386
  • ollama 0.4.8, xinference-client 1.6.0

调用 GPT-4/3.5、DeepL、Azure Translator、腾讯机器翻译、本地 Ollama LLM 或 Inference Server

模型/权重管理

  • huggingface-hub 0.32.0
  • fsspec
  • hf-xet

下载 / 缓存 DocLayout、RapidOCR 等模型及权重

Web GUI & API

  • gradio 5.31.0
  • gradio-pdf 0.0.22
  • fastapi 0.115.12
  • starlette 0.46.2
  • uvicorn 0.34.2
  • jinja2
  • websockets
  • pydantic 2.11.5
  • typer

提供本地浏览器界面、REST API 与 CLI 入口

数据存储 / 队列

  • peewee 3.18.1 (SQLite 默认)

缓存已译句段、任务状态等

科学计算 & 常用基础

  • numpy 2.2.6
  • pandas 2.2.3
  • scipy 1.15.3
  • tqdm
  • tenacity
  • rich
  • requests/httpx

数组运算、表格处理、进度条、重试、日志、HTTP 请求

其他辅助

  • rapidfuzz
  • regex
  • pyyaml
  • configargparse
  • psutil
  • pillow
  • fonttools

文本比对、正则解析、配置、资源占用监测、字体嵌入等

依赖层级

  • pdf2zh 元数据直接声明了 硬依赖：PyMuPDF、pdfminer-six、pikepdf、opencv-python-headless、rapidocr-onnxruntime、onnx/onnxruntime、huggingface-hub、gradio、fastapi、deepl、openai、azure-ai-translation-text、tencentcloud-tmt、ollama、numpy、pandas、peewee、tqdm、rich 等。
  • 其余如 scikit-image、sympy、shapely 是这些核心包的二级依赖或被 rapidocr-onnxruntime/布局检测模块拉入。
  • 开发/格式化工具（ruff、docformatter 等）仅随轮子打包一起装，对运行并非必需。
  • 简而言之：
    1. PDF 栈：PyMuPDF + pdfminer-six + pikepdf
    2. AI 布局 / OCR 栈：OpenCV + RapidOCR (ONNX) + scikit-image
    3. 翻译栈：多家商用 API SDK + 本地 LLM (Ollama)
    4. Web/CLI 栈：Gradio + FastAPI + Typer
    5. 数据 / 科学栈：NumPy、Pandas、SymPy 等
    6. 工具 / 辅助：Requests、TQDM、Rich、Tenacity…

> 关注 少数派小红书，感受精彩数字生活 🍃

> 实用、好用的 正版软件，少数派为你呈现 🚀