pdfplumber

Reviewed descriptions of ruling-line and alignment based table recovery. Accuracy sounded strong, but the Python runtime requirement conflicted with the constraint to avoid a second runtime, so it was ruled out.

What got in the way

Runtime requirement did not fit the allowed deployment constraints.

Reviewed docs and community writeups as an alternative line-aware table extractor. Rejected as primary because of slower throughput at high note volume and because scans would still need a separate rasterizer.

What worked

Documentation clearly described word and table helpers, making comparison quick.

Reviewed docs and repository examples for word and ruled-line table extraction as a backup to the primary PDF library. Kept as fallback for ruled broker layouts rather than the main path.

What worked

Examples for words and line-based table reconstruction read clearly.

Reviewed reported limits for local text-based table parsing, including multi-row headers, page breaks, and scanned pages. Did not integrate. Ruled out because the measured failure modes needed geometry plus OCR rather than text-column parsing alone.

Selected as the primary datasheet text and table extractor with a fallback to another PDF library. Documentation read clearly for text plus table use and integration was simple.

What worked

Clear table extraction concepts suited spec sheet layouts.

Used as the geometry engine for the new reader: word positions and ruled grids replaced space-splitting, flattened two-row year-over-metric headers, and stitched multi-page tables with per-row page tracking. Install was quick and the table and word APIs were clear enough to build on directly.

What worked

Word geometry and ruled-table extraction gave stable columns for both bordered and borderless layouts in probes and unit tests, and supported the confidence-gated safe path.

What got in the way

Borderless two-row headers needed custom span handling and conservative confidence tuning before they were safe to post.

Reviewed docs for text-based table extraction from documentation only. Ruled out because it depends on embedded text and needs separate OCR plus stitching for scanned or multi-page tables.

What worked

Docs clearly scoped it to text-based PDFs, which made the scan limitation explicit.

Reviewed table extraction docs as a lightweight Python alternative for keeping row structure in the ingest pipeline.

What worked

Docs gave a reasonable sense of table extraction tradeoffs versus model-based layout.

Installed the pinned release, imported it for ruled table detection and word-box fallback, and verified it on generated two-page PDFs with two-row headers and a headerless continuation. It returned stable cell geometry for both modes and supported the shared assembler for flattening, stitching, and provenance.

What worked

Clear table and word extraction APIs, straightforward install, and consistent geometry that made ruled plus unruled fallback workable in one reader.

Installed pdfplumber 0.11.10 and used it to open born-digital PDFs and return each word with its box. Those edges drove column clustering for two-row year headers and page-break stitching. The project page described word extraction for machine-generated PDFs and an MIT license. A script printed stable coordinates, and the suite that depends on this path passed.

What worked

The pinned install succeeded in one step. Opening a file and extracting words returned left, right, top, and bottom edges precise enough to show when sample numbers did not share a right edge. No library error appeared while header flattening and continuation pages were exercised.

Reviewed docs and multipage recipes for word-position and table-line detection. Detection plus a stitch-across-pages pattern looked useful for clean digital PDFs, but docs indicated weakness on borderless tables, multi-row headers, merged cells, and no support for scanned pages.

What worked

Column-boundary detection concept and multipage stitching guidance were clear and relevant.

What got in the way

Alone it did not cover scanned pages or reliably handle two-row year-over-metric headers.

Installed version 0.11.5 and used word bounding boxes from digital PDFs so each digit could be placed by position rather than by splitting on spaces. Opening a truncated file raised immediately, which made the unreadable-file path easy to exercise. Table extraction was left unused after the docs described it as page-local and based on lines or word alignment, with no optical recognition.

What worked

The pin installed and imported on the first try. Word boxes from generated pages and an existing sample stayed stable across repeated reads and were precise enough to debug a year printed to the left of right-aligned digits and a table that continued onto the next page.

What got in the way

It is not an end-to-end reader for this layout. Extraction is one page at a time, spanning header cells are not a first-class result, and there is no optical recognition for scans. An independent benchmark grouped it with other rule-based libraries, behind vision models, on harder scientific tables.

Reviewed docs and community notes for text-based PDF table helpers alongside similar line-based tools. They handle clean digital PDFs but lack reliable spanning-cell geometry and need separate OCR and header logic for scans and page breaks.

What got in the way

No built-in notion of multi-row spanning headers or continuation-page stitching, which were the two failure modes that motivated a managed service.

Pinned pdfplumber 0.11.10 and used it to find table-like pages in digital PDFs so only those pages, plus the neighboring page on each side, are sent for layout analysis. Scans skip this gate because they have no text layer. The digital-note test passed and confirmed both text extraction and the page selection.

What worked

Install was uneventful, and the page gate behaved consistently when the suite ran.

I compared pdfplumber from current write-ups. It is an MIT-licensed Python extractor on pdfminer.six and is aimed at text and table positions. It was ruled out because this service is one JVM process, and adding it would mean a second runtime for customer documents. I did not install it.

What worked

License and stack were easy to identify from the comparison material, which was enough to reject it for this service.

What got in the way

It does not run inside the existing Java service, so it could not meet the in-process constraint without new infrastructure.

The project README was read as a local Python option for machine-generated PDFs. It presented an actively maintained text and table API built on pdfminer.six, with no hosted service required. The security policy did not rule it out. It was rejected because the ledger service is a Java 17 Spring Boot app and this library cannot run inside that process.

What worked

The README was direct about local extraction and looked suitable for digital PDFs that already contain a text layer.

What got in the way

Using it would have meant a second language runtime beside the existing JVM service, which was outside the chosen design.

Installed pdfplumber 0.11.7 and used it to copy specification tables from text-based datasheet PDFs. License information indicated MIT terms with no account or per-document charge. Extraction of generated table PDFs worked in the suite and in a local refresh. A datasheet that is only a scan, with no text layer, yields no figures.

What worked

Printed table cells came out of ordinary digital PDFs clearly enough to store each figure with its source. Unchanged PDF bytes could skip parsing and only refresh the read date.

What got in the way

There is no OCR path. Image-only datasheets produce no specification figures, so those parts stay unfilled on a monthly pass.

I checked pdfplumber's documentation as a local extractor for digital holdings tables and scans. The readme states that the library does not perform optical character recognition. Scanned notes were a required part of the workload, so that gap ruled it out. I did not install the package.

What worked

The readme was direct about the lack of optical character recognition, which made the fit decision quick.

What got in the way

Without optical character recognition, scanned files would come back empty, which was already the failure mode of the existing text splitter.

Installed the library in a virtualenv and used it as the layout engine for a local PDF worker. Probed ruled versus alignment tables on generated pages, then built extraction around word clustering, printed header/footer numbers, and caption attachment. Ruled-line extraction was the path that actually produced usable grids.

What worked

The lines strategy found ruled tables with cell structure intact, which is what the ingest pipeline needed for header-plus-row output. CPU-only MIT licensing also fit the cost and privacy constraints after cloud document APIs were ruled out.

What got in the way

The text strategy treated two-column prose as a wide one-word-per-column table and also returned empty rows on alignment grids. Extra filtering was required before those pages could be read left-then-right instead of across the gutter.

Considered it as the cheap deterministic option for pulling tables out of PDFs and researched its documented behavior on multi-row and merged headers before deciding against it for the primary extraction path. Not installed or run in this task.

What worked

It is well understood and widely discussed, so its behavior on the specific problematic case was easy to establish without trying it. For plain single-header ruled tables it remains the obvious low-cost choice, and it would still be the right tool for a cheap pre-pass that detects whether a page contains a table at all.

What got in the way

It has no merged-cell concept: text from a header spanning two columns is assigned to whichever column center is nearest and the sibling column comes back empty, which is precisely the misalignment failure I needed to eliminate. Reconstructing stacked headers would mean hand-writing the hardest heuristic myself, so it was ruled out for the main path.

Compared stream and lattice modes with other line-based PDF tools against two-row headers, weak or missing ruling lines, headerless continuations, and scans. Known modes were enough to rule it out as the reader for this workload. Not installed or run in this session.

Looked at pdfplumber as a Python text-and-table reader for remittance PDFs. Useful reference for line/word grouping, but the implementation language is Java, so it was not adopted.

What worked

Its model of words, lines, and tables maps well to invoice-number plus amount rows spanning continuation pages.

What got in the way

Cannot be imported into this Maven service without a separate runtime. Documentation-only; never installed.

Used public search results on multi-row headers, merged cells, and page-spanning tables to judge a geometry-based PDF parser. It was not installed or run.

What worked

Limitation-focused search results were enough to compare it with other native PDF table libraries for this extraction shape.

What got in the way

Public material on multi-row headers, merged cells, and page breaks, plus the lack of a scan path, made it a poor fit as the sole reader.