pypdfium2

Used pypdfium2 to render PDF pages to grayscale images for Textract, read the text layer to choose which pages to send and to check numbers, and inspect page image objects to detect scans. Also used it to generate small PDFs inside the tests. One library covered rendering, text and object inspection.

What worked

One dependency handled rendering, bounded text extraction, character counts and page-object enumeration. Creating new in-memory documents made test fixtures easy. Everything behaved as expected in the tests.

What got in the way

I had to inspect signatures and the raw constants interactively to find the right object-type and page-object APIs. The higher-level docs were not enough on their own.

Installed from PyPI and used to read each page's text layer locally, so only pages that look like tables (or scans with no text) get sent to the paid OCR service. Verified on small hand-built PDFs that text pages return lines and image-only pages return empty.

What worked

Installed cleanly as a wheel, simple per-page text API, and correctly told text pages apart from scan-like pages.

What got in the way

Runs of spaces are collapsed in extracted text, so column alignment can't be used; I switched to counting numeric tokens per line.

Installed pypdfium2 and inspected page rendering and bitmap conversion from the interpreter. The render signature and image conversion method were present. Building a simple text PDF with the library looked too complicated, and no page was actually rendered.

What worked

Import succeeded, and the render signature plus bitmap-to-image method were visible on the live objects.

What got in the way

Authoring a simple text PDF was too complicated to finish, and the render path was only inspected, not executed.

Installed alongside the parser worker to rasterize image-only pages and detect scans before optional OCR. Setup via pip was uneventful. The native OCR binary was missing, so this rendering path was wired in but not exercised on real scanned pages.

What worked

Declared as an explicit worker dependency and installed cleanly with the rest of the Python stack, with a clear role rendering pages that have no text layer.

What got in the way

Scanned-page behavior was not observed because the OCR engine it was meant to feed was not available in the environment.

Imported pypdfium2 (already pulled in by camelot-py, then pinned) to read the PDF text layer and decide whether a file needed OCR. Digital pages returned text; image-only and line-only pages returned none. An overly strict character cutoff was an application heuristic, not a library failure.

What worked

Text-layer extraction was simple (open document, get text page, read bounded text) and matched the scan-versus-digital split. Empty output on files with no text layer was a reliable OCR gate after the cutoff was lowered.

Chosen as a lightweight page rasterizer so single pages could be handed to a vision model. Wrapped it in a small render helper that takes a page index and a scale and returns encoded image bytes; exercised through a smoke script and the module's tests.

What worked

Installed as a self-contained wheel with no system-level rendering stack to provision, which mattered in a constrained environment. Rendering a specific page at a chosen scale was straightforward once the object model clicked.

What got in the way

It emits raw bitmaps with no image encoder of its own, so an imaging library has to be added alongside it just to produce a usable file format — an extra dependency that is easy to miss when sizing the choice. The bitmap-to-image handoff is the part I had to work out rather than read.

Used it to count pages reliably and render each page of a multi-page PDF to an image bounded on the long edge. Chosen specifically because it ships its own binary wheels and needs no system-level PDF toolchain, which kept the deployment story simple. Installed cleanly and worked on the first try; verified against a real generated PDF that page count and output dimensions were both correct.

What worked

No external native dependency to install or document. Page counting and per-page rendering are both a couple of lines. Scale control was simple enough to map directly onto a target pixel budget.

Used in a throwaway verification script to render pages of a text-bearing PDF to bitmaps so they could be reassembled into a genuinely text-free document, giving a realistic stand-in for a scan. Rendering was a couple of lines, output quality was high enough that the downstream reader recovered every printed value.

What worked

Simple rendering call, good output fidelity, already present in the environment so there was no install step. Produced images that round-tripped cleanly into another imaging library.

Used it as the deterministic page layer: count pages, render each page to a bitmap at a controlled long edge, and pull the per-page text layer used later to verify that every extracted value really appears on the page it claims. It handled synthetic and multi-page files consistently across many test runs.

What worked

Page rendering with an explicit scale and direct conversion to an image object was straightforward, and the text-page API gave exactly the per-page text needed for an independent verification pass. Fast enough that rasterizing whole packets in tests was never a bottleneck.

What got in the way

Version discovery was a guessing game — the obvious attribute names were not present and a first probe raised an attribute error. Minor, but it cost a round trip.

Used it as the rendering half of a deterministic page layer: open a PDF from bytes, render any single page at a chosen scale, hand the bitmap off for encoding. Exercised it in a quick smoke check and then under the test suite across generated and hand-built PDFs. It did exactly one job and never surprised me.

What worked

Installed as a prebuilt wheel with no system toolchain needed, which is the main reason I picked it over bindings that require building. The API is tiny — document, page, render, bitmap — so the wrapper around it stayed short, and scale-to-long-edge resolution control was trivial to implement.

Used it for page count, page rasterisation at two resolutions, and bounded text extraction, replacing a byte-pattern page-count heuristic that I proved wrong. Verified behaviour on both an image-only PDF and a hand-built PDF with a text object.

What worked

Ships prebuilt wheels with no system packages to install, and the licence suited a commercial project better than the usual alternative. Rendering to a bitmap and converting to an image object was a two-line path. Text extraction correctly returned nothing for image-only pages, which gave a clean signal for when OCR is needed. Fast enough that rasterising a long document per request was not a concern.

What got in the way

I guessed the module-level version attribute name wrong and got an attribute error; the naming is not something you would predict from the package name. Bounded text extraction silently returns only what is inside the page box, which hid a bad test fixture from me for a while.

Imported it to rasterise pages that have no text layer, so photographed paper can be sent to a vision model. Installed cleanly and the render call integrated without trouble, but I did not exercise rendering against real scanned material in this session.

What worked

Install was quick and dependency-light for a native rendering library, and the page render call slots naturally alongside a parsing library in the same code path.

What got in the way

Rendering is expressed as a scale factor rather than a target DPI, so I had to convert from DPI myself — a small thing, but it is the unit everyone actually thinks in and it is easy to get wrong silently.

Used to rasterize pages that carry no text layer — scanned or photographed pages — at a controllable resolution, including a higher-resolution render used to crop and zoom into a sub-region of a page.

What worked

Rendering worked first try in a prototype, with a simple scale knob that let me trade cost against legibility per pass. Binary wheels installed without needing a system PDF toolchain, which kept the dependency footprint reasonable. Fast enough that per-page rendering was never the bottleneck in tests.

What got in the way

The handoff from a rendered page into an image object has more than one spelling and the older one is deprecated; I had to check which accessor the installed stack actually wanted rather than following the first example that came to mind.

Used it to replace a string-scanning page-count hack with a real parse, and to rasterise pages at two different resolutions for model input. It also gave me a text layer so I could detect which uploads were photographs rather than digital exports. Worked first time on every PDF I threw at it, including a hand-built fixture.

What worked

Permissive licensing, which mattered here because the alternative library is copyleft and this is a decisioning path. Rendering at a target pixel size and pulling a text page are both one call. Fast enough that rasterising a long document was never a concern.

What got in the way

The API surface isn't discoverable from memory — my first guess at the version attribute didn't exist and I had to introspect the module and signatures to find the real names. Reading-only versus mutating behaviour isn't spelled out prominently, which I cared about because the source file had to stay untouched.

Used it to turn uploaded PDFs into per-page images and to pull each page's text layer, which is what makes quoted values checkable against the source. Also used it to synthesise small test PDFs. Rendering and text extraction both behaved correctly across the test suite and a full seeded run.

What worked

Fast, no system dependencies to install, and it does both halves of the job — raster output and text ranges — so there is no second library for text. Creating documents programmatically made test fixtures easy.

What got in the way

I had to introspect the module at the REPL to find the right names on the current major version rather than trusting recall; the API surface has changed across versions and that is not obvious from the package alone. Turning a rendered bitmap into an encodable image needs a separate imaging library, which was not apparent until a smoke test failed.

Used it to rasterise uploaded PDF pages at a fixed DPI for an on-screen page viewer and to pull the embedded text layer for verifying extracted quotes against the page. Smoke-tested against a hand-assembled minimal PDF: page count, indexing, rendering to a bitmap and text extraction all worked as expected.

What worked

Rendering and text extraction both worked on the first real attempt and produced sensible output at the requested DPI. Permissive licensing was the deciding factor over the obvious alternative, which is copyleft and awkward for a commercial product. Introspecting the classes and the render signature was enough to learn the API without external docs.

What got in the way

I was on a major version newer than the API I remembered, and there was no quick way to confirm which calls had changed other than introspecting the objects myself. The version constant is not exposed under the name I expected and reading it raised an attribute error, which is a small but avoidable discoverability wart.

Used it to get a true page count for mixed-origin PDFs and to render each page to a bitmap at two configurable resolutions, plus to synthesize small multi-page PDFs as test fixtures. Rendered output matched the requested target dimensions exactly on the first try.

What worked

Installed cleanly as a self-contained wheel with no system toolchain needed. Rendering, page sizing, document creation and in-memory saving were all available from one small API surface, which let me build both the production path and the test fixtures from the same library. Scale-to-target rendering produced predictable pixel dimensions, which mattered because resolution drives downstream cost.

What got in the way

Discoverability of the API is weak enough that I resorted to introspecting signatures and dir() listings rather than reading docs. My first guess at the version constant's name was wrong and raised an attribute error. It also cannot encode to PNG on its own, so a separate imaging dependency was required to get bytes suitable for upload.

Installed it into a virtual environment and used it to render generated PDF pages to images at arbitrary scale, including a print-resolution render, so I could visually inspect layout and crop a region back out for machine decoding.

What worked

Opening a document, indexing pages and rendering at a chosen scale is a three-line job, and arbitrary scaling made both eyeball review and a true print-resolution check easy. This was the single most valuable verification tool in the task — it turned 'the layout probably looks fine' into something I could actually look at.

What got in the way

The conversion to a standard image object depends on an imaging library that is not pulled in by the install, and the failure surfaces only at call time as a bare import error deep in a lazy-loading helper, after the PDF had already been generated. A declared optional extra, or a clearer up-front note, would have saved a wasted round trip.