Document Extraction Should Default to One Engine

TLDR: A second document engine is not a harmless fidelity helper. It duplicates parsing, fonts, graphics state, memory, and edge cases. Default to one engine that owns the neutral page model. Add another only when its distinct capability justifies a real architecture boundary.

PDF libraries are often compared through screenshots. One renders a difficult embedded font better, another exposes a richer operator list, and a third detects tables. It is tempting to combine the winners feature by feature.

That approach quietly builds multiple extraction systems.

Each engine parses object graphs, resolves resources, interprets fonts, applies transforms, and makes its own decisions about malformed files. Even if the second library is called only for an image crop, the browser still downloads and initializes much of that machinery. The result has two coordinate truths and two failure surfaces.

The cost is not only bundle size. Provenance becomes harder. If semantic text came from engine A but the pixels came from engine B, which operation supports an editable label? When bounds disagree slightly, which representation is authoritative? Those questions reach every verification and export feature.

A stronger default is one neutral page model: tokens, lines, blocks, paths, images, tables, ordered paint records, and provenance edges. Renderers and editors consume that model. Unsupported appearance can remain in a locked raster underlay without becoming extraction input.

This does not mean never use two engines. A server-side conversion service may provide layout intelligence that the client library cannot reasonably implement. A compliance workflow may require independent render comparison. Those are explicit capabilities with measurable value.

What does not justify the boundary is one prettier crop.

Before adding an engine, write down five numbers or contracts: transferred bytes, peak memory, duplicate parse time, coordinate reconciliation, and the downstream artifact shape. Then ask whether the new engine contributes structure, verification, or only pixels.

The best document pipeline is not the one with the most parsers. It is the one where every extracted claim can point back to a stable source representation, and where fidelity gaps remain visible instead of being hidden behind another opaque rendering pass.

One engine also makes testing sharper. A failing fixture maps to one adapter and one state model instead of beginning a debate over which renderer was right. That constraint may feel less flexible, but it creates the pressure to build a durable intermediate representation. In document intelligence, coherent evidence is usually worth more than locally perfect pixels.