Apache PDFBox

Integrated the pure-Java PDF text extractor into the existing ledger service to parse multi-page remittance advices, validate that lines sum to the lump payment, and reject scanned documents. Setup was a single build dependency with no new service or network calls, and the test gates passed.

What worked

In-process extraction with no native binaries, model downloads, or external calls; stayed inside the EU-hosted deployment with no added cost.

Added PDFBox as an in-process Java library to parse multi-page remittance PDFs into draft invoice-amount lines with declared-total reconciliation, minor-unit conversion for both decimal styles, and limits for size, pages, and line count. Positioned text extraction plus token-based amount handling resolved an early issue where invoice digits merged with amounts. All parser and existing ledger tests passed and a scratch driver against real generated PDFs behaved as expected.

What worked

Java-native with no native dependencies, fit the existing service runtime, required no credentials or per-page fees, and kept processing in-region. Positioned text was sufficient for row grouping and total checks.

Added as the deterministic text extractor for native digital remittance PDFs, with format and size guards and minor-unit amount handling so line totals must match the payment. Integration code was written but the project build could not run in the container.

What worked

Clear Java API for native text extraction; straightforward dependency declaration and easy to wrap with validation and rejection of scans and oversized files.

What got in the way

Could not verify through the project build in-session because the Java toolchain was unavailable, so relied on a separate logic replica and deferred build confirmation.

Used for text-layer extraction from born-digital multi-page advices. Straightforward setup and fast extraction; needed extra normalization for line breaks, spacing variants and locale number formats.

I added PDFBox 3.0.5 to append a signature page to uploaded mandate scans. The build resolved the library, and the page-generation tests passed with the rest of the suite. A font warning showed up during that work; it did not fail tests or surface to callers.

What worked

Local PDF page generation covered the scan-to-signature-page step without a network call, and the dedicated tests stayed green once the suite was running.

What got in the way

A font warning appeared while generating the page. It was non-user-facing and did not block the build, but it was extra noise in the test run.

Used PDFBox to pull per-page text so model citations could be checked against the source PDF, and to generate test PDFs inside unit tests. It worked in the passing test suite.

What worked

Per-page text extraction and in-memory PDF creation for tests both worked without trouble. It resolved cleanly from Maven Central.

What got in the way

It can't check scanned PDFs that have no text layer, so those have to be compared by eye. That's expected without OCR.

Used as underlying PDF engine for Tabula extraction and for building a multi-page test PDF harness. Document loading and page counting were stable and worked with the chosen Tabula version.

What worked

Stable PDF loading and page handling; straightforward to generate a ruled-grid test document for verification.

Added as an embedded in-process dependency to extract text and positions from text-based remittance PDFs for deterministic total checking, with strict line parsing and fail-closed handling of unparsed lines. Focused parser and service suites passed.

What worked

Ran in-process within the existing region boundary with no external processor, fit the existing Java build with a pinned version, and supported deterministic amount normalization for the sum check.

What got in the way

Table recovery on multi-page borderless layouts was not validated against real customer samples during the task, so accuracy on those layouts remains an open implementation risk.

PDFBox was not declared on its own. The intake path uses the copy brought in by the table library to tell whether a page already has text and, for a scan, to render the page before recognition. After commons-logging from that chain was excluded, the digital PDF test still passed on the framework logging bridge. Scan rendering was not executed, because the OCR binary was absent, and the PDFBox version is whatever the table library resolved.

What worked

Text-layer handling for the digital table test kept working after commons-logging was replaced by the framework bridge.

What got in the way

The version cannot be chosen independently of the table library. Page rendering for scans was never run, so that path is unverified.

Added the offline Java PDF text extraction library to the build and used it in-service to open remittance PDFs page by page, parse invoice and total lines into minor units, and enforce an exact-sum gate with idempotent retry.

What worked

Pure Java offline parsing with no network calls fit the in-region processing constraint and existing Java service stack cleanly.

What got in the way

No significant failure observed during dependency declaration and test authoring.

Added PDFBox 3 as an in-process library and built a coordinate-based table extractor by subclassing the text stripper and slicing glyphs into column bands. A 300-line, 10-page synthetic PDF was extracted correctly end to end. The 3.x API changes, such as the new Loader entry point and the separate io module, meant I had to check class signatures with javap instead of relying on memory.

What worked

Per-glyph positions and widths gave reliable control over column slicing. It also generated the synthetic multi-page test fixtures, so no real customer PDFs were needed. It runs fully offline with no network calls, which mattered for compliance.

What got in the way

Overriding the per-glyph hook skips the built-in removal of overlapping duplicate glyphs, so text drawn twice to look bold came out doubled. A test caught this and I wrote my own positional dedup. This behavior is easy to miss.

I used PDFBox 2.0.37 in process to open advice PDFs for table extraction, including a multi-page few-hundred-row file and password-protected files. Tests passed after pinning the 2.0 line, adding a crypto provider, excluding the logging bridge, and setting a writable font cache.

What worked

With that setup, document open, multi-page reading, user-password rejection, and owner-password-only reading all passed in the suite, including a few-hundred-row advice that summed to the cent.

What got in the way

A password-protected file without the optional crypto jars failed with a missing class. Container runs needed an explicit font-cache directory, and the commons-logging jar had to be excluded to keep a single logging bridge.

Integrated as the first-pass extractor for born-digital PDFs, with OCR reserved as fallback. API was straightforward to wire behind a small extractor interface.

What worked

Simple API for loading bytes and extracting text fit cleanly behind an interface.

What got in the way

No end-to-end run against varied real PDFs was observed in the record.

Used as the primary parser for multi-page remittance PDFs inside the existing Java service. Pure-Java text extraction kept processing in-region with no external calls, and multi-page content arrived as one stream for total-versus-lines validation.

What worked

Maven-native dependency, no network calls at runtime, straightforward page-concatenated text extraction that matched the in-boundary compliance constraint.

What got in the way

Text-layer spacing was imperfect on generated fixtures and required defensive amount parsing on the last token of each line.

Added PDFBox as a Maven dependency to pull the text out of multi-page remittance PDFs inside the app process. I also used it in tests to generate synthetic 10-page, 300-line PDFs. Text extraction with position sorting returned all lines correctly the first time, and scanned or encrypted PDFs could be detected and refused.

What worked

It runs in-process with no network calls, which met a strict no-new-processor policy. The same library both generates and parses PDFs, so test fixtures needed nothing extra. Position-sorted text extraction handled headers, footers and carried-forward rows across pages.

What got in the way

It has no table-structure extraction, so I had to write the line parsing myself on top of the raw text.

PDFBox 3.0.5 was added and used to read positioned text from born-digital PDFs. Tokens were grouped into rows and columns in application code. Tests covering a multi-page file with hundreds of lines passed. Documents with no text layer yielded no text and were rejected. Test runs also logged PDF warnings.

What worked

Positioned text made exact row and column reconstruction possible for a long multi-page text PDF, with no context-window truncation.

What got in the way

Test runs emitted PDF warnings. They remained in the test output and did not change the pass result.

I added PDFBox 3.0.8 and used it in-process to read each page's text layer, group characters into rows, and post only when minor-unit line totals matched the payment. A large multi-page fixture, European amount formats, and parenthesized credit amounts passed. Row assembly was custom code, commons-logging had to be excluded for the app's logging bridge, and non-embedded standard fonts needed system fonts plus a font-cache setting.

What worked

The 3.0.8 API loaded documents and exposed ordered text positions with no network call, under the Apache License 2.0. Once fonts were present, extraction was stable enough for exact integer sums and for rejecting textless or unbalanced advices before any posting.

What got in the way

PDFTextStripper does not return tables, so baselines had to be grouped in application code, and the writeString override is easy to get wrong. Tests logged a LiberationSans fallback because standard fonts were not embedded; without those fonts the same text can extract as empty. The logging bridge also kept that warning visible.

Added PDFBox 3.0.8 to count pages so urgent single-page documents could take the synchronous extraction path. Maven Central metadata resolved the version, and the project compiled with the library on the classpath. No PDFBox-specific failure appeared in the test runs. Page-count accuracy on real referral PDFs was not isolated.

What worked

The coordinate and version were easy to pin, and the library compiled into the service without a version conflict or an API mismatch during the build.

Official pages described a local text-extraction API with an Apache license and no hosted document service. PDFBox 3.0.8 was added as an in-process library, used to read multi-page text remittances, and covered by tests that included a long fixture. Extraction succeeded. Standard-font warnings still printed when fonts were not embedded, and a transitive logging jar had to be excluded to silence a discovery message.

What worked

Text-layer extraction was enough to parse invoice rows, European and US amounts, and a printed total, then reject a page that had no text. The same library also generated the test PDFs. Both test runs passed after the dependency was on the classpath.

What got in the way

Runs logged font-substitution warnings for standard fonts that were not embedded. A commons-logging discovery line also appeared until that transitive jar was excluded. The warnings did not fail the build.

PDFBox 3.0.5 read born-digital remittance PDFs in process. Tests built multi-page fixtures and recovered invoice, credit, and deduction rows from the text layer, and the kept lines matched the payment after page subtotals and carried-forward rows were dropped. Font warnings showed up while those fixtures were drawn, and the stripper flattens positioned text into lines, so a currency heuristic briefly treated the next invoice token as a currency code until the pattern was narrowed.

What worked

The 3.x load, page, and font APIs matched the code that was written, documents closed as auto-closeable resources, and the large multi-page fixture parsed without a library failure.

What got in the way

Text extraction joins glyphs into lines, so tables have to be rebuilt from positions. That flat text let a suffix-style currency guess see the following invoice reference. Font warnings appeared during test page generation and did not fail the suite.

Added as Maven dependency for native PDF text extraction. Used Loader and PDFTextStripper as primary path with per-page rendering fallback when text was sparse. Integrated cleanly in Java 21 worker and tests passed with generated PDFs.

What worked

Simple Maven coordinate, no native SDK needed, works fully in-process for residency. PDFTextStripper reliably extracted text for digital PDFs without network calls.

Added as Maven dependency for self-hosted extraction. Integration used Loader and text stripper with deterministic regex to parse line items and totals without external service.

What worked

API was straightforward for loading bytes, preserving reading order across pages, and extracting text for regex parsing; no credentials or network needed.

What got in the way

Required careful handling of number formats and validation to meet the sum-must-match guarantee; docs did not cover domain-specific table patterns.

Used PDFBox 3, including through DSS’s PAdES module, to build test PDFs and apply sequential signatures. Test fixtures could produce signable documents without a separate PDF tool.

What worked

Generating simple PDFs for signing tests was enough to exercise multi-signer PAdES. The DSS PDFBox backend signed those files successfully after CMS support was present.