Choosing the right finish: fusion, provenance, and deployment

pdf-inspector reaches its most interesting decision after OCR, not before it. This chapter asks what should happen when native and OCR paths produce different candidates: when should native text remain in control, when should OCR replace it, when should the two be fused, and when is a hosted document pipeline the more honest finish? It also connects that content decision to the Rust, CLI, Python, Node/Bun, and browser surfaces through which the result is delivered.

OCR should not automatically win

OCR and native extraction observe different representations of the same page. Native parsing reads the PDF's own text and drawing structure. OCR reads pixels produced by rendering. Native text can be exact where the font mapping and coverage are sound. OCR can recover words that exist visually but were never exposed as text, yet its output is a recognition hypothesis with confidence and model dependence. Treating OCR as the automatic winner would discard that difference.

pdf-inspector sends positioned OCR spans through the same deterministic assembly path used for native items. The spans are mapped from bitmap polygons into PDF coordinates and then passed through reading-order, table, chart, and Markdown processing. This is a strong architectural choice because it keeps the two sources comparable: OCR is not pasted onto the end as an unstructured paragraph, and it does not require a second layout language for tables or columns.

The final content decision still depends on why the page was routed. On a page whose native extraction was already rejected, a usable OCR result can replace the suppressed native output. On a clean page processed with Force, the native content remains valuable. pdf-inspector normalizes duplicate OCR blocks and merges only text that is genuinely additional, rather than replacing exact native words with a recognition copy simply because OCR ran.

An ambiguous page is more difficult. Native extraction may have retained a clean heading or a partial body before a scan or encoding signal caused the page to be routed. OCR may recover the missing body, repeat the fragment, or produce a weaker version of it. The pipeline therefore keeps a private native candidate and compares it with the OCR candidate before selecting the public result.

A candidate earns trust through several signals

The comparison is not based on one magic number. pdf-inspector measures the amount of alphanumeric content, a text-quality score, OCR confidence, character overlap, and material new coverage. Each measurement answers a different question.

Text quality asks whether the candidate looks like usable text rather than empty output, symbol soup, CID garbage, or a string with encoding problems. Alphanumeric mass distinguishes a substantial candidate from a short accidental fragment. OCR confidence describes the recognition engine's accepted spans, but it does not establish that the page is complete. Overlap asks how much the two candidates say in common. Novelty asks whether OCR adds a meaningful amount that native extraction did not contain.

These signals support conditional outcomes. If OCR is empty, weak, or otherwise unusable, the trustworthy native candidate can remain in control, but the page should recommend hosted processing when native coverage was already incomplete. If OCR mostly repeats a native fragment and adds no material content, retaining native text is safer; agreement between two partial hypotheses does not prove that the rest of the page was recovered. If OCR is materially complementary, the result can be fused. If the native page is empty or already rejected and OCR supplies usable text, OCR can serve as the page's source.

A second comparison protects exact native text from a misleading OCR result. OCR confidence may be high while its recognized Markdown is shorter or materially lower quality than the native candidate.