Docling

Reviewed open source layout and table extraction quality. Quality looked strong and operating cost looked low, but it required a second runtime sidecar that conflicted with the project runtime constraint and left large re-ingest throughput as self-managed work.

Reviewed open-source PDF and table-extraction docs as a CPU-friendly self-hosted alternative to paid APIs for digital documents.

What worked

Docs clearly explained local execution with no per-page fee and no GPU requirement for text-based PDFs.

Reviewed technical material on layout-aware table extraction. Capability looked relevant, but the Python and model-inference footprint conflicted with runtime and large reprocessing constraints, so it was ruled out.

What got in the way

Operational footprint did not fit the no-second-runtime and throughput constraints.

Reviewed open-source self-hosted document and table extraction notes, including license and multilingual handling. Documentation read well for a privacy-sensitive alternative to SaaS APIs and supported the decision to favor deterministic in-region parsing.

What worked

Self-hosting story and open license terms were clear and directly relevant to the residency constraint.

Reviewed docs for open-source document parsing and table handling. Attractive for self-hosting and data control but ruled out because accuracy tuning and infrastructure ownership would fall on a small team. Not installed or run.

What worked

Documentation gave a clear picture of local parsing without sending data to a third party.

What got in the way

Expected accuracy on messy broker tables and hosting effort were hard to estimate from docs alone.

Read project documentation only while comparing open-source structure-aware extraction against a lighter geometry approach. It looked capable but heavier than needed, so it was not installed or trialed.

What worked

Overview docs clearly described table structure support for comparison purposes.

What got in the way

Not enough signal from docs alone to judge operational weight versus the simpler chosen path.

Reviewed project notes via search for AI-based layout and table conversion. Output quality sounded strong but it was ruled out on operational fit because it would add a heavier Python and model-weight runtime alongside the existing Java service.

Integrated as a local sidecar service for layout, reading order, table structure, captions, and OCR, mapped into the existing parsed-document shape with validation and fallback handling.

What worked

Capability match for row-level tables, reading order, and scan OCR was strong, and the HTTP sidecar pattern kept the main runtime unchanged.

What got in the way

API details for converter output and caption handling needed defensive fallbacks, and the service could only be compile-checked because the package was not installed in the environment.

Evaluated as the selected self-hosted document pipeline for layout plus table structure with whole-document conversion and a CPU container path. Documentation supported an MIT license, Python version floor, container serving, and table-structure options; no install or live run was performed in this task.

What worked

Docs clearly described single-pipeline table handling, container use, and model-caching behavior relevant to residency constraints.

Evaluated from documentation as a self-hosted parsing option. Documentation conveyed heavier resource needs than necessary for spreadsheet and text-layer PDFs, so it was set aside for this volume.

Reviewed as a newer document-conversion option with table and OCR support. Passed over in favor of a smaller deterministic stack with fewer dependencies and more predictable finance-number handling.

What worked

Project docs gave a useful overview of table, header, and OCR coverage.

Reviewed docs for layout-aware open-source extraction with strong table support. Capability was attractive but the additional runtime requirement conflicted with the Node-only constraint, so it was ruled out on operational fit.

What worked

Table and layout capability was well described.

What got in the way

Runtime requirements did not fit the deployment constraint.

Fetched the serve usage guide and searched for the convert-file JSON shape, including tables, texts, and pictures. From that, a client was written that posts each PDF to a configured base URL and maps the JSON document, with cell matching enabled and full-document OCR left off. The container was not started. Tests used a stand-in response, so the live schema, errors, and timing were not observed.

What worked

The usage guide was available as one fetchable document. A base URL was enough to describe how the client should reach the converter, and the request options for cell matching and OCR were clear enough to set without an account.

What got in the way

The response field layout was not apparent from the usage guide alone and took a separate search for the document schema. With no running server, there was no check that the mapped fields match what the current image returns, and no observation of timeouts or error payloads.

Ran docling-serve locally from pip and called its async HTTP API (submit file, poll status, fetch result) from a new Node parser. Dumped the OpenAPI spec from the app object to confirm endpoints, auth header and options. Converted a generated multi-page manual and a skewed image-only scan. Table structure, multi-level headers and OCR of digits were very good. Setup needed a headless OpenCV swap, and the server was OOM-killed several times in a 4 GB sandbox.

What worked

Async convert/poll/result flow is simple to integrate. OpenAPI spec is easy to extract and accurate. Table cells come with row/column spans and header flags. Repeated headers on continuation pages were reconstructed. OCR got every number right on a blurred, rotated scan. Env vars for workers, page batch size and threads let it run with less memory.

What got in the way

Default install pulled opencv-python, which failed without libGL until replaced with the headless build. Memory use was high enough to be killed repeatedly on 4 GB, and it kept models loaded between jobs. Poll wait returned before completion, so early result fetches got 404s. Table captions were not linked to tables, all headings came back as level 1, running headers and footers were mixed into the body, and column-header flags were only partly set.

Ran docling-serve locally from pip as a sidecar and wrote a Node client against its async submit-then-poll HTTP API. Results came back correct end to end. On CPU, though, memory went past 3 GB on a five-page document and the sandbox killed the server after each file, so every file needed a fresh restart.

What worked

The async submit-and-poll API avoided the roughly two-minute limit on the one-shot endpoint. The health endpoint made startup easy to detect. Its output matched the library's JSON, so the same mapper code worked for both.

What got in the way

Memory use was high and seemed to grow from one conversion to the next. It was OOM-killed under a 3 GB limit even with one worker and fewer threads. I needed the same opencv headless swap as with the library.

Installed Docling in a Python venv using the CPU torch index and ran it on generated test manuals to get real JSON fixtures. It recovered table structure well, including row spans, multi-level headers and captions, and its OCR read a skewed typewritten scan correctly. To get it running headless I had to swap opencv-python for opencv-python-headless.

What worked

Table structure came out accurate, with spans and header rows marked. Every item carries per-page provenance with character spans, so I could split text that had been merged across pages. OCR handled a skewed image-only page. The JSON schema was easy to map into our own types.

What got in the way

Page headers and footers sat in the main body tree, marked only by a content-layer flag, not in the furniture tree. One item merged a table caption with OCR text from the following page. Some captions weren't linked to their tables. The default opencv dependency needed replacing with the headless build. The install is heavy because of torch and model downloads.

Read the project docs as a self-hosted, open-source option. Clear overview, but self-hosting OCR and table models was more operational work than this team needed, so it was kept as a fallback rather than chosen.

Read the repo, usage and installation docs. Strong table model and several OCR engine choices, but it is Python-only for a .NET stack and I found no built-in merging of tables across pages.

Reviewed docs for self-hosted document parsing and local deployment. Compliant direction but heavier than needed for the deterministic total-check task, so a lighter in-process table library was preferred.

Installed 2.97.1 and read its type declarations to map tables, pictures, captions, page items, and furniture into the existing page model. The declarations separated body content from headers and footers. The runtime entry file was a short re-export, so the item walker was not in that file. The dependency was removed before tests because the mapper did not import it.

What worked

Table, cell, picture, and label interfaces were explicit enough to keep header rows, captions, and reading order without guessing field names. Furniture was distinguishable from body groups, which kept headers and footers out of the main reading order.

What got in the way

The published JavaScript entry was only a few kilobytes and re-exported the implementation, so searching that file for the item walker found nothing. The package was not needed at runtime once the mapper used a local shape.

Installed the 1.67.0 Node addon to supply table structure, reading order, captions, and selective OCR for manual ingest. The prebuilt binary failed to load until a small compatibility library was preloaded. Declarations covered JSON conversion and OCR flags. Printed page labels were read with a separate library. Layout models were never installed, so a live conversion was not run.

What worked

Published declarations named async file conversion, a warm pipeline, and OCR controls, and those names matched the options used in the integration. After the compatibility library was preloaded, the addon imported and its dependency check ran. The readme stated that models resolve from the working directory and how to download them.

What got in the way

Importing the prebuilt Linux addon failed in the dynamic loader. It referenced an unversioned C++ string helper and C23 integer-parsing symbols that this host did not export. A newer C++ runtime from the distro archive required a newer C library as well. Satisfying the first symbol still left the addon unable to open. Layout models were absent, so table recognition on a real manual was not observed.

Read benchmark and project docs for an open-source document conversion toolkit as a self-hosted alternative. It looked promising for structure extraction but did not remove the need to own spanning-header heuristics and scan OCR operations.

Searched open-source self-hosted extraction with OCR support. Approach sounded aligned with keeping documents in-house, but limited time and no local install meant it stayed a docs-only comparison rather than a trial.