发布说明
OCRmyPDF 使用 语义版本控制 来管理其命令行界面和公共API。
OCRmyPDF的输出信息不被视为稳定接口的一部分 - 也就是说,输出信息可能会在任何发布版本中改进,因此解析它们可能不可靠。请使用API来依赖精确的行为。
公共API可能在启动OCRmyPDF进程或希望使用其某些功能处理PDF的脚本中有用。
OCRmyPDF 的最新版本是 。这些说明中提到的任何较新版本可能存在于主分支中,但尚未被标记。
OCRmyPDF 通常支持最近三个 Python 版本。
注意
注意维护者:这些发布说明可能会更新有关即将发布但尚未标记的版本的信息。只有当版本被标记并发布到PyPI时,它才是官方的。
v16.7.0
修复了Docker构建中的更多问题并更新了一些版本。
主Docker镜像已恢复为Ubuntu 24.04,因为v16.6.2中的修复解决了该问题。
之前将Ghostscript输出发送到stdout的代码已更改为输出到临时文件,因为Ghostscript在内部无论如何都会这样做。这是一个适度的效率改进。
修复了调试日志输出被解析为富文本标记的问题。#1444
v16.6.2
在PDF/A转换过程中,移除无效的超链接注释以满足Ghostscript 10.x的要求。#1425
v16.6.1
修复了Docker构建中的一些问题,例如删除了不必要的内容并使用稳定的Tesseract版本。
暂时将Docker镜像回滚到Ubuntu 22.04,以访问更旧/更稳定的Ghostscript。
在文档中澄清了批处理命令。
修复了HOCRResult的JSON序列化和pickle化的问题。#1427
v16.6.0
修复了损坏的PDF文件在使用
--redo-ocr时会失败的问题。#1403修复了在Windows上如果图像在早期步骤中已优化,则无法进行JBIG2优化的错误。#1396
修复了检测unpaper 7.0.0版本时的错误。#1409
修复了扫描页面时的性能回归问题。#1378。感谢 @aliemjay。
通过强制使用Alpine 3.19修复了Alpine Docker镜像。Alpine 3.20包含一个有缺陷的Tesseract OCR版本,因此不可用。
升级了Ubuntu Docker镜像以使用Ubuntu 24.04。
构建和测试脚本/操作已切换到uv。
在容器中运行时,我们现在提醒用户临时文件夹位于容器内部,可能无法访问。
修复了Linux测试覆盖矩阵,该矩阵缺少一些关键版本。
v16.5.0
v16.4.3
v16.4.2
v16.4.1
v16.4.0
选择
osd和equ伪语言与-l/--language现在在使用Tesseract OCR时会退出并报错,因为这些不是常规的Tesseract语言,而是实现的细节。使用它们可能会导致Tesseract崩溃。hOCR渲染器对输入文件中的额外空白更加宽容。
watcher.py 现在在输入不是 .pdf 时将输出文件扩展名更改为 .pdf。
改进了对包含循环引用表单XObjects的PDF的处理。 #1321
修复了ARM64的Alpine Docker镜像,该镜像之前无法正确构建。
Docker 镜像现在使用 pikepdf 9.0.0。
防止使用Tesseract OCR 5.4.0,这是一个已知存在退化的版本。
当设置了
--no-progress-bar时,禁用“线性化”的进度条。通过安装测试期间所需的库,修复了一些关于通过pikepdf缺少JBIG2解码的警告的测试。
v16.3.1
v16.3.0
v16.2.0
将格式化从black切换为ruff。
增加了将sidecar输出发送到io.BytesIO的支持。
增加了将HEIF/HEIC图像(iPhone和其他一些设备的原生图像)转换为PDF的支持,前提是安装了适当的pi-hief库。该库被标记为依赖项,但维护者可以根据需要选择退出。
我们现在默认会对超过Tesseract内部限制的大图像进行下采样,但仅当这会导致处理失败时才会进行。以前,这种行为只有在命令行上明确请求时才会发生。它仍然可以配置和禁用。请参阅–tesseract命令行选项。
添加了Macports安装说明。感谢@akierig。
在尝试获取第三方程序版本时发生意外错误时,改进了日志输出。
v16.1.2
修复了使用 Ghostscript 10.3 时测试套件失败的问题。
其他小修正。
v16.1.1
修复了PyPy 3.10的支持。
v16.1.0
改进后的hOCR渲染器现在是从左到右语言的默认设置。
改进了对旋转页面的处理。以前,对于在页面条目上使用/Rotate标签旋转的页面,OCR文本可能会丢失。
改进了对裁剪页面的处理。以前,在某些情况下,带有裁剪框的页面可能无法正确应用OCR,导致OCR文本和可见文本之间出现错位。
文档改进,特别是针对不太常见平台的安装说明。
v16.0.4
修复了新hOCR渲染器在从左到右文本中的一些问题。目前它还不是默认选项,但很快就会成为默认。从右到左的文本仍在开发中。
添加了一个错误以防止使用多个版本的Ghostscript,这些版本似乎会损坏输入PDF中的现有文本。新生成的OCR不受影响。为了获得最佳效果,请使用包含该问题修复的Ghostscript 10.02.1或更新版本。
v16.0.3
将最低要求的Ghostscript更改为9.54,以支持RHEL 9及其衍生版本的用户,因为这是那里可用的最新版本。
移除了关于CVE-2023-43115的警告信息,假设大多数发行版现在已经向后移植了补丁。
v16.0.2
暂时将PDF文本渲染器默认改回sandwich,以解决macOS预览中的回归问题。
v16.0.1
修复了新hOCR文本渲染器的文本渲染问题 - 多余的字节顺序标记。
收紧依赖关系。
v16.0.0
添加了OCR文本渲染器,结合了Tesseract的PDF生成器和旧的hOCR转换器渲染器的最佳理念。结果是一个希望永久解决提取文本中单词无空格连接问题的修复,更好地在倾斜基线上注册/定位文本#1009,修复了使用德国Fraktur字体时的字符输出问题#1191,正确渲染从右到左的语言(阿拉伯语、希伯来语、波斯语)#1157。亚洲语言可能仍然存在过多的单词断行问题。新的渲染器是默认的;旧的sandwich渲染器仍然可以通过
--pdf-renderer sandwich使用;旧的hOCR渲染器不再可用。ocrmypdf.hocrtransformAPI 发生了重大变化。不再支持 Python 3.9。现在需要 Python 3.10+。
现在需要 pikepdf >= 8.8.0。
v15.4.4
修复了在Windows上安装Ghostscript的文档。#1198
添加了关于旧版本Ghostscript中安全问题的警告信息。
v15.4.3
修复了在8.7.1之前的pikepdf中的弃用警告;现在需要pikepdf >= 8.7.1。
v15.4.2
我们现在对某一类PDF文件抛出异常,这些文件可能需要选择明确的颜色转换策略才能正确显示,以便进行PDF/A转换。
修复了在移除调试日志处理程序后尝试写入日志消息时发生的错误。
v15.4.1
v15.4.0
新增了实验性API以支持最终文本的离线编辑。 具体来说,现在可以使用OCRmyPDF生成hOCR文件,用其他工具编辑它们, 然后最终确定PDF。这些API是实验性的,可能会发生变化,包括工作文件夹的使用细节。 目前没有命令行界面。
代码重组:执行器、进度条、初始化和设置。
修复了在覆盖工具未能正确跟踪线程或子进程的情况下测试覆盖率的问题。此代码仍在测试中,但显示为未覆盖。
在测试套件中,减少使用子进程和其他干扰覆盖率测量的技术。
改进了当我们似乎在 snap 容器内运行且文件不可用时的错误检查。
插件规范现在正确定义了进度条为协议,而不是将它们定义为“类似tqdm”。
我们现在默认在POSIX平台上使用“forkserver”进程创建方法,而不是fork,因为这种方法更健壮,并且在存在线程时避免了一些问题。
修复了用户请求
--no-use-threads被忽略的情况。如果PDF的顶层对象没有语言元数据,我们会添加OCR语言。
用更有帮助的信息替换一些难以理解的测试错误消息。
关于OCRmyPDF如何为页面选择色彩空间的调试信息现在更加详细。
v15.3.1
修复了在上一版本中引入的 misc/watcher.py 日志设置问题。#1180
我们现在尝试在创建输出文件时保留输入的扩展属性。
出于某些原因,macOS 构建现在需要明确安装 OpenSSL。
更新了关于Docker性能问题的文档。
v15.3.0
更新 misc/watcher.py 以使用 Typer 改进命令行界面,并支持通过
.env指定环境变量。改进了错误信息。感谢 @mflagg2814 的 PR 促使了这一改进。改进了当文件无法读取时的错误信息,因为我们正在运行在一个snap容器中。
v15.2.0
添加了一个基于Alpine Linux的Docker镜像。这个镜像比基于Ubuntu的镜像更小,可能在某些情况下更有用。目前托管在jbarlow83/ocrmypdf-alpine。目前不支持ARM版本。
Ubuntu Docker 现在别名为 jbarlow83/ocrmypdf-ubuntu。
更新了Docker文档。
v15.1.0
我们现在需要Pillow 10.0.1版本,因为该依赖的所有早期版本存在严重的安全漏洞。该漏洞涉及WebP图像,并且在OCRmyPDF中从恶意WebP图像创建PDF时可能被触发。
向
ocrmypdf.ocr添加了一些之前接受但未记录的关键字参数。文档更新和类型改进。
v15.0.2
将Python 3.12添加到测试矩阵中。
更新了关于Python 3.12、32位支持以及v15中一些新功能的文档说明。
v15.0.1
Wheels Python 标签已更改为 py39。
标记为预期失败,该测试在最近的Ghostscript版本中失败。
澄清了关于32位支持范围的文档和发布说明。
更新了安装文档以反映v15中的更改。
v15.0.0
放弃了对 Python 3.8 的支持。
放弃了对一些较旧依赖项的支持,特别是
coloredlogs和tqdm,转而使用rich - 详情请参见pyproject.toml。一般来说,Ubuntu 22.04是我们的新基准系统。对一些依赖项的版本要求进行了收紧。
放弃了对32位Linux轮子的支持。我们强烈建议使用64位操作系统,以及64位版本的Python、Tesseract和Ghostscript来使用OCRmyPDF。我们的许多依赖项正在放弃32位构建(例如Pillow),我们也在效仿。(维护者仍然可以从源代码构建32位版本。)
更改为可信发布以进行PyPI发布。
pikepdf 的内存映射功能已重新启用以提高性能,因为 pikepdf 中的问题已修复。
ocrmypdf.helpers.calculate_downsample之前有两个变体,一个 接受PIL.Image,另一个接受tuple[int, int]。后者 已被移除。ocrmypdf 的 snap 版本现在基于 Ubuntu core22。
我们现在考虑了页面上图像的一小部分以高DPI(分辨率)绘制的情况。以前,整个页面会以任何特征的最高分辨率进行光栅化,这导致了性能问题。现在,页面根据页面的平均DPI进行光栅化,权重由每个特征占据的面积决定。通常,PDF中高分辨率的小区域是由于重复使用资源而产生的错误或怪癖,高分辨率并不有益。#1010, #1104, #1004, #1079, #1010
Ghostscript 颜色转换策略现在可以使用
--color-conversion-strategy进行配置。#1143JBIG2 优化的阈值现在可以通过
--jbig2-threshold进行配置。#1133
v14.4.0
v14.3.0
v14.2.1
修复了#977,其中Form XObjects中的图像总是被排除在图像优化之外。
v14.2.0
添加了
--tesseract-downsample-above以对较大的图像进行下采样,即使它们没有超过Tesseract的内部限制。这可以用于加速OCR,但可能会牺牲准确性。修复了旧版Pillow上的重采样AttributeError。#1096
移除了关于在使用具有/UserUnit功能的PDF上使用Ghostscript的错误。以前,Ghostscript无法处理这些PDF,但在所有支持的版本中,现在已支持此功能,因此不再需要此错误。
改进了关于安装Tesseract其他语言包的文档。
v14.1.0
添加了
--tesseract-non-ocr-timeout。这允许在使用--tesseract-timeout 0禁用OCR的同时,使用Tesseract的去斜和其他非OCR功能。添加了
--tesseract-downsample-large-images。这会对超过Tesseract能处理的最大图像尺寸的大图像进行下采样。大图像可能仍然需要很长时间来处理,但如果需要处理,这允许它们被处理。修复了#1082,一个与snap打包构建相关的问题。
将linter更改为ruff,修复lint错误,更新文档。
v14.0.4
v14.0.3
修复了#1068,避免在以root身份运行时删除/dev/null。
其他文档修复。
v14.0.2
修复了#1052,尝试处理某些不符合规范的PDF时出现的异常。
明确记录了不再支持Windows 32位系统。
修复了源代码安装说明。
其他文档修复。
v14.0.1
修复了一些使用智能版本比较进行的版本检查。
在Docker镜像中添加了缺失的jbig2dec。
v14.0.0
放弃了对 Python 3.7 的支持。
一般来说,放弃了对早于Ubuntu 20.04提供的所有依赖的支持。
现在需要 Ghostscript 9.50 或更高版本。支持旧版本的垫片已被移除。
现在需要Tesseract 4.1.1或更新版本。支持旧版本的垫片已被移除。
Docker 镜像现在使用 Tesseract 5。
放弃了setup.cfg配置,转而使用pyproject.toml。
移除了已弃用的异常 PdfMergeFailedError。
一些更多的公共领域测试文件被移除或替换。我们的目标是100%符合SPDX,并通常朝着简化版权的方向努力。
v13.7.0
修复了在尝试运行但未安装Tesseract时出现的异常。
更改为SPDX许可证跟踪和信息文件。
v13.6.2
添加了一个垫片以防止在Python 3.7和3.8中出现“错误处理期间的错误”。
现代化了一些类型注解。
改进了我们_windows模块的注释,以帮助IDE和mypy理解我们在做什么。
v13.6.1
需要 setuptools-scm 7.0.5 以避免早期版本的 setuptools-scm 中可能出现的源分发问题。
抑制虚假警告,改进测试,改进类型检查和其他杂项。
v13.6.0
v13.5.0
添加了一个新的
optimize_pdf插件钩子,使得创建能够替换或增强OCRMypdf的PDF优化器的插件成为可能。移除了所有最大版本限制。我们的新政策是将已知的不良版本列入黑名单,并仅阻止已知的不良依赖版本。
OCRmyPDF插入的所有OCR文本的对象的命名模式已更改。这一直是一个实现细节(并且仍然如此),但可能有人依赖它,并会感谢提前通知。
清理。
v13.4.7
v13.4.6
将损坏的ICC配置文件上的转换错误转换为警告。感谢@oscherler。
v13.4.5
移除pdfminer.six版本的上限。
文档。
v13.4.4
更新了pdfminer.six版本。
Docker 镜像已更改为 Ubuntu 22.04,因为它已经发布并提供了我们所需的依赖项。这似乎比我们最近更改为 Debian 更加一致。
v13.4.3
修复了在旧版本pytest中使用pytest.skip()时的错误。
文档更新。
v13.4.2
解决了 Ghostscript 9.56.0 中的一个主要回归问题 ,其中所有 OCR 文本都被从 PDF 中移除。它简单地移除了所有文本, 甚至包括非 OCRmyPDF 生成的文本。幸运的是,我们可以要求 Ghostscript 9.56.0 使用其旧的行为,这对我们的目的来说是有效的。 用户必须避免使用 (Ghostscript 9.56.0, ocrmypdf <13.4.2) 的组合,因为 旧版本的 OCRmyPDF 无法检测到这一特定版本的 Ghostscript 会移除所有 OCR 文本。
标记 pdfminer 20220319 为已支持。
修复了来自最新版本Pillow和pytest的一些弃用警告。
测试套件现在支持 Python 3.10(Python 3.10 之前运行良好,但未进行测试)。
Docker 镜像现在使用 debian:bookworm-slim 作为基础镜像,以修复 Docker 镜像构建问题。
v13.4.1
由于使用进程时存在持续的死锁问题,暂时将线程而非进程作为默认的执行器工作器。添加一个新的命令行参数
--no-use-threads来禁用此功能。
v13.4.0
修复了使用pikepdf 5.0.0时的测试失败问题。
对优化器进行了各种改进。特别是,我们现在能够识别使用deflate(PNG)和DCT(JPEG)编码的PDF图像,并且还生成使用deflate和DCT压缩图像的PDF,因为这通常比纯DCT能带来文件大小的改进。
v13.3.0
在未能优化图像使其不那么“吓人”后,产生了一个无害但“吓人”的异常。
如果页面图像太大,无法通过unpaper清理,则添加了一个警告。图像将未经清理直接通过。这是由于unpaper使用的C库中存在硬编码限制,因此无法轻易修复。
我们现在在调用 img2pdf 时使用更好的默认设置。
我们不再尝试优化在某些情况下未能保存的图像。
我们现在考虑了Tesseract 5与Tesseract 4在文本输出方面的一些差异。
更好地处理Ghostscript在尝试栅格化页面图像时生成空图像的问题。
v13.2.0
移除了所有运行时对distutils的使用,因为它在标准库中已被弃用。我们之前使用
distutils.version来检查依赖项的版本号,现在改用packaging.version。这是一个新的依赖项。修复了一个错误消息,该消息建议用户在实际上未安装Ghostscript时被抑制。
修复了进度条中显示的页码和总数不正确的问题。这纯粹是一个显示/呈现问题。#876。
v13.1.1
修复了在Tesseract 5上尝试对空白页面进行去斜处理的问题。#868。
v13.1.0
改为使用基于Python concurrent.futures的并行执行,而不是池,因为futures现在在功能上已经超过了池。
如果子工作进程被终止(可能是由操作系统或用户在任务管理器中终止),并行任务将失败并显示错误消息。以前,主ocrmypdf进程会无限期地“挂起”,等待子进程报告。
新增了参数
--tesseract-thresholding以提供对 Tesseract 5 的阈值参数的控制。文档更新和更改。为
--output-type none提供了更好的文档,这是在几个版本前添加的。删除了一些过时的文档。改进的bash自动补全功能 - 感谢@FPille。
v13.0.0
重大变更
已弃用的模块
ocrmypdf.leptonica已被移除。我们不再依赖Leptonica (
liblept) 或 CFFI (libffi,python3-cffi)。(请注意,Tesseract仍然需要Leptonica;OCRmyPDF不再直接使用这个库。)参数
--remove-background在我们寻找此功能的Leptonica实现的替代方案时暂时禁用。--threshold参数已被移除,因为它也依赖于 Leptonica。 Tesseract 5.x 已经改进了阈值处理,因此这个功能无论如何都是多余的。--deskew之前是通过Leptonica算法计算的。我们现在使用Tesseract的一个功能来找到适当的页面去斜角度。根据Tesseract的去斜角度可能与Leptonica的算法不同。至少在理论上,Tesseract的去斜角度是通过比Leptonica更复杂的分析得出的,因此这应该会改善整体结果。我们还使用Pillow来执行去斜操作,这可能会影响图像的外观,与Leptonica相比。由于该版本即将结束生命周期,因此不再支持Python 3.6。
我们现在需要pikepdf 4.0或更高版本。这反过来意味着OCRmyPDF需要一个与manylinux2014规范兼容的系统。这一变化是由于Pillow不再发布manylinux2010的轮子而“被迫”进行的。
我们不再提供requirements.txt格式的文件。请使用
pip install ocrmypdf[...]代替。提升了多个库的必需版本。
修复
修复了OCRmyPDF在Windows上即使安装了Ghostscript也无法找到并因此退出并报错的问题。
通过移除Leptonica,我们修复了所有与Leptonica在Apple Silicon上相关的问题,以及Leptonica在Windows上无法导入的问题。
v12.7.2
修复了使用非标准版本“5.0.0-rc1.20211030”进行Tesseract打包时出现的“无效版本号”错误。
修复了已弃用的
importlib.resources.read_binary的使用。将一些字符串路径的使用替换为
pathlib.Path。修复了在使用
--output-type none时的文件句柄泄漏问题。移除了不再支持的pikepdf版本的shims。
v12.7.1
声明支持 pdfminer.six v20211012。
v12.7.0
修复了在使用由pybind11 2.8.0编译的pikepdf 3.2.0时测试套件失败的问题。#843
如果OCR因此失败,改进关于使用
--max-image-mpixels的建议给用户。小规模文档修复。(感谢 @mara004。)
在Python版本中,如果标准库实现已经足够,则不需要importlib-metadata和importlib-resources的向后移植。 (感谢Marco Genasci。)
v12.6.0
实现了
--output-type=none以跳过为仅需要辅助文件的应用程序生成PDF(#787)。修复了
--jbig2-lossy行为描述中的歧义。文档的各种改进。
v12.5.0
修复了PyPy 3.6和pikepdf 3.0组合的构建失败问题。此组合在源码构建中可以工作,但在使用wheels时无法工作。
接受了想要升级我们已弃用的requirements.txt的机器人。
文档更新。
用 importlib-metadata 和 importlib-resources 替换 pkg_resources 并在 setuptools 上安装依赖。
修复了在hocrtransform中导致文本在使用此渲染器时被省略的回归问题。
修复了一些打字错误。
v12.4.0
在移植文本层时,如果可用,请使用pikepdf的
unparse_content_stream。确认支持 pluggy 1.0。(感谢 @QuLogic。)
修复了一些打字问题,改进了预提交设置,并修复了由linter标记的问题。
PyPy 7.3.3 (=Python 3.6) 现已支持。请注意,PyPy 并不一定运行得更快,因为 OCRmyPDF 的大部分执行时间都花在运行 OCR 或执行原生代码上。然而,PyPy 在某些领域可能会带来速度提升。
v12.3.3
watcher.py: 修复了布尔环境变量的解释 (#821)。
调整CI脚本以测试Tesseract 5测试版。
记录我们对Tesseract 5测试版的支持。
v12.3.2
v12.3.1
修复了使用hOCR渲染器时文本选择的问题(#813)。
通过升级到较新的Ubuntu版本修复了Docker镜像的构建错误。 同时将此镜像的时区设置为UTC。
v12.3.0
修复了Pillow 8.3.0中引入的一个回归问题。Pillow不再对图像分辨率的DPI进行四舍五入。我们现在已经解决了这个问题(#802)。
我们不再使用一些在最新版本的pikepdf中已弃用的API调用。
当请求的语言看起来不像典型的ISO 639-2代码时,改进了错误消息。
修复了一些在Windows上尝试创建符号链接的测试,这些测试在Windows桌面上会失败,但在CI上通常不会。
文档修复(感谢 @mara004)
v12.2.0
修复了Windows上无效的Tesseract版本号 (#795).
文档调整。文档构建现在依赖于 sphinx-issues 包。
v12.1.0
出于安全原因,我们现在要求 Pillow >= 8.2.x。(如果无法升级,旧版本将继续工作。)
构建系统被重新组织,以依赖
setup.cfg而不是setup.py。 所有更改应与之前支持的setuptools版本兼容。requirements/*中的文件现在被视为已弃用,但将在 v12 中保留。 请使用pip install ocrmypdf[test]而不是requirements/test.txt等。 这些文件将在 v13 中移除。
v12.0.3
扩展hocr PDF渲染器支持的语言列表。 之前认为不支持某些语言,特别是那些使用拉丁字母的非欧洲语言。
修复了在详细模式下异常堆栈跟踪被抑制的情况。
改进了商业OCR的文档。
v12.0.2
修复了在对包含小图像的文件使用
--remove-background时抛出的异常 (#769)。改进关于向Docker镜像添加语言包的文档描述,并更正了法语语言包的名称。
v12.0.1
修复了未标记的tesseract版本的“无效版本号”问题 (#770)。
v12.0.0
重大变更
由于最近在pikepdf、Pillow和reportlab中出现的安全问题,我们现在需要这些库及其一些依赖项的更新版本。(如有必要,包维护者可以根据自己的判断覆盖这些版本;较低的版本通常也能正常工作。)
我们现在在指导Ghostscript创建PDF/A时使用“LeaveColorUnchanged”颜色转换策略。通常这比执行颜色转换更快,而颜色转换并不总是必要的。
OCR文本现在被打包在一个Form XObject中。这使得从其他文档内容中隔离OCR变得更加容易。然而,一些实现不佳的PDF文本提取算法可能无法检测到文本。
许多API函数现在有更严格的参数检查,或者期望使用关键字参数,而以前并不需要。
ocrmypdf.optimize中的一些已弃用函数已被移除。由于在较新的平台(如Apple Silicon)上使用ABI绑定的当前策略存在困难,
ocrmypdf.leptonica模块现已弃用。它将被移除并替换,可能是通过将Leptonica重新打包为独立库,或者使用不同的图像处理库。持续集成已迁移至GitHub Actions。
我们不再依赖
pytest_helpers_namespace进行测试。
新功能
新插件钩子:
get_progressbar_class,用于进度报告,允许开发者用其他机制替换标准控制台进度条,例如更新GUI进度条。新插件钩子:
get_executor,用于替换并发模型。 这主要是为了支持在AWS Lambda上执行,由于缺乏共享内存,AWS Lambda不支持标准的Pythonmultiprocessing。新插件钩子:
get_logging_console,用于替换 OCRmyPDF 输出其消息的标准方式。新插件钩子:
filter_pdf_page,用于修改由OCRmyPDF生成的单个PDF页面。OCRmyPDF 现在可以在没有进程间信号量的非标准执行环境中运行,例如 AWS Lambda 和 Android Termux。如果环境中没有信号量,OCRmyPDF 将自动选择一个不使用信号量的替代进程执行器。
持续集成已迁移至GitHub Actions。
我们现在生成一个与x64镜像兼容的ARM64 Docker镜像。 感谢@andkrause几个月前在一个拉取请求中完成了大部分工作,我们现在终于能够将其集成进来。同时感谢@0x326的审查意见。
修复
修复了在使用旧版本Leptonica时尝试刷新
sys.stderr时可能出现的死锁问题。一些工作进程从其父进程继承了资源,例如日志处理程序,这些资源也可能导致死锁。这些资源现在已被释放。
测试覆盖率的改进。
移除了对早于4.0.0-beta1版本的Tesseract的支持(该版本随Ubuntu 18.04一起发布)。
OCRmyPDF 现在可以解析所有 Tesseract 版本号,因为已经使用了多种方案。
修复了在解析包含以0比例绘制的图像的PDF时出现的问题。(#761)
移除了关于禁用mmap的频繁重复消息。
v11.7.3
排除CCITT Group 3图像不被优化。OCRmyPDF使用的一些库似乎无法正确处理这种晦涩的压缩格式。如果没有此修复,您可能会遇到错误或可能的损坏输出图像。
v11.7.2
更新了main.txt中的固定版本,主要是为了将Pillow升级到8.1.2,因为该软件最近披露了安全漏洞。
如果
--sidecar参数设置为与输入或输出PDF相同的文件,现在会导致异常。
v11.7.1
在尝试图像优化时,一些异常仅在调试级别记录,导致它们被抑制。现在这些错误已被适当地记录。
改进了与
--unpaper-args相关的错误信息。更新了文档以提及新的conda发行版。
v11.7.0
我们现在支持将
--sidecar与--pages一起使用;这些参数过去是互斥的。(#735)修复了PDF/A-1b生成中可能存在的问题。Acrobat抱怨我们的PDF使用了对象流。像veraPDF这样更强大的PDF/A验证器并不认为这是一个问题,但从现在开始,我们将尊重Acrobat的反对意见。这可能会增加PDF/A-1b文件的大小。PDF/A-2b文件不会受到影响。
v11.6.2
修复了一个回归问题,该问题在使用诸如
--deskew --rotate-pages参数时会产生错误的页面方向 (#730)。
v11.6.1
修复了尝试优化异常窄宽度图像的问题,通过将这些图像排除在优化之外 (#732)。
移除一个不再支持的pikepdf版本的过时兼容性垫片。
v11.6.0
OCRmyPDF 现在会自动从相同的虚拟环境中注册插件,并使用适当的 setuptools 入口点。
重构插件管理器,以移除不必要的复杂性,并使插件注册更加自动化。
PageContext和PdfContext现在正式成为 API 的一部分,因为它们本应如此,因为它们已经是ocrmypdf.pluginspec的一部分。
v11.5.0
修复了一个问题,当使用
--force-ocr并且页面包含具有多种分辨率的对象时,输出页面大小可能因四舍五入而略有不同。在确定页面栅格化的分辨率时,我们现在将页面上的打印文本视为需要更高的分辨率。这修复了某些页面以不可接受的低分辨率文本呈现的问题,但在某些工作流程中,如果低分辨率文本是可接受的,可能会增加输出文件的大小。
添加了一个解决方法,以修复在Apple ARM芯片(或其他可能不允许写+可执行内存的平台)上尝试
import ocrmypdf.leptonica时发生的异常。
v11.4.5
修复了使用API时文件可能未关闭的问题。
改进了
setup.cfg,提供了更好的测试覆盖率设置。
v11.4.4
修复了
AttributeError: 'NoneType' object has no attribute 'userunit'(#700),与 OCRmyPDF 未正确转发来自 pdfminer.six 的错误消息有关。调整了一些参数的输入类型。
ocrmypdf.ocr现在接受一个threading.Lock,原因在文档中有说明。
v11.4.3
删除了冗余的调试信息。
测试套件现在断言大多数修补过的函数在应该被调用时被调用。
测试套件现在跳过了在piekpdf的两个特定版本上失败的测试。
v11.4.2
修复了对Cygwin的支持,希望如此。
watcher.py: 修复了OCR_LOGLEVEL未被解释的问题。
v11.4.1
修复了使用
pages参数传递无效页面范围(例如“1-0”)导致未处理异常的问题。接受了用户对Synology演示脚本的贡献,位于misc/synology.py。
澄清了关于临时文件位置更改的文档
ocrmypdf.io。修复了Python wheel标签,该标签错误地设置为py35,尽管我们早已停止支持Python 3.5。
v11.4.0
在寻找Tesseract和Ghostscript时,我们现在会检查Windows注册表,以查看它们的安装程序是否注册了其可执行文件的位置。这应该有助于那些将这些程序安装到非标准位置的Windows用户。
我们现在报告PDF/A转换的进度,因为这个操作有时很慢。
改进了命令行补全功能。
OCRmyPDF创建的临时文件夹的前缀已从
com.github.ocrmypdf更改为ocrmypdf.io。选择依赖此前缀的脚本可能需要调整。(这一直是一个实现细节,因此不被视为语义版本控制“合同”的一部分。)修复了#692,其中包含损坏字体的特定文件会通过生成大量调试消息来淹没内部消息队列。
修复了处理没有页面记录的hOCR文件时的异常。已知Tesseract不会生成此类文件。
v11.3.4
修复了在使用pikepdf 2.1.0时可能出现的错误信息‘called readLinearizationData for file that is not linearized’。(升级到pikepdf 2.1.1也可以解决此问题。)
文件监视器现在自动包括
.PDF和.pdf,以更好地支持区分大小写的文件系统。一些文档和注释的改进。
v11.3.3
如果unpaper输出非UTF-8数据,悄悄地修复这个问题,而不是在转换时出错。(可能解决了#671。)
v11.3.2
v11.3.1
声明对新版本的支持:pdfminer.six 20201018 和 pikepdf 2.x
修复了与
--pdfa-image-compression相关的警告,该警告在不正确的时间出现。
v11.3.0
当OCR被禁用时,输出消息中的“OCR”步骤被描述为“图像处理”,以更好地解释应用程序的行为。
调试日志现在仅在作为命令行运行时创建,而不是在为API调用执行OCR时创建。调用应用程序负责设置日志记录。
对于页数较少的PDF,我们在一个线程中收集有关输入PDF的信息,而不是在进程中进行处理(当有更多页面时)。当作为线程运行时,我们没有关闭工作PDF的文件句柄,导致每次调用
ocrmypdf.ocr时都会泄漏一个文件句柄。修复了一个问题,即子工作进程发送的调试消息与父进程的日志设置不匹配,导致消息被丢弃。此问题仅影响macOS和Windows,其中父进程未分叉。
修复了rasterize_pdf_page的hookspec,以移除默认参数,这些参数未按预期方式由pluggy处理。
修复了由于上述问题导致的自动页面旋转的另一个问题 (#658)。
v11.2.1
修复了一个问题,其中优化为JBIG2的带有调色板或相关ICC的1位图像可能会发生颜色反转。
v11.2.0
修复了优化带有软遮罩或图像遮罩的PNG类型图像时的问题。 这是在(或大约)v11.1.0中引入的回归问题。
改进了对
ocrmypdf.ocrAPI调用中plugins参数的类型检查。
v11.1.2
修复了hOCR渲染器以大致相反的顺序写入文本的问题。这不应影响能够正确定位所有文本位置的合理智能PDF阅读器,但可能会混淆那些依赖内容流中对象顺序的阅读器。(#642)
v11.1.1
我们现在在使用pngquant时避免使用命名的临时文件,从而允许使用容器化的pngquant安装。
澄清了一条错误信息。
发布版本中1的数量创历史新高!
v11.1.0
v11.0.2
修复了#612,TypeError异常。通过消除在内存中不必要的输入PDF元数据修复来解决。
v11.0.1
黑名单 pdfminer.six 20200720,该版本在20200726中修复了一个回归问题。
批准 img2pdf 0.4,因为它通过了测试。
澄清在v11.0.0版本中,pdfa.py的GPL-3部分已被移除;debian/copyright文件未正确标注此更改。
v11.0.0
项目许可证已更改为Mozilla公共许可证2.0。一些杂项代码现在采用MIT许可证,非代码内容/媒体仍采用CC-BY-SA 4.0许可证。许可证的更改已获得所有被发现对项目GPLv3许可部分有贡献的人的批准。(#600)
由于许可证变更,这被视为主要版本号更改;然而,与v10.x相比,在功能行为或API方面没有已知的重大更改。
v10.3.3
修复了在图像上使用
--threshold时出现的“KeyError: 'dpi'”错误消息。 (#607)
v10.3.2
修复了一个情况,当我们能够确定文件大小增加的原因时,却报告了“没有原因”。
启用了对 pdfminer.six 20200726 的支持。
v10.3.1
修复了使用早于20200402版本的pdfminer.six时出现的多个测试套件失败问题。
启用了对 pdfminer.six 20200720 的支持。
v10.3.0
修复了一个问题,即我们会考虑已经JBIG2编码的图像进行优化,可能会导致生成的图像比原始图像优化程度降低。我们相信这个问题不会导致图像失去保真度。
在可用的情况下,现在使用pikepdf内存映射。这提高了性能。
当安装了Leptonica 1.79+时,使用其新的错误处理API来避免对stderr的“混乱”重定向,这是捕获其错误消息所必需的。
对于旧版本的Leptonica,添加了一个新的线程级锁。这修复了在Leptonica中处理错误条件时可能出现的竞争条件(尽管没有证据表明它在实践中曾引起问题)。
文档改进和更多的类型提示。
v10.2.1
禁用了使用pdfminer计算文本框顺序的功能。我们从未需要这个结果,并且在具有复杂预存文本的文件上计算成本很高。
修复了插件管理器以接受
Path(plugin)作为插件的路径。修复了一些打字错误。
文档改进。
v10.2.0
更新Docker镜像以使用Ubuntu 20.04。
修复了PDF/A转换后标题变为“无标题”的问题。(#582)
修复了在使用
--pdf-renderer hocr时,使用较新版本的Tesseract时输出中会丢失一些文本的问题。Tesseract开始添加更多关于文本语义的详细标记,而我们的HOCR转换未能识别这些标记,因此忽略了它们。此选项不是默认选项。如有必要,--redo-ocr也可以重新进行OCR以修复此类问题。修复了Python 3.9测试版中的一个错误,原因是移除了已弃用的
Element.getchildren()。 (#584)实现了使用API与
BytesIO和其他文件流对象的支持。 (#545)
v10.1.1
修复了在某些输入文件上设置
OMP_THREAD_LIMIT为无效值时的错误消息。(该错误是无害的,除了在某些情况下性能不如最佳。)
v10.1.0
之前,我们
--clean-final会导致未经过unpaper清理的页面图像被生成两次,这在某些情况下是必要的,但通常不是。我们现在利用这个优化机会,尽可能重用图像。我们现在提供PNG文件作为unpaper的输入,因为它接受这些文件,而不是生成可能非常大的PPM文件。这可以提高性能和临时磁盘使用率。
插件文档已更新。
v10.0.1
修复了从命令行使用
-l lang1+lang2时的回归问题。
v10.0.0
重大变更
对 pdfminer.six 版本 20181108 的支持已被取消,同时取消的还有一个使该版本工作的猴子补丁。
输出消息现在以颜色显示(当终端支持时),并且描述消息严重程度的前缀已被移除。因此,解析OCRmyPDF日志消息的程序需要进行修订。(请考虑将OCRmyPDF作为库使用。)
某些依赖项的最低版本已提高。
许多API变更;请参阅开发者变更。
现在需要Python库pluggy和coloredlogs。
新功能和改进
PDF页面扫描现在在CPU之间并行化,对于页数较多的文件,这一阶段的速度显著加快。
PDF页面扫描已优化,解决了一些性能回归问题。
当使用
--pages参数时,PDF页面扫描不再在未选择的页面上运行。PDF页面扫描现在独立于Ghostscript,结束了我们过去对Ghostscript中这一偶尔不稳定的功能的依赖。
已添加插件架构,目前允许用户更轻松地使用不同的OCR引擎或PDF渲染器,分别替代Tesseract和Ghostscript。插件还可以覆盖某些决策,例如在初始扫描后更改OCR设置。
彩色日志消息。
开发者变更
测试欺骗机制,用于测试Tesseract和Ghostscript中故障的正确处理,已被移除,转而使用插件进行测试。欺骗机制相当复杂,并且在Windows上需要许多特殊的技巧。
描述图像DPI分辨率的代码被重构为一个
ocrmypdf.helpers.Resolution类。模块
ocrmypdf._exec现在对 OCRmyPDF 是私有的。ocrmypdf.hocrtransform模块已更新以遵循 PEP8 命名规范。Ghostscript 不再用于查找 PDF 中文本的位置,与此功能相关的 API 已被移除。
大量的内部重组以支持插件。
v9.8.2
修复了OCRmyPDF在判断文档是否已有文本时忽略Form XObject内部文本的问题。
修复了文件大小增加警告,以考虑小文件的开销。
添加了在Cygwin上安装的说明。
v9.8.1
修复了在
%PROGRAMFILES%\gs目录(Windows)中存在意外文件导致异常的问题。标记 pdfminer.six 20200517 为已支持。
如果缺少jbig2enc并且请求了优化,则会发出警告而不是错误,这是预期的行为。
文档更新。
v9.8.0
修复了文件中只有第一个PNG(FlateDecode)图像会被考虑进行优化的问题。从今以后,文件大小应该会有所改善。
修复了选择语言为日语时启动崩溃的问题 (#543).
添加了选项以配置watcher.py的轮询和日志级别。
v9.7.2
修复了
ocrmypdf.ocr(...language=)不接受文档中列出的语言列表的问题。更新了setup.py以确认支持pdfminer.six版本20200402。
v9.7.1
修复了与 qpdf 10.0.0 一起使用时版本检查失败的问题。
添加了一些缺失的类型注解。
更新了文档以警告需要“ifmain”保护和Windows。
v9.7.0
修复了如果未定义
OCR_JSON_SETTINGS时watcher.py中的错误。Ghostscript 9.51 现在已被列入黑名单,因为此版本存在许多问题。
为Ghostscript 9.52中的“txtwrite”问题添加了一个临时解决方案。
修复了在操作
OMP_THREAD_LIMIT时显示错误线程数的问题。移除了在同一页面上使用数百到数千张图像时可能出现的性能瓶颈。
文档改进。
优化现在将应用于一些定义了颜色配置文件的单色图像,而不仅仅是黑白图像。
在确定图像的简化色彩空间时,会参考ICC配置文件。
v9.6.1
文档改进 - 感谢许多用户的贡献!
修复了ArchLinux的安装说明 (@pigmonkey)
更新了FreeBSD和其他操作系统的安装说明 (@knobix)
添加了使用Docker Compose与watchdog的说明 (@ianalexander, @deisi)
其他杂项 (@mb720, @toy, @caiofacchinato)
文档中提供的一些脚本已被迁移出去,以便它们可以作为整个文件复制出来,并确保语法检查得以保持。
修复了OCRmyPDF在处理PDF时,因
/Trailer /Info中的错误对象类型而抛出异常的罕见情况。现在错误会被记录,并且错误的对象会被忽略。(#497)移除了可能非免费的文件
enron1.pdf并简化了使用它的测试。移除了可能非自由的文件
misc/media/logo.afdesign。
v9.6.0
修复了在某些情况下将元数据从输入PDF传输到输出PDF时的回归问题。
pdfminer.six 现在支持到 2020-01-24 版本。
解释页面旋转决策的消息现在再次在标准详细级别显示,当使用
--rotate-pages时。在之前的某些版本中,它们被设置为调试级别的消息,只有在使用参数-v1时才会出现。对
misc/watcher.py的改进。感谢@ianalexander和@svenihoney。文档改进。
v9.5.0
添加了用于测量OCR质量的API函数。
对处理具有困难/不符合标准的元数据的PDF进行了适度的改进。
v9.4.0
更新了推荐的依赖版本。
改进测试覆盖率并更改以促进更好地测量测试覆盖率,例如当测试在子进程中运行时。
当Leptonica未正确安装时,错误消息的改进。
修复了可能导致某些间歇性CI失败的pytest“会话范围”的使用。
当参数
--keep-temporary-files或详细程度设置为-v1时,会在工作临时文件夹中生成一个调试日志文件。
v9.3.0
改进了对原生Windows的支持:我们现在会在“Program Files”文件夹中明显的位置检查Tesseract和Ghostscript的安装,而不是依赖用户编辑
PATH来指定它们的位置。当存在多个安装或程序安装到非标准位置时,仍然可以使用PATH环境变量来区分。修复了解析Ghostscript错误消息时的异常。
添加了一个改进的示例,演示了如何设置一个监视文件夹以进行自动OCR处理(感谢@ianalexander的贡献)。
v9.2.0
现在支持原生Windows。
持续集成已迁移到Azure Pipelines。
提高了测试覆盖率和测试速度。
修复了一个问题,即原本是JPEG格式的页面会被保存为PNG格式,从而增加文件大小。此问题仅在选择了预处理选项以及
--output-type=pdf并且原始页面上的所有图像都是JPEG格式时发生。自v7.0.0版本以来的回归问题。OCRmyPDF 不再依赖于 QPDF 可执行文件
qpdf或libqpdf。 它使用 pikepdf(而 pikepdf 又依赖于libqpdf)。包维护者 应调整依赖关系,使 OCRmyPDF 不再自行调用 libqpdf。 对于使用 Python 二进制轮子的用户,这一变化意味着不再需要单独安装 QPDF。这一变化主要是为了 简化在 Windows 上的安装。修复了Tesseract日志消息被丢弃的罕见情况。
修复了pixFindPageForeground函数签名错误,导致在某些平台/Leptonica版本上出现异常的问题。
v9.1.1
扩展支持的pdfminer.six版本范围。
修复了使用pikepdf 1.7.0时的Docker构建问题。
修复了文档,建议使用从get-pip.py获取的pip。
v9.1.0
改进了文件大小在输出时增加的诊断。现在如果JBIG2或pngquant不可用时会发出警告。
现在需要 pikepdf 1.7.0,以获取在运行 Python 3.8 的 Linux 系统上无需源代码安装的更改。
v9.0.5
由于支持Alpine Linux的困难,Alpine Docker镜像(jbarlow83/ocrmypdf-alpine)已被放弃。
主要的Docker镜像(jbarlow83/ocrmypdf)已经改进,以承担以前仅Alpine镜像独有的额外功能。
无需更改应用程序代码。
pdfminer.six 版本 20191020 现已支持。
v9.0.4
修复了与Python 3.8的兼容性(但目前需要从源代码安装)。
修复了Tesseract设置中的
--user-words和--user-patterns。更改为 pikepdf 1.6.5(适用于 Python 3.8)。
更改为 Pillow 6.2.0(以缓解早期 Pillow 中的安全漏洞)。
调试消息现在会提到如果区域设置不是英语时,英语会自动被选择的情况。
v9.0.3
在中间Postscript文件中嵌入sRGB ICC配置文件的编码版本(用于PDF/A转换)。以前我们包含了文件名,这要求Postscript在启用文件访问的情况下运行。出于安全考虑,Ghostscript 9.28启用了
-dSAFER,因此默认情况下不再允许访问任何文件。此修复对于与Ghostscript 9.28的兼容性是必要的。从标准测试套件中排除一个有时会超时并在持续集成中失败的测试。
v9.0.2
图像优化器现在在某些情况下会跳过优化flate(PNG)编码的图像,因为这些情况下优化努力可能被浪费。
图像优化器现在忽略指定任意解码数组的图像,因为这些情况很少见。
修复了导致单色图像中黑白反转的问题。 我们不确定,但问题似乎与Leptonica 1.76.0及更早版本有关。
修复了一些在未安装英语或德语Tesseract语言包时测试套件失败的情况。
修复了如果未安装Tesseract英语语言时的运行时错误。
改进了在使用后显式关闭Pillow图像。
实际上修复了Alpine Docker镜像的构建。
更改为 pikepdf 1.6.3。
v9.0.1
修复了当可选依赖项 unpaper 和 pngquant 中任何一个缺失时测试套件失败的问题。
尝试修复Alpine Docker镜像构建。
已记录FreeBSD端口现已可用。
更改为 pikepdf 1.6.1。
v9.0.0
重大变更
由于底层库(Leptonica)实现此功能的可靠性较差且偶尔会崩溃,
--mask-barcodes实验性功能已被取消。-v(详细级别)参数现在只接受0、1和2。放弃了对Tesseract 4.00.00-alpha版本的支持。Tesseract 4.0 beta及更高版本仍然得到支持。
删除了
ocrmypdf-polyglot和ocrmypdf-webservice镜像。
新功能
为希望集成OCRmyPDF的应用程序添加了一个高级API。 特别感谢Martin Wind(@mawi1988),他为这项工作做出了重大贡献。
为长时间运行的步骤添加了进度条。 ■■■■■■■□□
我们现在默认创建线性化(“快速网页视图”)PDF。新参数
--fast-web-view提供了控制何时应用此功能的功能。新增了一个
--pages功能,用于将OCR限制在特定的页面范围内。 列表可以包含逗号或单个页面,例如1, 3, 5-11。当页面数量相对于允许的作业数量较少时,我们会在可用时以多线程(OpenMP)模式运行Tesseract。这应该会提高页面数量较少的文件的性能。
移除了对
ruffus的依赖,因此也消除了之前使 API 无法实现的重入限制。输出和日志消息进行了全面改进,以便ocrmypdf可以集成到使用日志模块的应用程序中。
需要 pikepdf 1.6.0。
添加了一个标志。😊
错误修复
带有矢量图稿的页面被视为全彩色。以前,在考虑覆盖页面所需的色彩空间时,矢量图被忽略,这可能导致在某些设置下丢失颜色。
测试套件现在减少了生成进程的频率,从而可以更准确地测量代码覆盖率。
提高了测试覆盖率。
修复了一个罕见的除以零错误(如果优化生成了无效文件)。
更新了Docker镜像以使用较新的版本。
修复了使用非
/DeviceGray色彩空间编码的JBIG2图像未正确解释的问题。修复了当页面的MediaBox具有非零角时的OCR文本图像配准(即对齐)问题。
v8.3.2
删除了允许在macOS上无需pdfminer.six即可工作的变通方法,现在pdfminer.six的适当sdist版本已可用。
现在需要 pikepdf 1.5.0。
v8.3.1
修复了带有错误元数据的PDF文件会被渲染为空白页面的问题。#398。
v8.3.0
改进了在生成页面新图像时更新页面的策略。我们现在尝试保留更多原始文件的内容,特别是注释部分。
对于超过100页的PDF文件,如果在一个序列中替换了一个PDF页面并跳过一个或多个后续页面,那么在移植OCR文本时,中间文件可能会损坏,导致处理失败。这是一个回归问题,可能是在v8.2.4版本中引入的。
之前,我们对Ghostscript生成的图像进行了少量像素的调整,以确保输出图像的大小完全符合我们的要求。在发现了一种让Ghostscript生成我们所需精确图像大小的方法后,我们取消了调整大小的步骤。
除了
fish之外,现在还可以在misc/completion中找到bash的命令行补全功能。包维护者,请安装这些文件,以便用户可以利用它们。更新了需求。
现在需要 pikepdf 1.3.0。
v8.2.4
修复了在检查某种只有Acrobat可以读取的PDF类型时的误报问题。我们现在更准确地检测仅Acrobat可读的PDF。
OCRmyPDF 持有较少的打开文件句柄,并且更及时地释放不再需要的句柄。
小优化:我们不再遍历目录以确保其中的所有引用都已解析,因为对libqpdf的更改使得这一步骤不再必要。
现在需要 pikepdf 1.2.0。
v8.2.3
修复了
--mask-barcodes偶尔会在当前工作文件夹中留下一个名为junkpixt的不需要的临时文件的问题。修复(希望如此)在存在非标准
sys.stderr的环境中处理 Leptonica 错误的问题。改进了
--verbose的帮助文本。
v8.2.2
修复了v8.2.0版本中的一个回归问题,该问题在尝试报告
unpaper或其他可选依赖不可用时发生异常。在某些情况下,当
unpaper未安装时,ocrmypdf [-c|--clean]未能退出并报错。
v8.2.1
此版本已取消。
v8.2.0
由于@mawi12345的辛勤工作,我们的Docker镜像现在有了重大改进。新的Docker镜像ocrmypdf-alpine基于Alpine Linux,并且在一个更小的包中包含了三个现有镜像的大部分功能。这个镜像最终将取代主要的Docker镜像,但目前所有镜像都在构建中。查看文档以获取详细信息。
文档特别围绕Docker镜像的使用进行了重组。
修复了PDF图像优化中的一个问题,即优化器会不必要地解压缩并重新压缩PNG图像,在某些情况下会失去刚刚执行的量化的好处。优化器现在能够将PNG图像嵌入PDF中而无需转码。
修复了有损JBIG2图像优化中的一个小的回归问题。所有JBIG2候选图像被错误地放入整个文件的单个优化组中,而不是将页面分组在一起。这通常会导致更大的JBIG2Globals字典,并导致压缩效果较差,因此它的效果不如设计的那样好。然而,质量不会受到影响。无损JBIG2完全未受影响。
更新了依赖项,包括将pikepdf升级到1.1.0。这修复了 #358。
安装时对外部程序的版本检查已从setup.py中移除。这些测试现在在运行时执行。
覆盖安装时检查的非标准选项 (
setup.py install --force) 现在已被弃用并会打印一个 警告。它将在未来的版本中被移除。
v8.1.0
添加了一个功能,
--unpaper-args,它允许在使用--clean或--clean-final时向unpaper传递任意参数。默认的、非常保守的unpaper设置被取消了。参数
--clean-final现在隐含了--clean。在此之前,可以单独使用--clean-final,但它不会有任何实际效果。修复了遍历损坏的目录条目时出现的异常 (特别是那些具有无效目标对象的条目)
修复了在使用
--tesseract-timeout和图像处理功能时,处理超过100页的文件时出现的问题。 #347OCRmyPDF 现在总是调用
os.nice(5)来向操作系统表明它是一个后台进程。
v8.0.1
修复了解析缺少必填字段的PDF时出现的异常。#325
现在需要 pikepdf 1.0.5,以解决一些其他 PDF 解析问题。
v8.0.0
没有主要功能。此版本的目的是切断对某些依赖项的旧版本的支持。
重大变更
放弃了对Tesseract 3.x的支持。现在需要Tesseract 4.0或更新版本。
放弃了对 Python 3.5 的支持。
一些在v7.x版本中已被弃用的
ocrmypdf.pdfaAPI已被移除。此功能已移至pikepdf。
其他更改
修复了在尝试屏蔽条形码时未处理的异常。 #322
现在可以在不使用pdfminer.six的情况下使用ocrmypdf,以支持那些没有它或目前无法使用它的发行版(例如Homebrew)。如果可能的话,下游维护者应该包含pdfminer.six。
当PDF/A转换从输入PDF中移除某些XMP元数据时,现在会发出警告。(PDF/A中只允许某些XMP元数据类型的“白名单”。)
修复了导致生成的PDF/A文件包含不符合规范的XMP元数据的几个问题(使用veraPDF验证时会失败)。
修复了一些由于PDF中的无效DocumentInfo导致XMP元数据创建失败的情况。
修复了一些文档问题。
现在需要 pikepdf 1.0.2。
v7.4.0
--force-ocr现在可以与新的--threshold和--mask-barcodes功能一起使用现在需要 pikepdf >= 0.9.1。
更改了元数据处理以支持pikepdf 0.9.1。因此,Ghostscript 9.25或更高版本中非ASCII字符的元数据处理已修复。
chardet >= 3.0.4 暂时被列为必需项。pdfminer.six 依赖于它,但最近的版本并未指定此要求。 (#326)
不再需要python-xmp-toolkit和libexempi。
现在为希望通过简单HTTP接口而不是命令行访问OCRmyPDF的用户提供了一个新的Docker镜像。
增加对PDF图形堆栈溢出或下溢的容忍度。 (#325)
v7.3.1
修复了从v7.3.0版本开始的性能回归问题;在应该选择快速页面分析时未选择。
修复了与新的
--mask-barcodes功能相关的一些异常,并改进了参数检查添加了对缺少Unicode映射的TrueType字体的缺失检测
v7.3.0
新增了一个功能
--redo-ocr,用于检测文件中现有的OCR,将其移除并重新进行OCR。这对于希望利用Tesseract 4.0中OCR质量改进的用户可能特别有帮助。请注意,3.0版本之前由OCRmyPDF添加的OCR无法被检测到,因为在早期版本中它没有被正确标记为不可见文本。OCR从可见文本构建字体的情况,例如Adobe Acrobat的ClearScan。OCRmyPDF的内容检测通常更为复杂。它 了解更多关于每个PDF的内容,并做出更好的 推荐:
OCRmyPDF 现在可以检测到 PDF 包含无法映射到 Unicode 的文本(这意味着人类可以阅读,但复制粘贴时会变成乱码)。在这些情况下,它建议使用
--force-ocr来使文本可搜索。包含矢量对象的PDF现在以更适合OCR的分辨率进行渲染。
我们现在对于包含Adobe LiveCycle Designer的动态XFA表单的PDF文件会以错误退出。目前开源社区没有工具可以处理这些文件。
OCRmyPDF 现在会在处理包含 Adobe AcroForms 的 PDF 文件时发出警告,因为这类文件可能不需要进行 OCR 处理。它仍然可以处理这些文件。
添加了三个新的实验性功能,以在某些条件下提高OCR质量。这些参数的名称、语法和行为可能会发生变化。它们也可能与某些其他功能不兼容。
--remove-vectors用于去除矢量图形。这可以提高OCR质量,因为OCR不会在艺术作品中搜索可读文本;然而,它目前也会移除“曲线文本”。--mask-barcodes用于检测并抑制文件中的条形码。我们观察到,条形码可能会干扰OCR,因为它们“类似文本”但实际上并非文本。--threshold使用了一种比当前Tesseract OCR中使用的更复杂的阈值算法。这解决了Tesseract 4.0中一个已知问题,即在亮背景上的暗色文本问题。
修复了当安装的Ghostscript版本非常旧时未报告错误消息的问题。
PDF优化器现在在优化级别为
--optimize 1或更高(默认)时,会启用对象流保存文件。这使得文件稍微小一些,但需要PDF 1.5。PDF 1.5于2003年首次发布,并得到了PDF查看器的广泛支持,但一些基本的PDF解析器(如PyPDF2)无法理解对象流。您可以使用命令行工具qpdf --object-streams=disable或pikepdf库来移除它们。新依赖项:pdfminer.six 20181108。请注意,这是仅适用于Python 2的pdfminer的一个分支。
弃用通知:2018年底,我们将停止对Python 3.5和Tesseract 3.x的支持。OCRmyPDF v7将继续与旧版本兼容。
v7.2.1
修复了与pikepdf 0.3.5中API更改的兼容性问题。
为了在测试套件中支持1.72版本之前的Leptonica版本而采用的临时解决方案已被移除。旧版本的Leptonica可能仍然兼容。唯一的影响是测试套件的一部分将被跳过。
v7.2.0
有损JBIG2行为变更
一位用户报告说,ocrmypdf实际上在有损压缩模式下使用了JBIG2。这不是预期的行为。用户应该查看有关JBIG2在有损模式下的技术问题,并决定这是否对他们的使用场景有影响。
JBIG2有损模式确实比其他任何单色压缩技术实现了更高的压缩比;对于大型文本文档,节省的空间相当可观。JBIG2无损模式仍然提供了很高的压缩比,并且是对旧版CCITT G4标准的重大改进。
只有已经审查过在损失模式下使用JBIG2的问题的用户才应该选择加入。因此,损失模式的JBIG2只有在发出新的参数--jbig2-lossy时才会开启。这与--optimize的设置是独立的。
未安装可选JBIG2编码器的用户不受影响。
(感谢用户‘bsdice’报告此问题。)
其他问题
当图像优化器将图像量化为每像素1位时,它将尝试进一步将该图像优化为CCITT或JBIG2,而不是将其保留在“flate”编码中,这种编码对于1 bpp图像来说效率不高。 (#297)
PDF中用作软掩码(即透明度掩码或阿尔法通道)的图像现在被排除在优化之外。
修复了Tesseract 4.0-rc1的处理,该版本现在接受无效的Tesseract配置文件,这破坏了测试套件。
v7.1.0
v7.0.6
将 Ghostscript 9.24 列入黑名单,因为 9.25 版本已经可用,并修复了 9.24 中的许多回归问题。
v7.0.5
提高与Ghostscript 9.24的兼容性,并在安装此版本时启用JPEG直通功能。
Ghostscript 9.24 失去了将PDF标题、作者、主题和关键字元数据设置为Unicode字符串的能力。OCRmyPDF 将设置ASCII字符串,并在Unicode被抑制时发出警告。可以使用其他软件来更新元数据。这是一个短期的解决方案。
由Kodak Capture Desktop生成的PDF文件,或者通常包含对目录中空对象的间接引用的PDF文件,在通过OCRmyPDF处理后可能会有一个无效的目录,这可能会干扰其他查看器。此问题已修复。
检测由Adobe LiveCycle生成的PDF文件,这些文件目前只能在Adobe Acrobat和Reader中显示。当遇到这些文件时,退出并报错,而不是在“请等待”错误信息页面上执行OCR。
v7.0.4
修复了在尝试优化嵌入在PDF中的某种类型PNG时抛出的异常,使用了
-O2更新到pikepdf 0.3.2,以获得对之前被排除在优化之外的某些额外图像类型(CMYK和灰度)的优化支持。修复了#285。
v7.0.3
修复了#284,一个在解析同时是图像掩码的内联图像时出现的错误,通过将pikepdf升级到0.3.1版本。
v7.0.2
v7.0.1
通过拒绝具有alpha通道的输入图像,修复了与img2pdf >= 0.3.0的兼容性问题
为pikepdf 0.3.0添加向前兼容性(与img2pdf无关)
v7.0.0 变更的各种文档更新
v7.0.0
将OCR层与现有PDF页面结合的核心算法已经重写并显著改进。PDF不再被分割成单页PDF进行处理;相反,图像被渲染,OCR结果被嫁接到输入的PDF上。新算法使用更少的临时磁盘空间,并且在处理大文件时性能更高。
新依赖项:pikepdf。 pikepdf 是一个强大的新 Python PDF 库,驱动最新的 OCRmyPDF 功能,基于 QPDF C++ 库(libqpdf)构建。
新功能:使用
-O或--optimize进行PDF优化。在OCR之后,OCRmyPDF将执行与OCR PDF相关的图像优化。如果有一个JBIG2编码器可用,那么单色图像将被转换,对于大型黑白图像来说,这可能会带来巨大的节省,因为JBIG2比任何其他单色(双级)压缩都要高效得多。(所有与JBIG2相关的美国专利可能已经过期,但用户仍需负责提供如jbig2enc这样的JBIG2编码器。OCRmyPDF不实现JBIG2编码。)
如果安装了
pngquant,OCRmyPDF 将可以选择使用它来执行 PNG 图像的有损量化和压缩。JPEG的质量也可以降低,假设较低质量的图像可能适合在OCR后存储。
这个图像优化组件最终将作为一个独立的命令行工具提供。
优化范围从
-O0到-O3,其中0禁用优化,3实现所有选项。1是默认值,仅执行安全且无损的优化。(这与GCC的优化参数类似。)执行的优化类型会随时间而变化。
页面边缘的少量文本,如水印、页码或数字印章,当发出
--skip-text时,将不再阻止页面的其余部分进行OCR。这种行为基于启发式方法。已移除的功能
已弃用的
--pdf-renderer tesseractPDF 渲染器已被移除。-g,生成调试文本页面的选项,已被移除,因为它增加了维护负担并且只在个别情况下有效。HOCR页面仍然可以通过使用适当设置运行hocrtransform.py来预览。
已移除的依赖项
PyPDF2defusedxmlPyMuPDF
sandwichPDF 渲染器可以与所有支持的 Tesseract 版本一起使用,包括那些不支持-c textonly的 v3.05 之前的版本。(推荐使用 Tesseract v4.0.0,它更高效。)--pdf-renderer auto选项以及用于选择 PDF 渲染器的诊断工具现在与旧版本的兼容性更好,但可能会做出与过去版本不同的决策。如果一切成功但PDF/A转换失败,现在会返回一个独特的返回代码(
ExitCode.pdfa_conversion_failed (10)),而这种情况以前会返回ExitCode.invalid_output_pdf (4)。后者现在仅在输出文件无效的某些迹象时返回。下游打包者的注意事项
还有一个新的依赖项是
python-xmp-toolkit,它又依赖于libexempi3。可能需要单独
pip install pycparser以避免另一个Python 3.7问题。
v6.2.5
由于Tesseract 4.0rc1行为变化,禁用一个失败的测试。 以前,如果Tesseract的配置无效,它会退出并显示错误消息,而OCRmyPDF会拦截此消息。 现在Tesseract会发出警告,OCRmyPDF v6.2.5可能会转发或忽略此警告。(在v7.x中,OCRmyPDF将响应此警告。)
此发布分支不再支持使用可选的PyMuPDF安装,因为它已在v7.x版本中被移除。
此发布分支不再支持macOS。macOS用户应升级到v7.x。
v6.2.4
回退Ghostscript 9.25的兼容性修复,该修复移除了对设置Unicode元数据的支持
回退黑名单 Ghostscript 9.24
旧版本的Ghostscript仍然被支持
v6.2.3
通过拒绝具有alpha通道的输入图像,修复了与img2pdf >= 0.3.0的兼容性问题
此版本将包含在Ubuntu 18.10中
v6.2.2
从v7.0.0版本向后移植兼容性修复,适用于Python 3.7和ruffus 2.7.0
回移植修复,以在决定页面上有哪些颜色时忽略遮罩
从v7.0.0版本中回迁一些小的改进:更好的参数验证和关于Tesseract 4.0.0
--user-words回归的警告
v6.2.1
修复了最近版本的Tesseract(4.0.0-beta1之后)未被检测为支持
sandwich渲染器的问题(#271)。
v6.2.0
Docker: Docker 镜像
ocrmypdf-tess4已被移除。主要的 Docker 镜像ocrmypdf和ocrmypdf-polyglot现在使用 Ubuntu 18.04 作为基础镜像,因此 Tesseract 4.0.0-beta1 现在是它们使用的 Tesseract 版本。不再有基于 Tesseract 3.05 的 Docker 镜像。现在支持创建PDF/A-3。然而,无法将文件附加到PDF/A-3。
列出文件大小可能增长的更多原因。
修复了#262,
--remove-background在包含颜色映射(调色板)图像的PDF上出现的错误。修复了另一个XMP元数据验证问题,这种情况发生在输入文件的创建日期没有时区且创建日期未被覆盖的情况下。
v6.1.5
修复了#253,在使用
hocr渲染器时可能出现的除以零错误。修复了PDF/A中XMP元数据内
字段格式不正确的问题。veraPDF将此标记为PDF/A验证失败。该错误是由于修改时间的时区和秒的最后一位被省略,因此最坏情况下修改时间戳会四舍五入到最近的10秒。
v6.1.4
修复了 #248
--clean参数可能会在某些文档中移除左侧文本列的OCR。我们现在设置--layout none来抑制这种情况。测试缓存已更新以反映上述更改。
更改测试套件以适应 Ghostscript 9.23 的新功能,即无需转码即可将 JPEG 插入 PDF。
PDF中的XMP元数据现在使用
defusedxml进行检查以确保安全。如果外部进程在被要求报告其版本时因信号退出,我们现在会打印系统错误消息,而不是抑制它。这种情况发生在找到所需的可执行文件但缺少共享库时。
现在需要 qpdf 7.0.0 或更高版本,因为测试套件在没有它的情况下无法通过。
注释
在Ghostscript 9.23中出现的明显回归问题可能会导致某些ocrmypdf输出文件在极少数情况下无效;目前的解决方法是设置
--force-ocr。
v6.1.3
修复了 #247,
/CreationDate元数据未从输入复制到输出。当在具有大量页面的文件上使用Python 3.5时,现在会发出警告,因为已知这种情况会退化为单核性能。此问题的原因尚不清楚。
v6.1.2
升级到 PyMuPDF v1.12.5,该版本包含对 #239 的更完整修复。
添加
defusedxml依赖项。
v6.1.1
修复了如果未安装 PyMuPDF 时,文本在所有页面上被报告为找到的问题。
v6.1.0
PyMuPDF 现在是一个可选但推荐的依赖项,以减轻在作者预期访问 PyMuPDF 较少的平台上的安装困难。(仅适用于 6.x 版本)使用
pip install ocrmypdf[fitz]安装 OCRmyPDF 以充分利用其功能。修复了在生成输出文件时如果OCR超时可能发生的
FileExistsError。 (#218)修复了在生成PDF/A(使用PyMuPDF)时,所有目录/书签都被重定向到第1页的问题。(在没有PyMuPDF的情况下,目录在PDF/A模式下会被移除。)
修复了当目录/书目标题包含字符
)时出现的“RuntimeError: invalid key in dict”错误。 (#239)添加了一个新的参数
--skip-repair以跳过初始的PDF修复步骤,如果PDF已经是格式良好的(因为其他程序已经修复了它)。
v6.0.0
软件许可证已更改为GPLv3 [此后又再次更改]。 测试资源文件和一些单独的源代码可能有其他许可证。
OCRmyPDF 现在依赖于 PyMuPDF。 包含 PyMuPDF 是更改为 GPLv3 的主要原因。
其他向后不兼容的更改
环境变量
OCRMYPDF_TESSERACT,OCRMYPDF_QPDF,OCRMYPDF_GS和OCRMYPDF_UNPAPER不再使用。 如果需要覆盖 OCRmyPDF 使用的外部程序,请更改PATH。ocrmypdf包已被移动到src/ocrmypdf以避免意外导入的问题。函数
ocrmypdf.exec.get_program已被移除。已弃用的模块
ocrmypdf.pageinfo已被移除。--pdf-renderer tess4作为sandwich的别名已被移除。
修复了在使用
--skip-text --output-type pdf时导致文件大小急剧膨胀的问题。OCRmyPDF现在会移除重复的资源,如字体、图像和其他它生成的对象。(#237)改进了初始页面分割步骤的性能。最初认为此步骤不会很耗时,并在一个进程中运行。大文件测试显示它成为了一个瓶颈,因此现在它被并行化了。在一个700页的文件上,使用四核机器,这一改变节省了大约2分钟。(#234)
测试套件现在包含一个缓存,可用于加速跨平台的测试运行。这也不需要计算校验和,因此速度更快。(#217)
v5.7.0
修复了在运行Tesseract 4时,导致拥有超过4核的机器CPU利用率低的问题。(与#217相关。)
‘hocr’ 渲染器已经得到了改进。对于大多数使用场景,‘sandwich’ 和 ‘tesseract’ 渲染器仍然更好,但对于使用 PDF.js 渲染器处理英文/ASCII 语言的人来说,‘hocr’ 可能更有用。(#225)
现在它以某种方式格式化文本,使得某些PDF查看器更容易选择和提取复制粘贴文本。这应该特别有助于macOS Preview和PDF.js。
所选文本的外观和选择文本的行为得到了改进。
PDF内容流现在使用相对移动,使其更加紧凑,便于查看者确定同一行上的两个单词。
它现在可以处理倾斜基线上的文本。
感谢@cforcey的拉取请求,@jbreiden的许多有用建议,@ctbarbour的另一轮改进,以及@acaloiaro的独立审查。
v5.6.3
抑制两条过于冗长的调试消息
v5.6.2
开发分支意外被标记为发布版本。请勿使用。
v5.6.1
修复了 #219:更改最终输出文件的创建方式,以避免在输出为特殊文件(如
/dev/null)时触发权限错误。修复了由于qpdf 8.0.0回归和Python 3.5处理符号链接导致的测试套件失败问题
“加密PDF”错误信息根据PDF加密类型的不同而有所不同。现在,对于所有类型的PDF加密,都会显示一条清晰的信息。
ocrmypdf 现在已在 Homebrew 中。建议 Homebrew 用户使用官方 homebrew-core 公式中的 ocrmypdf 版本,而不是私人 tap。
一些代码检查
v5.6.0
修复了 #216:保留“文本为曲线”的PDF文件而不进行光栅化处理
与上述相关,关于栅格化的消息更加一致
为了保持一致性,次要版本现在将获得它们本应始终具有的尾随 .0。
v5.5
添加新参数
--max-image-mpixels。Pillow 5.0 现在会在图像可能是解压缩炸弹时抛出异常。此参数可用于覆盖 Pillow 设置的限制。修复了在使用三明治渲染器时输出页面被裁剪的问题,并在旋转和图像处理的页面上跳过了OCR。
当使用旧版本的Ghostscript时,现在会在已知导致非拉丁字符问题的情况下发出警告
修复了
-output-type pdfa-1和pdfa-2的一些参数验证检查
v5.4.4
修复了 #181: 修复了当PDF页数超过系统文件句柄限制(
ulimit -n)时的最终合并失败问题。修复了#200:PDF中一种不常见的格式化十进制数字的语法会导致qpdf发出警告,而ocrmypdf将其视为错误。现在这个警告被传递了。
修复了一个问题,即中间PDF会以1.3版本创建,而不是原始文件的版本。这种情况有可能但不太可能产生副作用。
当使用旧版本的qpdf时,现在会发出警告,因为像 #200 这样的问题会导致 qpdf进入无限循环
解决问题 #140: 如果 Tesseract 输出无效的 UTF-8,转义它并打印其消息 而不是因 Unicode 错误而中止
添加之前未列出的设置要求,pytest-runner
更新文档:修复了使用Docker镜像的Synology示例脚本中的错误,改进了安全指南,建议使用
pip install --user
v5.4.3
如果子进程在被查询时未能报告其版本,则干净地退出并显示错误,而不是抛出异常
添加了测试以确认系统区域设置支持Unicode,如果不支持则提前失败
澄清了一些版权信息
更新了固定的requirements.txt,以便homebrew公式捕获更多最新版本
v5.4.2
修复了从v5.4.1版本引入的一个回归问题,该问题导致sidecar文件被创建为空文件
v5.4.1
添加针对Tesseract v4.00alpha在尝试获取方向时崩溃的临时解决方案,前提是已安装最新的语言包
v5.4
更改弃用警告的措辞以提高清晰度
添加了生成PDF/A-1b输出的选项(如果需要) (
--output-type pdfa-1); 默认仍为生成PDF/A-2b更新文档
v5.3.3
修复了在旧版本的Tesseract上尝试强制使用
--pdf-renderer sandwich时应出现的错误消息缺失问题更新测试文件中的版权信息
在Dockerfiles中将系统
LANG设置为UTF-8,以避免UTF-8编码错误
v5.3.2
修复了一个与语言包相关的损坏的测试用例
v5.3.1
修复了缺少Tesseract语言包时返回的错误代码
修复了在Travis上尝试自动brew时“brew audit”崩溃的问题
v5.3
v5.2
当使用 Tesseract 3.05.01 或更新版本时,除非使用
--pdf-renderer参数指定了其他 PDF 渲染器,否则 OCRmyPDF 将默认选择“sandwich” PDF 渲染器。之前的行为是选择--pdf-renderer=hocr。“tesseract” PDF 渲染器现已弃用,因为它可能会导致 Tesseract 3.05.00 上的 Ghostscript 出现问题。
“tess4” PDF 渲染器已更名为“sandwich”。“tess4”现在是“sandwich”的已弃用别名。
v5.1
现在支持页面尺寸大于200英寸(5080毫米)的文件,使用
--output-type=pdf时,页面尺寸将保持不变(在PDF规范中,此功能称为UserUnit缩放)。由于Ghostscript的限制,此功能不适用于PDF/A输出。
v5.0.1
修复了#169,在某些版本的Tesseract 3.04(包括jbarlow83/ocrmypdf Docker镜像)上由于无法创建辅助文本文件而导致的异常。
v5.0
向后不兼容的更改
不再支持 Python 3.4。现在需要 Python 3.5。
不再支持 Tesseract 3.02 和 3.03。需要 Tesseract 3.04 或更新版本。支持 Tesseract 4.00(alpha)。
OCRmyPDF.sh 脚本已被移除。
添加一个新功能,
--sidecar,它允许创建包含OCR结果的纯文本“sidecar”文本文件。这些OCR文本比从PDF中提取的文本更可靠。关闭#126。新功能:
--pdfa-image-compression,允许覆盖Ghostscript的有损或无损图像编码启发式方法,并根据需要将所有图像编码为JPEG或无损编码。修复了#163。修复了 #143,添加了
--quiet以抑制“INFO”消息修复了#164,一个拼写错误
移除了命令行参数
-n和--just-print,因为它们已经有一段时间没有工作了(报告为Ubuntu bug #1687308)
v4.5.6
v4.5.5
macOS homebrew tap 的自动更新
修复了#154,在搜索没有/Contents记录的空白页面上的文本时出现的KeyError '/Contents'。注意:此问题的修复不完整。
v4.5.4
v4.5.3
为Ghostscript 9.21及可能更早版本添加了一个解决方法,这些版本在处理XMP元数据时会出现“VMerror -25”错误信息,这是由于Ghostscript的一个bug。
高Unicode字符(U+10000及以上)不再被接受用于在命令行上设置元数据,因为Ghostscript可能无法正确处理它们。
修复了当tesseract失败或超时时,
tess4渲染器会在输出页面上重复内容的问题修复了当无损重建可能时,
tess4渲染器未被识别的问题
v4.5.2
修复了 #147,
--pdf-renderer tess4 --clean将会生成一个过大的页面, 由于丢失了 DPI 信息,页面左下角包含原始图像。使“使用 Tesseract 4.0”警告不那么吓人
为家酿OCRmyPDF设置机器
v4.5.1
修复了#137,使用
--force-ocr和其他一些标志组合时,非正方形像素宽高比的图像比例会在输出中失真。
v4.5
现在支持包含“Form XObjects”的PDF文件(问题 #134;PDF 参考手册8.10),并且在确定光栅化分辨率时会考虑它们包含的图像
Tesseract 4 Docker 镜像不再包含所有语言,因为构建时间过长,某些内容往往会失败
OCRmyPDF 现在警告使用
--pdf-renderer tesseract与 Tesseract 3.04 或更低版本时,由于 Ghostscript 在这些情况下会损坏 OCR 文本。
v4.4.2
Docker 镜像(ocrmypdf、ocrmypdf-polyglot、ocrmypdf-tess4)现在基于 Ubuntu 16.10 而不是 Debian stretch
这使得支持Tesseract 4图像变得更加容易
对于任何Docker用户来说,如果他们使用自己的更改自定义了这些镜像,并且这些更改依赖于Debian而不是Ubuntu,那么这可能是一个破坏性的变化。
OCRmyPDF 现在阻止了在 Tesseract 3.04 上运行 Tesseract 4 渲染器,这在 v4.4 和 v4.4.1 中是允许的,但不会工作
v4.4.1
为了防止由 img2pdf >= 0.2.1 和 Pillow <= 3.4.2 引起的 TIFF 输出错误,依赖关系已被加强
Tesseract 4.00 的并发进程限制从 1 增加到 2,因为观察到 1 会降低性能
文档改进以描述
--tesseract-config功能添加了测试用例并修复了
--tesseract-config的错误处理对setup.py进行调整以解决v4.4版本中的问题
v4.4
Tesseract 4.00 现在以实验性质得到支持。
一个新的渲染选项
--pdf-renderer tess4利用了 Tesseract 4 的新纯文本输出 PDF 模式。详情请参阅关于 PDF 渲染器的文档。--tesseract-oem参数允许控制 Tesseract 4 OCR 引擎模式(tesseract 的--oem)。使用--tesseract-oem 2来强制使用新的 LSTM 模式。修复了在Linux上使用Tesseract 4.00时的性能问题
修复了在某些情况下导致输出到stdout损坏的问题
移除了对Pillow JPEG和PNG支持的测试,因为现在支持的Pillow最低版本已经强制要求这一点
OCRmyPDF 现在会在继续之前测试目标文件是否可写
测试套件现在需要
pytest-helpers-namespace来运行(但不需要安装)对代码进行了重大重组,以使OCRmyPDF可重入并提高性能。所有更改应向后兼容v4.x系列。
然而,OCRmyPDF 的依赖项“ruffus”不是可重入的,因此没有可用的 Python API。脚本应继续使用命令行界面。
v4.3.5
更新文档以确认与Python 3.6.0的兼容性。无需更改代码,因此可能支持许多早期版本。
v4.3.4
修复了高DPI图像的“decimal.InvalidOperation: quantize result has too many digits”问题
v4.3.3
正确修复了使用Ghostscript 9.20创建PDF/A的问题
修复了内联模板掩码中缺少可选参数时的异常
v4.3.2
修复了Ghostscript 9.20创建PDF/A的问题(注意:此修复实际上并未生效)
v4.3.1
修复了一个问题,即在Tesseract超时后,如果输入页面使用了/Rotate标记进行旋转,由“hocr”渲染器生成的页面会错误地旋转。
修复了LeptonicaErrorTrap中的一个文件句柄泄漏问题,该问题在使用
--deskew或--remove-background或其他基于Leptonica的图像处理功能时,对于大约百页长的文件会导致“打开文件过多”的错误,具体取决于系统的ulimit -n值。现在在文档中宣传了为多语言文档指定多种语言的能力
减少了一些测试资源的文件大小
清理了调试输出
在测试用例中,Tesseract缓存现在对错误的缓存命中和重现精确输出更加谨慎,尽管没有观察到任何问题。
v4.3
新功能
--remove-background用于检测并擦除彩色和灰度图像的背景更好的文档
修复了在光栅堆栈深度为零时绘制图像的PDF问题
ocrmypdf 现在可以将其输出重定向到标准输出,以便在 shell 管道中使用
这不会提高性能,因为仍然使用临时文件进行缓冲
在此模式下,某些输出验证被禁用
v4.2.5
修复了一个问题 (#100) 关于 PDF文件在图像上省略了可选的/BitsPerComponent参数
移除了非免费文件 milk.pdf
v4.2.4
修复了一个错误 (#90) 由 正确使用模板遮罩的PDF引起
修复了处理PDF时尝试绘制图像或模板掩码而未正确设置图形状态的问题(此类图像现在在计算DPI时被忽略)
v4.2.3
修复了PDF中存储页面旋转(/Rotate)在间接对象中的问题
集成了一些修复以简化下游打包(Debian)
测试套件不再假设它已安装
如果运行的是Linux,跳过在命令行传递Unicode的测试
添加了一个测试用例来检查显式掩码和模板掩码
为间接对象和线性化PDF添加了一个测试用例
已弃用 OCRmyPDF.sh shell 脚本
v4.2.2
文档改进
v4.2.1
修复了包含模板掩码的PDF页面会报告错误的DPI并导致Ghostscript中止的问题
实现了标准输入流
v4.2
ocrmypdf 现在会尝试将单个图像文件转换为 PDF,如果它们作为输入提供 (#15)
这是一个基本的便利功能。它只支持单个图像,并且总是使图像填满整个页面。
为了更好地控制图像到PDF的转换,请使用
img2pdf(ocrmypdf的依赖之一)
新参数
--output-type {pdf|pdfa}允许禁用 Ghostscript PDF/A 生成pdfa是默认值,与过去的行为一致pdf为担心文件大小增加的用户提供了一个解决方案,这是由于 Ghostscript 强制将 JBIG2 图像转换为 CCITT 并重新编码 JPEG 文件。pdf尽可能保留原始文件的特性,包括PDF/A转换修复的问题
包含“非正方形”像素宽高比图像的PDF文件,例如200x100 DPI,现在可以正确处理和转换(修复了一个导致裁剪的bug)
--force-ocr即使页面不包含图像,也会将页面栅格化支持那些希望使用OCRmyPDF来重建带有损坏Unicode映射的PDF中的文本信息的用户(复制和粘贴的文本与显示的文本不匹配)
支持重新解释PDF,其中文本被渲染为曲线以便打印,并且需要恢复文本
修复问题 #82
修复了一个问题,即在某些设置下,PDF中的单色图像会被转换为8位灰度,从而增加文件大小 (#79)
对Ubuntu 12.04 LTS “precise”的支持已被放弃,转而支持(大致上)Ubuntu 14.04 LTS “trusty”
需要一些Ubuntu的“PPAs”(反向移植)才能使其工作
对一些旧依赖的支持已停止
现在需要 Ghostscript 9.15 或更高版本(在 Ubuntu trusty 中可通过 backports 获取)
现在需要 Tesseract 3.03 或更高版本(在 Ubuntu trusty 中可用)
Ghostscript 现在尽可能在“更安全”模式下运行
v4.1.4
错误修复:如果由于其他设置无法进行无损重建,则带有ICC配置文件的单色图像被错误地转换为全彩图像;结果是这些图像的文件大小增加。
v4.1.3
为使用版本4安全处理程序的PDF提供更有帮助的错误信息
更新Windows/Docker用户的使用说明
修正了矩阵乘法的操作顺序(对大多数用户没有影响)
添加一些leptonica包装函数(对大多数用户没有影响)
v4.1.2
将IEC sRGB ICC配置文件替换为Debian的sRGB(来自icc-profiles-free),后者与MIT许可证更兼容
对于与某些类型的格式错误的PDF相关的错误,提供更有帮助的错误信息
v4.1
--rotate-pages现在只在有合理信心确定方向时旋转页面。此行为可以通过新的参数--rotate-pages-threshold进行调整。修复了在运行时如果
unpaper未安装或缺失时的错误检查问题修复了在错误处理过程中“RethrownJobError”错误导致有用错误信息被抑制的问题
v4.0.7
对Ghostscript输出设置的小修正
v4.0.6
更新安装说明
提供一个sRGB配置文件,而不是使用Ghostscript的
v4.0.5
从v4.0.4中移除一些冗长的调试信息
修复了未删除的临时文件
DPI现在可以正确计算裁剪后的图像,以及其他图像变换
在DPI计算期间现在会检查内联图像,而不是直接拒绝图像
v4.0.4
发布时开启了详细的调试信息。请勿使用。请跳转到v4.0.5。
v4.0.3
新功能
检测到的页面方向现在在摘要评论中报告
修复
如果发生意外错误,显示堆栈跟踪
将Tesseract的“字符太少”错误信息视为跳过该页面的原因,而不是中止文件
Docker: 通过坚持使用已修复此问题的Ghostscript版本来解决空白JPEG2000问题
v4.0.2
修复
修复了与Tesseract 3.04.01版本的兼容性,特别是其输出方向信息的不同方式
改进了对Tesseract错误和崩溃的处理
修复了在Docker上使用chmod导致大多数测试用例失败的问题
v4.0.1
修复
修复了如果tesseract无法找到页面方向信息时出现的KeyError
v4.0
新功能
自动页面旋转(
-r)现在可用。它忽略PDF上的任何先前旋转信息,并根据可检测文本的主要方向设置旋转。此功能相当可靠,但有时会出现误判,尤其是在没有太多文本可供处理的情况下。 (#4)现在使用Leptonica而不是unpaper进行去斜操作。 Leptonica在图像去斜方面比unpaper更快且更可靠。
修复
修复了一个问题,即如果用户在Acrobat中扫描后旋转页面(特别是如果它是一个/Rotate标签),无损重建可能会导致某些页面显示不正确。
修复了一个问题,即如果页面被裁剪导致其原点不是 (0, 0),无损重建可能会导致图形层与文本层不对齐 (#49)
变更
日志输出现在更容易阅读
--deskew现在由 Leptonica 执行,而不是 unpaper (#25)现在需要libffi
对Docker和Travis构建环境进行了一些更改以支持libffi
--pdf-renderer=tesseract现在会在 Tesseract 版本低于 3.04.01 时显示警告,该版本计划修复 Tesseract 3.04.00 中的一个重要的 OCR 文本渲染错误。你也可以手动将 ./share/sharp2.ttf 安装到 Tesseract tessdata 文件夹中的 pdf.ttf 上以纠正此问题。
v3.2.1
变更
修复了#47 “convert() 得到了一个意外的关键字参数‘dpi’”通过升级到 img2pdf 0.2
调整了Dockerfiles
v3.2
新功能
无损重建:在可能的情况下,OCRmyPDF 将注入文本层,而不会对 PDF 页面的内容和布局进行其他操作。例如,包含矢量和栅格内容混合的 PDF 将保留矢量内容。在 PDF/A 转换期间,图像可能仍然会被转码。(
--deskew和--clean-final会禁用此模式,这是必要的。)新参数
--tesseract-pagesegmode允许您将页面分割参数传递给 Tesseract OCR。这对于两列文本和其他使 Tesseract 混淆的情况非常有帮助。新增了一个“多语言”版本的Docker镜像,该镜像生成了安装了所有语言包的Tesseract,适用于我们中的多语言使用者。它的体积要大得多。
变更
JPEG转码质量现在为95,而不是默认的75。更大的文件大小以减少质量下降。
v3.1.1
变更
修复了在具有混合页面大小的文档上导致页面大小和DPI计算错误的bug
v3.1
变更
默认输出格式现在是PDF/A-2b而不是PDF/A-1b
Python 3.5 和 macOS El Capitan 现在成为支持的平台 - 实现支持无需任何更改
改进了与缺失输入文件相关的一些错误信息
修复了 #20: 不接受大写的 .PDF 扩展名
修复了OCRmyPDF未能识别某些页面包含先前OCR处理过的文本的问题,例如由Tesseract 3.04生成的OCR文本。
将 /Creator 标签插入 PDF 中,以便错误可以追溯到此项目
新增了选项
--pdf-renderer=auto,让 OCRmyPDF 选择最佳的 PDF 渲染器。目前它总是选择 'hocrtransform' 渲染器,但该行为可能会改变。设置 Travis CI 自动集成测试
v3.0
新功能
使用Docker容器或Python的
pip包管理器进行更简单的安装消除了许多外部依赖,因此更容易设置
现在将
ocrmypdf安装到/usr/local/bin或等效路径,以便系统范围内访问并更容易输入改进了命令行语法和使用帮助 (
--help)可以使用 Tesseract 3.03+ 的 PDF 页面渲染来更好地定位识别的文本 (
--pdf-renderer tesseract)PDF元数据(标题、作者、关键词)现在会转移到输出的PDF中
PDF元数据也可以从命令行设置(
--title等)如果可能,自动修复格式错误的输入PDF
添加了测试用例以确认一切正常
添加了跳过需要太长时间进行OCR且通常无法OCR的极大页面的选项(例如大型扫描地图或图表);其他页面仍会被处理(
--skip-big)添加了选项,如果Tesseract OCR进程在某一页上耗时过长,可以终止该进程,同时继续处理其他页面 (
--tesseract-timeout)较少使用的颜色空间(CMYK,调色板)现在通过转换为RGB得到支持
现在支持在同一PDF页面上显示多张图片
变更
使用Python 3.4+和ruffus管道进行新的、健壮的重写
现在使用 Ghostscript 9.14 改进的颜色转换模型来保留 PDF 颜色
OCR文本现在在PDF中呈现为不可见文本。以前的OCRmyPDF版本错误地在图像顶部呈现了可见文本。
管道中的所有“任务”可以在任何可用的CPU上并行执行,从而提高性能
-o DPI参数已被逐步淘汰,取而代之的是--oversample DPI,以防将来我们需要-o OUTPUTFILE移除了几个依赖项,因此安装更加容易。我们不再使用:
与v2.x相比,需要或可选的一些新的外部依赖项:
发布候选版本^
rc9:
rc8:
修复 #111: 如果PDF缺少DocumentInfo字典,则抛出异常
rc7:
修复直接从pip安装时的错误,“没有这样的文件‘requirements.txt’”
rc6:
由于 Python 3 的内部 XML 解析器已经足够,因此放弃了 libxml2(Python lxml)
设置Docker容器
如果识别的文本包含Unicode字符且系统区域设置不是UTF-8,则修复Unicode错误
rc5:
放弃了Java和JHOVE,转而使用qpdf
改进了命令行错误输出
额外的测试和错误修复
在Ubuntu 14.04 LTS上测试
rc4:
放弃了MuPDF,转而使用qpdf
修复了一些安装程序问题和安装说明中的错误
提高性能:使用多线程渲染运行Ghostscript
提高性能:默认使用多核
错误修复:检查进程超时时的错误异常
rc3: 故意跳过版本号以避免与Tesseract混淆
rc2: 首次公开发布用于测试到test-PyPI, Github
rc1: 测试发布流程
兼容性说明
./OCRmyPDF.sh脚本目前仍然可用不再支持像
-vvv这样堆叠详细程度选项配置文件
config.sh已被移除。相反,你可以将文件传递给通用设置的参数:
ocrmypdf input.pdf output.pdf @settings.txt
其中 settings.txt 包含 每行一个参数,例如:
-l
deu
--author
A. Merkel
--pdf-renderer
tesseract
修复
处理包含空格的文件名:已修复
注释和已知问题
一些依赖项可能适用于比测试版本更低的版本,因此如果它们“妨碍”了,请尝试覆盖依赖项以查看它们是否有效。
--pdf-renderer tesseract在 Tesseract 3.03 中由于一个错误,会输出页面大小不正确的文件。不支持包含“内嵌图像”的PDF文件,并且在3.0版本中也不会支持。扫描的图像几乎从不包含内嵌图像。
v2.2-稳定版 (2014-09-29)
OCRmyPDF 版本 1 和 2 是作为 shell 脚本实现的。OCRmyPDF 3.0+ 是一个分支,逐渐用 Python 替换了所有的 shell 脚本,同时保留了现有的命令行参数。没有人维护旧版本。
有关旧版本的详细信息,请参阅其发布说明的最终版本。