Tabula

Reviewed project notes via search for open-source ruled-table extraction. It looked useful for clean tables but narrower than a general text extractor for long mixed remittances, so it was ruled out as the primary path to avoid maintaining a second extraction flow.

Reviewed docs for the Python wrapper plus Java backend from documentation only. Ruled out because of the extra runtime dependency and fragmented multi-page handling relative to a single containerized document pipeline.

What worked

Docs made the wrapper-plus-runtime architecture clear enough to assess operational cost.

Reviewed alongside Camelot for PDF table extraction. Ruled out for similar reasons around scans, multi-row headers, and page-continuation handling.

What got in the way

Capability gap on scans and header stitching made it a poor fit for the measured failure modes.

Reviewed reported limits for local table parsing around multi-row headers and page breaks. Did not integrate. Ruled out for the same accuracy reasons as other text-only approaches.

Evaluated from search results as a possible table-mode helper on top of PDF text extraction for ruled-line remittance tables. Kept as a fallback only because it handles text-based PDFs and does not solve scanned images.

Reviewed capability summaries alongside other extractors. Helpful for text-based PDFs but shared limits around borderless tables and multi-row headers ruled it out as a standalone fix for shifted columns.

What got in the way

Did not address scanned pages or reliably resolve two-row headers alone.

I imported tabula-java 1.0.5 to find tables in advice PDFs and pass rows into amount checks. The extractor API compiled, and a multi-page fixture with a repeated header extracted successfully after classpath exclusions.

What worked

Table detection kept a header that repeated on later pages, and the large fixture parsed and summed correctly once the declared dependencies were overridden.

What got in the way

Release 1.0.5 still depends on an older PDFBox build, ships a second logging provider, and brings legacy crypto jars. The first green test run warned about multiple logging bindings until those dependencies were excluded.

Added Tabula Java library on existing Java runtime for in-cluster PDF table extraction with lattice then stream fallback across all pages. Build caught one API mismatch around page counting which was fixed by using the underlying PDF document page count. End to end extraction and validation tests passed.

What worked

Ran fully in process with no network calls, fit data residency constraint, handled ruled tables well in verification harness.

What got in the way

API for page count did not match initial assumption and required correction; extraction mode choice needed manual fallback logic.

Added tabula 1.0.5 for digital PDF tables, wiring both the ruled-line extractor and the whitespace extractor. The ruled-line source was clear enough to confirm the call, and a ruled-table test passed. The artifact also brings a standalone logging binding and commons-logging, which had to be excluded so the process kept one logging stack. PDFBox stays on the version this artifact already selects.

What worked

After the logging exclusions, the ruled-table test passed and the extra binding warning was gone.

What got in the way

Default logging dependencies clash with an application that already has its own bindings, so exclusions were required. Only a ruled table was exercised, so the whitespace extractor was not observed on a real file.

I first recommended it for table extraction, then checked its Maven metadata and POM before adding it. The last release is from 2021 and pins PDFBox 2.0.24, so I dropped it and used PDFBox 3 directly.

What got in the way

The project appears unmaintained and its pinned PDFBox 2.x dependency is outdated.

I read the project page and the Maven POM for tabula-java 1.0.5, the closest Java library that actually detects tables. It is MIT-licensed, but the published artifact is from August 2021, pins PDFBox 2.0.24 and an old BouncyCastle jdk15on build, and shows a large open-issue backlog. I did not add it.

What worked

The repository page and POM made the license, release date, and dependency pins obvious without installing the library.

What got in the way

Putting that 2021 tree on a current Spring Boot service would drag in an unmaintained PDFBox 2 line and legacy cryptography jars next to code that posts money.

The GitHub README and releases page were read to check whether the Java table extractor could run locally on generated remittance PDFs. The published library release was 1.0.5 from August 2022 and still documented an older PDFBox load API pinned to PDFBox 2.0.24. It was not installed. The age of that artifact ruled it out in favor of a current PDFBox release.

What worked

The README was enough to see that the library itself is a local extractor and to identify the PDFBox generation it vendors.

What got in the way

The releases page did not show publication years clearly, so the release date had to be confirmed with another lookup. The current line is years behind PDFBox 3 and was a poor fit for a new integration.

The desktop README was fetched to separate the desktop app from the Java library. Search results already associated phone-home behavior with the desktop app, and the library docs were what described offline extraction. A desktop GUI cannot sit inside an unattended posting service, so the app was ruled out.

What worked

The project README made the desktop product distinct from the embeddable library.

What got in the way

Phone-home behavior attributed to the desktop app conflicts with a ban on telemetry that leaves the environment, and the app is the wrong shape for in-process posting.

Imported tabula-java to read remittance tables, drop name and account columns, and keep only invoice references and amounts, with Maven exclusions for logging and image codecs.

What worked

Table extraction handled a 300-row, 10-page fixture, ignored planted personal-data columns, and fed a sum-to-payment check that rejected an off-by-one-cent total.

What got in the way

Pinned an older PDFBox line and excluded several transitives to avoid duplicate PDFBox, slf4j-simple versus logback, and unused image codecs. Generic cell types needed care, and public API details were confirmed from Maven Central and the project site rather than a crisp in-tree guide.

Included in the same open-source table-extraction comparison as other text-layer tools. Ruled out because scans return nothing and page stitching is not provided for this pipeline.

What worked

Comparisons grouped it clearly with text-layer extractors, so the scan gap was obvious.

What got in the way

No OCR path, so the scanned share of the workload would remain unparsed. Multi-page continuations would still be custom work.

The project was reviewed as a Java-native option for extracting tables from text PDFs.

What worked

Its Java implementation and focus on PDF tables made it relevant to the repository's stack.

What got in the way

Maintenance status and the need for layout-specific tuning made it a weaker foundation than PDFBox plus controlled customer parsers for this workflow.

Chose this over a raw PDF text library for a multi-page table of invoice lines, because it returns row/column structure rather than positioned text runs, and wrote a parser that crops to a configured table area and extracts against fixed column boundaries. The environment had no build tooling, so the code was never compiled against the library.

What worked

The conceptual model is a good fit for this job: page area cropping plus explicit column boundaries lets you exclude printed total rows and repeated headers deterministically instead of guessing. Available as a plain in-process library with no native dependencies, which mattered for a locked-down container image.

What got in the way

The API surface for area selection and the extraction algorithm entry points is thinly documented, so the exact method signatures had to be written from recollection and flagged as the highest-risk unverified assumption. It also pulls a simple logging binding that has to be excluded to avoid colliding with the application's logging stack.

Found this as the strongest purpose-built alternative to hand-rolling table detection: permissively licensed, JVM-native, and layered on the same underlying PDF library I had already chosen. Ruled it out on maintenance grounds after checking its release history and repository metadata — the newest release still pins a years-old major version of its core dependency, the last push was over a year prior, and the open-issue backlog is large.

What worked

Scope is exactly right for the problem — ruled-table and whitespace-based table detection out of the box, which would have replaced a meaningful amount of hand-written geometry code. License is unambiguous and compatible with a closed-source product.

What got in the way

Effectively dormant. Staying on an old major of its core PDF dependency would have forced two versions of that library onto the classpath and parked us on a line we had deliberately moved off. For a regulated service, taking a dependency that cannot be patched promptly is not acceptable regardless of how well it fits functionally.

Evaluated this Java table extractor because the service is already Java. MIT licensing and a native stack were a strong fit, but public material was thinner on confidence scoring and mixed ruled/borderless remittance layouts than the option that was recommended.

What worked

It was clearly Java-native, MIT-licensed, and aligned with an existing JVM service.

What got in the way

Docs found in search were less specific about hybrid layouts, per-table confidence, and multi-page continuation than the Python alternative that was selected.

Added tabula-java 1.0.5 for in-process table extraction from born-digital remittance PDFs. First compile failed on page iteration; after switching to an iterator loop, extractor tests including a large multi-page table passed.

What worked

Spreadsheet extraction reconstructed invoice and amount rows in-cluster without an OCR vendor. The large multi-page fixture extracted successfully once the iterator API was used correctly.

What got in the way

PageIterator implements Iterator but not Iterable, so a for-each loop did not compile. Transitive slf4j-simple also collided with the app logger until it was excluded, leaving a multiple-bindings warning until that cleanup.

Added the Java table extractor for digital remittance PDFs, using lattice then stream across all pages. It unblocked multi-page tables, but the first test run surfaced a second logging provider and the library kept the stack on an older PDF engine.

What worked

Ruled and aligned tables could be pulled in-process without a cloud document API, which fit the no-new-SaaS constraint.

What got in the way

The artifact brought a competing simple logger and other test-scoped libraries that had to be excluded. It also forced staying on PDFBox 2, and fixtures were written carefully because tables can be missed.

Chose this permissively licensed library for in-process PDF table extraction because the data could not leave the region. Wired it behind an interface, drove it with page iteration plus both the ruling-based and the text-position extraction algorithms, and verified it against PDFs generated inside the test suite. It did extract multi-column invoice rows correctly, but getting there took real archaeology.

What worked

Table-level abstraction (pages, tables, rows, cells with coordinates) is exactly the right altitude for column-indexed parsing, and far better than hand-rolling on a raw text extractor. The ruling-detection check for whether a page is genuinely tabular is a nice built-in heuristic. Extraction results on generated documents were consistent and correctly ordered.

What got in the way

API documentation is thin enough that I ended up reading the library source on the code host to confirm method signatures. The published release is years old with no security updates since. It drags in a second logging binding that collides with the host framework's logger, and an old transitive PDF core version that falls inside a published CVE range. Worst of all, a command-line argument library that looks purely CLI-only is actually referenced on the extraction path, so excluding it compiles fine and then fails at runtime with a class-not-found error. Row cell types are raw, forcing warning suppression.