Skip to main content

OCRmyPDF AppleOCR

A plugin for OCRmyPDF that enables optical character recognition (OCR) using the text detection capabilities of Apple’s Vision Framework on macOS.

Apple’s proprietary OCR implementation provides excellent accuracy and speed compared to other on-device OCR engines such as Tesseract.

Installation

Requires macOS, Python 3.11 or later, and OCRmyPDF 14.2.1 or later (17 or later for the --ocr-engine and fpdf2 renderer features described below).

The package is available on PyPI.

pip install ocrmypdf-appleocr

Usage

The plugin registers itself as an OCRmyPDF entry point, so it is loaded automatically once installed — no --plugin option is required. Specify the language(s) for OCR using the -l or --language option. If you want to enable automatic language detection in accurate or fast mode, use und (undetermined) as the language code.

ocrmypdf -l jpn input.pdf output.pdf

Because the plugin is loaded automatically, it takes over as the OCR engine whenever --ocr-engine is left at its default (auto). To select it explicitly, or to go back to Tesseract without uninstalling the plugin:

ocrmypdf --ocr-engine appleocr -l jpn input.pdf output.pdf
ocrmypdf --ocr-engine tesseract -l jpn input.pdf output.pdf

If you have other third-party OCR engine plugins installed, always pass --ocr-engine explicitly. With built-in Tesseract alone, auto reliably resolves to this plugin, because an entry-point plugin is registered after the built-ins and OCRmyPDF's get_ocr_engine hook takes the first result in reverse registration order. Once a second third-party engine plugin is installed, however, both claim auto, and which one wins comes down to the order Python happens to discover their entry points — not something you can control or should rely on. Naming the engine removes the ambiguity: every well-behaved engine plugin declines when --ocr-engine names a different engine.

Loading the plugin explicitly with --plugin ocrmypdf_appleocr still works, and is what you need on OCRmyPDF versions older than 17, which have no --ocr-engine option.

Options

  • --appleocr-recognition-mode: Recognition mode for Apple Vision OCR. Choices: fast, accurate, or livetext. Default: livetext on macOS 13 and later, accurate on macOS 12 and earlier.
  • --appleocr-disable-correction: Disable language correction in Apple Vision OCR (default: False)
  • --ocr-engine: OCR engine to use. The plugin appends appleocr to OCRmyPDF's built-in choices (auto, tesseract, none). Default: auto, which resolves to this plugin when it is the only engine plugin installed; specify appleocr explicitly if other third-party engine plugins are also present. Requires OCRmyPDF 17 or later.
  • --pdf-renderer: Renderer used to embed OCR results as invisible (“phantom”) text. Choices: sandwich, fpdf2 (also auto, hocr, hocrdebug, which OCRmyPDF now treats as aliases for fpdf2). Default: sandwich.
  • -l or --language: Specify OCR language(s) in ISO 639-2 three-letter codes. Use und for undetermined language. Specifying multiple languages joined with + (e.g. eng+fra) for multilingual documents is not supported.

Automatic language detection (und) is not supported in livetext mode. und is also only accepted as the sole language: combining it with other language codes (e.g. -l und -l eng) is an error — use specific language codes instead.

Recognition Modes

The fast and accurate modes use VNRecognizeTextRequest from Apple's Vision framework.

The livetext mode uses the newer ImageAnalyzer API from the VisionKit framework. Although officially Swift-only, it can be accessed via private API (VKCImageAnalyzer) through pyobjc.

The key difference is that LiveText supports vertical text layout in East Asian languages, which is not handled properly by the older API.

PDF Renderers

This plugin supports two OCRmyPDF renderers: sandwich and fpdf2. sandwich is the recommended renderer and the plugin's default, because OCRmyPDF's built-in fpdf2 renderer currently places the invisible text layer incorrectly for both rotated and vertical text (see the known limitations below).

  • sandwich: The plugin renders OCR output as a PDF layer with invisible text (via its own generate_pdf()), which OCRmyPDF then merges with the original page image. The plugin builds the PDF text matrix itself from the full quadrilateral Apple Vision reports, so rotation, text extent and font size stay correct on skewed and rotated pages, and vertical (top-to-bottom) text layout in CJK scripts is handled explicitly.

  • fpdf2: The plugin returns OCR output as an OcrElement tree via the newer generate_ocr() plugin API (OCRmyPDF 17+), and OCRmyPDF's built-in fpdf2-based renderer converts it to PDF. This replaces the legacy hocr renderer, which OCRmyPDF now treats as an alias for fpdf2.

    Known limitations of the fpdf2 renderer (as of OCRmyPDF 17.8.1). Both are upstream OCRmyPDF bugs, not specific to this plugin, and both affect only the invisible text layer — the extracted text itself is still correct, but on-screen text selection and highlighting are not:

    • Rotated text gets an oversized bounding box and font size. An OcrElement bbox is axis-aligned by the hOCR convention, so a rotated line can only be described by the axis-aligned bounding box of its quadrilateral (_aabb()) plus a separate textangle. The renderer tries to recover the true line box by un-rotating that bbox, but un-rotating an axis-aligned box and taking its bounding box again inflates it instead of recovering the original quad, and the font size is derived from that inflated height. The error grows with the rotation angle: on the ~8°-rotated script/examples/eng_rot1.pdf, fpdf2 emits a ~147 pt font where sandwich uses ~15 pt, while on the unrotated script/examples/eng.pdf the two agree (~14.5 pt).
    • Vertical (tategaki) CJK text is mis-positioned. The text box for each vertical line collapses into a narrow horizontal band instead of spanning the column.

If --pdf-renderer is left at its default (auto), the plugin defaults to sandwich. Pass --pdf-renderer sandwich or --pdf-renderer fpdf2 explicitly to override this.

Supported Languages

As of macOS 27 Golden Gate, the following languages are supported by Apple Vision OCR. Finnish, Hindi and Marathi were added in macOS 27 and are not available on earlier versions:

Language code Language name Fast mode Accurate mode LiveText
eng English ✓ ✓ ✓
fra French ✓ ✓ ✓
ita Italian ✓ ✓ ✓
deu German ✓ ✓ ✓
spa Spanish ✓ ✓ ✓
por Portuguese ✓ ✓ ✓
chi_sim Chinese (Simplified) ✓ ✓
chi_tra Chinese (Traditional) ✓ ✓
yue_sim Cantonese (Simplified) ✓ ✓
yue_tra Cantonese (Traditional) ✓ ✓
kor Korean ✓ ✓
jpn Japanese ✓ ✓
rus Russian ✓ ✓
ukr Ukrainian ✓ ✓
tha Thai ✓ ✓
vie Vietnamese ✓ ✓
ara Arabic ✓ ✓
ars Arabic (Najdi) ✓ ✓
tur Turkish ✓ ✓
ind Indonesian ✓ ✓
ces Czech ✓ ✓
dan Danish ✓ ✓
nld Dutch ✓ ✓
nor Norwegian ✓ ✓
nno Norwegian (Nynorsk) ✓ ✓
nob Norwegian (Bokmål) ✓ ✓
msa Malay ✓ ✓
pol Polish ✓ ✓
ron Romanian ✓ ✓
swe Swedish ✓ ✓
fin Finnish ✓ ✓
hin Hindi ✓ ✓
mar Marathi ✓ ✓

Acknowledgements

This project incorporates and references code from the following projects:

Metadata

Release files for ocrmypdf-appleocr 0.4.2

For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.

Source distribution (sdist)

Source distribution for ocrmypdf-appleocr 0.4.2
File Size Uploaded
ocrmypdf_appleocr-0.4.2.tar.gz 24.1 kB Details

Built distribution (wheel)

Table of built distributions (wheels) for ocrmypdf-appleocr 0.4.2
File Interpreter ABI Platform
ocrmypdf_appleocr-0.4.2-py3-none-any.whl Python 3 none any Details

Total release size: 47.0 kB

Release files / ocrmypdf_appleocr-0.4.2.tar.gz

Download URL ocrmypdf_appleocr-0.4.2.tar.gz
Size 24.1 kB
Tags Source
SHA-256 checksum
How to use checksums
b37ad9ecf95d33ddf7835c1ba3296cef5980a89b73a08fbd6d0931cca13c5e77
BLAKE2b-256 checksum
How to use checksums
db09205e95378f9b01c7e4c6d722ad1ace69bd042cc8a52d5379629b618aac52
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/7.0.0 CPython/3.13.14

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Oct 15, 2026.

Transparency log

Release files / ocrmypdf_appleocr-0.4.2-py3-none-any.whl

Download URL ocrmypdf_appleocr-0.4.2-py3-none-any.whl
Size 22.9 kB
Tags Python 3
SHA-256 checksum
How to use checksums
7328f8977538df35a85f09d06a18a819494d9dd20ac8cb0a908529d3cd2ab129
BLAKE2b-256 checksum
How to use checksums
bf734f764eda2dd66f094cbed967e66b79c9651bb9fb426752b84c021b5d1b96
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/7.0.0 CPython/3.13.14

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Oct 15, 2026.

Transparency log

Release history Release notifications | RSS feed

This release

0.4.2 This release

2 release files

0.4.1

2 release files

0.4.0

2 release files

0.3.4

2 release files

0.3.3

2 release files

0.3.2

2 release files

0.3.1

2 release files

0.3.0

2 release files

0.2.4

2 release files

0.2.3

2 release files

0.2.2

2 release files

0.2.1

2 release files

Anthropic, PBC Visionary sponsor Bloomberg Visionary sponsor Hudson River Trading Visionary sponsor Meta Visionary sponsor NVIDIA Visionary sponsor Microsoft Sustainability sponsor Depot Continuous Integration AWS Cloud computing and Security Sponsor Datadog Monitoring Fastly CDN Google Download Analytics Sentry Error logging StatusPage Status page