OCRmyPDF与Ghostscript 10.03.1版本兼容性问题分析

在文档数字化处理领域，OCRmyPDF作为一款优秀的开源工具，能够将扫描的PDF文档转换为可搜索的PDF文件。然而，近期随着Ghostscript升级到10.03.1版本，用户在使用OCRmyPDF时遇到了一个关键的兼容性问题。

问题本质

核心问题在于OCRmyPDF与新版Ghostscript交互时，文件参数传递顺序出现了错误。当用户尝试生成PDF/A格式（一种长期存档的PDF标准）时，OCRmyPDF错误地将PDFA定义文件放在了输入文件之后传递给Ghostscript，而Ghostscript 10.03.1版本对此顺序要求更为严格。

技术细节

根据Ghostscript官方文档，创建PDF/A文档的正确命令格式应该是：

gs -dPDFA=1 -dBATCH -dNOPAUSE -sColorConversionStrategy=RGB -sDEVICE=pdfwrite -sOutputFile=out-a.pdf PDFA_def.ps input.ps

关键点在于PDFA定义文件（PDFA_def.ps）必须位于输入文件之前。然而当前OCRmyPDF 13.4.0版本生成的命令却是：

gs [...] /tmp/fix_docinfo.pdf /tmp/pdfa.ps

这种错误的顺序导致Ghostscript无法在需要时获取PDF/A的配置信息，最终引发"rangecheck in .putdeviceprops"错误。

临时解决方案

目前用户可以通过以下两种方式暂时规避此问题：

1. 强制指定输出类型为标准PDF而非PDF/A：

   ocrmypdf --output-type pdf input.pdf output.pdf
   

2. 降级Ghostscript到10.03.1之前的版本

影响范围

此问题主要影响：

• 使用Ghostscript 10.03.1版本的用户
• 需要生成PDF/A格式输出的场景
• OCRmyPDF 13.4.0及可能更早版本

技术建议

对于开发者而言，修复此问题需要调整OCRmyPDF中生成Ghostscript命令的代码逻辑，确保PDFA定义文件参数始终位于输入文件之前。同时，这也提醒我们在处理外部依赖升级时，需要密切关注其参数规范的变化。

对于终端用户，建议关注OCRmyPDF的后续更新，官方很可能会发布针对此问题的修复版本。在此期间，使用上述临时解决方案可以保证基本功能的正常使用。