维护者笔记

这是为那些为下游使用打包OCRmyPDF的人准备的。（感谢你们的辛勤工作。）

已知的端口/打包器

OCRmyPDF 已经被移植到许多平台。如果你有兴趣移植到一个新平台，请查看 Repology 以了解该平台的状态。

pikepdf，由同一作者创建，是一个混合了Python和C++14的包，具有更严格的构建要求。如果你想在某些新平台或发行版上使用OCRmyPDF，首先确保你可以打包pikepdf。

请注意，我们有非Python的依赖项。特别是，OCRmyPDF需要安装Ghostscript和Tesseract OCR，并且需要能够在系统的PATH上找到它们的二进制文件。在Windows上，OCRmyPDF还会检查注册表以确定它们的位置。

Tesseract OCR 依赖 SIMD 来提高性能，并且仅在 ARM 和 x86_64 上得到适当支持。在其他处理器架构上，性能可能较差。

OCRmyPDF 使用 hatch-vcs 进行版本控制，该工具从 Git 中获取版本作为单一的真实来源。这可能不适合某些发行版，例如，用于表明您的发行版以某种方式修改了 OCRmyPDF。

如果需要，你可以修补src/ocrmypdf/_version.py中的__version__变量，或者设置环境变量SETUPTOOLS_SCM_PRETEND_VERSION为所需的版本，如果你出于某种原因需要覆盖版本控制。

OCRmyPDF 将使用 jbig2enc，一个 JBIG2 编码器，如果能够找到的话。一些发行版因为 JBIG2 包含专利算法而避免打包它，但所有专利自 2017 年以来都已过期。如果可能，考虑也打包它以改进 OCRmyPDF 的压缩。

请确保已安装命令行补全功能，如安装文档中所述。

如果您维护一个支持32位x86或ARM的Linux发行版，只要OCRmyPDF的所有依赖项继续以32位形式提供，它应该会继续工作。请注意，我们不在32位平台上进行测试。

OCRmyPDF 默认安装 pi-heif PyPI 包，该包支持从命令行将 HEIF（高效图像文件格式）图像转换为 PDF。如果您的发行版中没有此库可用，您可以排除它，OCRmyPDF 将自动优雅降级，仅失去对此功能的支持。