The same parse, emitted as Markdown or structured text instead of DOM.

The parsers already produce a model that knows nothing about CSS or the DOM, and it already runs unchanged in Node. Extraction is that model with a different emitter: Markdown for a pipeline that wants text, or a structured tree for one that wants headings, tables and lists as data. One parse, two outputs, no second implementation to keep in agreement with the first.

Highlight the exact place in the original document that an answer came from.

Extraction hands back stable anchors alongside the text — a paragraph or run identifier and an offset inside it. Store them next to the chunk in your index, pass them back to the viewer, and it scrolls to that place and highlights it. This is the thing a backend that converts to PDF cannot do at all: the mapping from what you indexed to what you display does not survive the conversion.

Chunking that respects document structure, with anchors carried through.

Splitting on character counts cuts tables in half and separates a heading from what it heads. A chunker that reads the document model can split on structure instead, and carry the anchors through so every chunk knows where it came from.

A thin adapter over PDF.js, so one API covers every format.

PDF is the one format with an excellent free browser renderer already, and rebuilding it would create no value. The work is an adapter that presents PDF.js through the same interface as everything else — the same open call, the same highlight call, the same text map — so an application integrates once.

.doc, .xls and .ppt — the formats nothing in the browser reads.

The pre-2007 binary formats are a different kind of work: compound file binary containers and undocumented record streams rather than XML. They are also the place where there is no free alternative at all, in or out of the browser, which is what makes them worth doing — after the three current formats are solid.

The same engine in Node, producing PDF or PNG for thumbnails and print.

Not every application wants everything in the browser: previews in a list, thumbnails in a search result and print output are legitimately server-side. The renderer is already DOM-agnostic enough for this to be an emitter rather than a rewrite.