Proposal: adaptive OCR fast path for born-digital PDFs

[Gua-code-VR]

Proposal: adaptive OCR fast path for born-digital PDFs

Hi Docling team,

we ran a small benchmark on a 6-page born-digital insurance-style PDF and found a potentially useful performance optimization opportunity.

All document-specific and customer-identifying data have been removed from the examples below.

Test document

• 6-page native-text PDF
• insurance / form-style layout
• contains structured tables, labels, fields and repeated sections
• CPU execution on Windows

Results

Default pipeline with OCR enabled

Docling reported:

• conversion time: 154.52 s
• texts: 176
• groups: 17
• tables: 6
• pictures: 12

The structural quality was very good, especially for table reconstruction and document hierarchy.

Same document with --no-ocr

Docling reported:

• conversion time: 19.65 s
• total wall-clock time measured externally: ~30.1 s
• texts: 40
• groups: 9
• tables: 6
• pictures: 12

This is roughly a 7.9x reduction in Docling processing time.

Interesting result

The table reconstruction was unchanged with OCR disabled.

For example, the main table retained the same logical shape:

COMPANY NAME        |       |              |
STREET ADDRESS      | ZIP   | CITY         | XX
TAX ID / VAT NUMBER |       |              | INTERNAL ID

All 6 detected tables had the same logical shape and content structure with OCR enabled and disabled.

OCR did add substantially more text elements and logical groups, but it did not improve the table reconstruction in this born-digital PDF.

Suggestion

Would it make sense to add an adaptive fast path for born-digital PDFs?

Possible pipeline:

PDF
 ↓
cheap native-text / quality preflight
 ↓
native text sufficient?
 ├─ yes → native text + geometric layout + table structure
 │          ↓
 │       confidence check
 │          ↓
 │       OCR only on ambiguous regions/pages
 │
 └─ no  → full OCR / layout pipeline

In other words, OCR could be selectively activated per page or even per region instead of being part of the full default path when native text is already reliable.

This could potentially preserve most of Docling's structural quality while significantly reducing latency on born-digital documents.

Why this may be useful

In our test, the main performance cost appeared unnecessary for table reconstruction:

OCR ON:  154.52 s
OCR OFF: 19.65 s

Tables:
6 → 6

Table logical structure:
unchanged

The trade-off was mainly in richer text extraction and grouping rather than table accuracy.

A hybrid mode such as:

native text first
→ structural confidence
→ OCR only where needed

might provide a useful middle ground between full OCR quality and fast native-PDF processing.

We would be happy to provide additional anonymized benchmark details if useful.

[wittjeff]

Thanks for the numbers. My company has been looking at the same cost from the other side, and I think most of this pipeline is already in docling. The 8x on your file probably comes from a region-selection rule rather than a missing fast path.

What the default already does. Since 2.116 (#3710), the default OCR mode is pdf_aware_layout_regions. OCR runs only on layout clusters, and any cluster covered only by programmatic text is skipped. --no-ocr and --ocr-mode full_page are the two extremes; the default is meant to be your "native text first, OCR only where needed" middle ground, at cluster granularity.

Why it doesn't behave that way on a form. Since 2.121 (#3981), a cluster also goes to OCR if any bitmap or vector shape touches it, even when it has a good text layer (BaseOcrModel._find_pdf_aware_layout_ocr_rects, still the case on main). On a form, nearly every label and field sits inside a stroked box or on a rule. So nearly every cluster qualifies, and the default comes close to OCRing the whole page. In #4174 this doubled the OCR'd area on plain text documents. #4139 shows the other side effect: OCR output replaces a text layer that was already correct. #4209 lets only bitmaps override programmatic text. Clusters with no text layer are still OCR'd, so outlined text keeps working. It's waiting for review. If you can run your file on that branch and post the timing and element counts, that would be a very useful data point.

One caution before treating the OCR pass as unnecessary: 176 → 40 texts is a big drop. The layout postprocessor drops clusters that contain no text cells. So most of those ~136 elements are probably regions where docling found no programmatic text and got the text only from OCR. On an insurance form, the usual suspects are:

• Filled-in field values stored as AcroForm widgets instead of page content. docling-parse reads widgets, but docling doesn't turn them into text today. feat: extract AcroForm widget fields into FormItem key-value graphs #4055 (draft) extracts them as FormItem key/value pairs, which would recover those values exactly, with no OCR.
• Text drawn as vector outlines, or text inside the 12 pictures (logos, stamps).

If that's what they are, --no-ocr isn't a fast path for this document. It silently drops the form's content. A diff of the two Markdown exports would show which case you have, and I'd be curious what it turns up.

The same point applies to tables. Table structure is predicted from the page image, so an unchanged shape with OCR on or off is expected. The cell text is the part worth comparing. Where the text layer is good, the OCR run can actually be the worse one (#4139).

Where your proposal goes beyond what docling does now is the quality check. The PDF-aware selector trusts any cluster that has text cells. A text layer that exists but decodes badly (fonts with no ToUnicode map, private-use codepoints, mis-encoded glyphs) is never OCR'd. A cheap per-cluster check along those lines, sending the cluster to OCR when it fails, would fit neatly into the existing selector without a new pipeline. That seems like the piece worth designing here, once the shape trigger is settled.