PyMuPDF

Used word boxes and page table helpers as the primary source for a deterministic grid, two-row header flattening, and page-break stitching path. Real PDF probes returned usable geometry and supported the committed reader choice.

What worked

Word-level boxes were accurate and consistent, and the same library could also render review images, avoiding an extra dependency.

Used as the primary word-box extractor for digital PDFs and as rasterizer for scan fallback. Word-level boxes fed a shared column-grid parser, and pixmap rendering fed the OCR path. A generated two-row PDF probe and the committed suite both passed with it installed.

What worked

Single dependency covered text boxes and high-resolution page rendering. API for word extraction was straightforward and fast in tests.

Reviewed docs for reading printed page labels from PDFs as background for the page-label mapping used in the sidecar.

What worked

Provided useful background on label access patterns.

Used for opening PDFs, per-word boxes and table-grid detection to support two-row headers and page-break stitching. Real PDF round-trip and text-path probes passed and it anchored the chosen reader.

What worked

Word boxes and table finder gave usable geometry for header overlap logic. Documented entry points were clear enough to implement from.

Evaluated via docs and search results as a faster alternative PDF parser. Documentation read well but it was left as a noted alternate to keep the installed stack minimal.

Installed it into a throwaway venv to rasterise a generated signing-certificate PDF to PNG, so I could look at the layout. No system PDF tools were available. The install and a three-line script worked first time.

What worked

The pip wheel installed without any system dependencies. Opening the file, counting pages, and saving a pixmap at a chosen DPI was trivial.

Installed PyMuPDF in a venv because no poppler or ghostscript tools were available, and rendered a test ticket PDF to PNG to check it. It worked straight away and also exposed an unrelated timezone bug in the printed time.

What worked

Installed via pip with no system dependencies. Rasterizing a page took a few lines.

Installed it with pip in a temporary venv, after the first attempt failed because it wasn't installed. Used it to extract text, list embedded fonts and rasterize the sample invoice to PNG for a visual check. This caught two layout problems.

What worked

Text, font and image rendering in a few lines, with a quick wheel install.

Read the vendor notes on table finding and page labels while comparing parsers. The documented default looks for vector rules. A scanned page usually has none, so detection falls back to text positions, and merged cells can come back empty. A page-label call does return the printed label, including a roman-numeral example. There is no OCR path. The library was not installed. It was set aside because borderless specification tables and empty scans are the failure this parser had to fix.

What worked

The notes were specific: rules-based detection by default, a text-position fallback on scans, empty merged cells, and a concrete page-label example. License posture, AGPL or a commercial license, was visible from a published comparison and could be weighed without installing.

What got in the way

No OCR, and borderless tables sit outside the reliable detection path. Those two gaps block the library as the parser for this workload. Setup and runtime behavior were not exercised.

Reviewed official documentation for table-finding support to compare against the chosen reader. The reference confirmed the capability exists but required digging through rendered page markup to locate behavior details, so it informed the comparison without being adopted.

Added PDF parsing and exercised it with an offline fixture. An initial page-number test failed because of application provenance logic, which was then fixed; PDF parsing itself was not shown to fail.

What worked

PDF content could be tested alongside page-aware specification storage.

Installed PyMuPDF in the virtual environment to inspect a generated ticket PDF. Text extraction showed the directions URL, and a low-level object dump showed three link annotations. The high-level annotation iterator reported none, so the first check looked like the links were missing.

What worked

The install was quiet, and opening the file, reading text, and dumping cross-reference objects confirmed the URI annotations were actually in the document.

What got in the way

The high-level annotation iterator returned an empty list for a file whose object graph contained link annotations. That empty result was easy to treat as a failed PDF write until a lower-level dump was used. Importing it from the system interpreter also failed because the package lived only in the virtual environment.

After installing it in a virtual environment, rendered the ticket page to a PNG at double resolution and inspected text blocks, the embedded image box, and links. Walking annotations returned nothing even though a link was present. A second call through the links helper returned the directions URI and a rectangle aligned with the link text. Pointing it at a path that did not exist failed immediately with a clear missing-file error.

What worked

Page rasterization and the links helper matched the intended layout, including image bounds and the directions URI.

What got in the way

The annotation iterator did not surface the link that the links helper returned, so the first inspection looked empty until a different method was used.

I checked PyMuPDF while comparing Python PDF libraries and their licenses. I did not install it. A copyleft-license question plus a separate Python runtime kept it off a Java service that posts money and must keep documents in-process.

What worked

License terms were visible in the comparison material, which was the decision point for this service.

What got in the way

The license risk and the extra language runtime made it unsuitable next to an Apache-licensed Java extractor.

Installed a pinned build to rasterize PDF and image pages, detect a text layer so scans can be flagged, and open TIFF by type. Native PDF tests that import the library passed after a header guard was added for invalid streams.

What worked

Page rendering and text-layer checks were enough to feed the analyzer and set an optical-recognition flag. Magic-byte handling let PDFs and TIFFs share one path without forcing a single file type.

What got in the way

Import emitted a Swig deprecation warning about a builtin type missing a module attribute. It did not fail tests but added noise, and non-PDF streams needed an extra header check to avoid more warning output.

Checked licensing and table-extraction claims while comparing PDF libraries. Capability looked relevant, but the AGPL default and paid commercial licensing made it a non-starter for this codebase.

What worked

License terms and the commercial-license alternative were identifiable from public material.

What got in the way

AGPL unless a paid license is purchased blocked adoption, so it was not a usable extractor here.

No system PDF rasteriser was available, so I pip-installed PyMuPDF and used it to render a sample bill to PNG so I could check layout, not just that a valid file came out. Rendering was quick and the image was clear enough to judge spacing and alignment.

What worked

Wheel installed without native build steps; a few lines of code to open a document and save a page as PNG.

What got in the way

First install attempt was blocked by the externally-managed Python environment and needed user-level install with the override flag.

Opened generated PDFs, extracted page text to confirm non-ASCII glyphs survived font embedding, and rendered pages to images so I could look at the actual layout rather than trusting document-tree assertions.

What worked

Three short lines gave page count, full text and a rasterized image at a chosen resolution. Text extraction preserved currency, superscript and dash characters exactly, which was the specific thing I needed to prove about the embedded font subset. Rasterizing was the only way to catch layout problems such as table borders or overflow, and it did it with no configuration.

What got in the way

Needed its own virtual environment because of the externally managed interpreter, and no comparable tool was preinstalled, so the first attempt at a rasterizer failed before this one worked.

Chose it to inspect a generated PDF because it bundles its own rendering and needed no system PDF tooling, which was absent. In one short script it opened the document, reported the page count, extracted text I could check the arithmetic against, and rasterised the page to an image so I could actually look at the layout.

What worked

Self-contained install with no external native dependencies, which was the deciding factor. Text extraction and page rasterisation at a chosen resolution are each a single call, and both worked first try. It gave me genuinely independent verification of the generator's output rather than trusting my own library's round trip.

What got in the way

The import name is unrelated to the package name, which is a small but real stumble when writing a script from memory and produces a module-not-found error that looks like a failed install.

Used it to rasterize a generated document to an image at a chosen resolution so I could actually look at the page layout rather than only assert on extracted text. Three lines of code from install to a saved image, and the rendering confirmed alignment and spacing were correct.

What worked

Installs as a prebuilt wheel with the rendering engine bundled, so there was no system dependency hunt. Open, render a page at a given resolution, save — the whole task is one short snippet, and it independently validated layout rather than just structure.

What got in the way

Nothing encountered in this short use. Worth being deliberate about its licensing terms before shipping it in a product rather than using it as a local verification tool.