pkg.sopackage field notes

brew / Rang 621

ocrmypdf mit Homebrew installieren

Prüfe Installationswege, Executables, Metadaten und Sicherheitshinweise für ocrmypdf in AI-Agent-Workflows.

Installation

Weitere Installationsbefehle

macOS

Homebrewverifiziert · 100%
brew install ocrmypdf

provider-native install command

Überblick

Paketzusammenfassung

Adds an OCR text layer to scanned PDF files

Befehle und Aliase

  • ocrmypdf

Verlauf

Projektgeschichte und Nutzung

OCRmyPDF is a Python command-line application and library that adds an OCR text layer to scanned PDF files, making image-based documents searchable and copyable while preserving the original page images where possible.

Projektgeschichte

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.

Adoptionsgeschichte

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.

Wie es verwendet wird

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.

Warum Paket-Nerds sich dafür interessieren

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.

Zeitleiste

  • 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.

Sicherheitslage

Risikostufe: grün

narrow executable package without higher-risk signals.

Risikoklassifikator

grün Risiko · niedrig Konfidenz · appliance

Warum

  • narrow executable package without higher-risk signals

Signale

  • metadata:no-higher-risk-signals

Installationsverhalten

  • Es wurden keine Homebrew-Bottle-Metadaten erfasst.

Empfohlene Prüfung

Prüfe vor unbeaufsichtigter Agent-Nutzung, ob das Tool Klartext-Credentials liest, Remote-Zustand schreibt, Artefakte veröffentlicht oder Plugins ausführt.

Executables

Installierte Executables

BefehlArtSichtbarkeitHinweis
ocrmypdfExecutableindexiertes ExecutableAus dem lokalen Executable-Index erkannt.

Aktualität

Version und Aktualität

Diese Signale trennen das Alter der Seitengenerierung, Aktivität des Paketmanagers und Upstream-Release-Vergleich. Versionsrückstand wird nur gemeldet, wenn eine Evidenz-URL und vergleichbare Versionen vorhanden sind.

Seite generiert2026-08-03
Manager-Version17.8.1
Manager aktualisiert2026-07-17
lokale Datenunbekannt
Upstreamnicht verfügbar
neueste erkannte Versionnicht erkannt
  • OKEs wurden keine Aktualitätswarnungen generiert.

Installationsmetadaten

Paketmetadaten

Paketschlüsselbrew:ocrmypdf
Version17.8.1
PaketmanagerHomebrew
Homepagehttps://ocrmypdf.readthedocs.io/en/latest/
Zuletzt aktualisiert2026-07-17T21:55:45Z
Pulseupdated
Bottlenicht erfasst
Dienstkeiner deklariert

Quellspur

Aus Repository-Daten generiert

Diese Seite wird von av-web aus dem privaten Paket-SQLite-Artefakt bereitgestellt, das scripts/generate-pkg-sqlite.py erstellt.

Verwendete Quellen

  • Geiger risk classifier
  • Nucleus package database
  • curated package history
  • pkgdb category and tag curation