Install ocrmypdf with Homebrew, apk, apt, dnf, MacPorts, Nix, zypper

Project links

• Homepage
• Repository
• Upstream docs
• Package manager page

Commands and aliases

• ocrmypdf

Project history

The project’s documentation frames OCRmyPDF around an awkward document-processing gap: PDF is the normal container for scanned documents, but existing scanned PDFs are difficult to modify. OCRmyPDF automates the pipeline of rasterizing pages, running OCR, inserting an invisible text layer, and writing a validated PDF or PDF/A output.

PyPI release history shows OCRmyPDF 3.0 published on 2015-09-05 and 4.2.2 on 2016-08-31, already advertising searchable PDF/PDF-A generation and preservation of embedded image resolution. Later documentation describes a public API, plugin support, image optimization, language packs, Docker usage, and feature-specific release notes, showing its expansion from a practical CLI into a packaged document-processing toolkit.

Adoption history

OCRmyPDF’s adoption follows the shape of the scanned-document problem: Linux, macOS, and distribution packagers ship it because it wraps several hard-to-coordinate pieces into one reproducible CLI. The project is available through PyPI and package managers including Homebrew, Debian/Ubuntu, Fedora, MacPorts, Nix, Alpine, and openSUSE-family packages.

The project’s packaging notes thank downstream packagers and point to broad porting status, while the README badges and package metadata show attention to PyPI, Homebrew, Read the Docs, and Python-version compatibility. That packaging breadth is part of its appeal: users can install a single command rather than hand-assemble Tesseract, Ghostscript or pypdfium2, image preprocessing, PDF/A conversion, metadata handling, and validation steps.

How it is used

The common workflow is `ocrmypdf input.pdf output.pdf`, with options for languages, page rotation, deskewing, cleaning, metadata, job parallelism, output type, PDF optimization, and redoing or skipping existing OCR. The README emphasizes searchable PDF/A output, accurate placement of OCR text below images, lossless insertion where possible, image optimization, input/output validation, Tesseract language support, and scaling to large PDFs.

The project is also used as a library or scripted tool in document-ingestion systems. Its public API and plugin documentation exist for callers that need OCRmyPDF behavior inside larger PDF processing flows rather than only from a shell.

Why package nerds care

OCRmyPDF is packaging glue with real teeth: it turns a fragile OCR/PDF toolchain into one command while still exposing dependency choices, language-data packaging, Docker images, plugin hooks, and PDF/A policy. It is a good package-nerd example of a Python CLI whose value is orchestrating native tools and file-format edge cases cleanly.

Timeline

• 2015-09-05: PyPI lists OCRmyPDF 3.0.
• 2016-08-31: PyPI lists OCRmyPDF 4.2.2 with the core searchable-PDF feature set.
• 2020s: release notes document continued work on PDF handling, API behavior, image optimization, plugins, rasterizer choices, and preservation of existing text layers.

Related projects

• OCRmyPDF depends conceptually and operationally on Tesseract OCR, PDF/A tooling, Ghostscript or pypdfium2 rasterization paths, image preprocessing tools, Python PDF libraries, and distribution language-pack packages.

Sources

• https://github.com/ocrmypdf/OCRmyPDF/blob/master/README.md
• https://ocrmypdf.readthedocs.io/
• https://ocrmypdf.readthedocs.io/en/stable/installation.html
• https://ocrmypdf.readthedocs.io/en/stable/maintainers.html
• https://ocrmypdf.readthedocs.io/en/stable/releasenotes/index.html
• https://pypi.org/project/ocrmypdf/
• https://pypi.org/project/ocrmypdf/3.0/
• https://pypi.org/project/ocrmypdf/4.2.2/
• source_facts.executables
• source_facts.package-manager