Text and Markdown extraction
One parse, two outputs: a rendered document for a person, and clean structured text for a pipeline.
Not shipped yet
This page describes work that is planned, not an API you can call today. It is here so you can judge whether the direction fits before adopting the viewer. Follow the roadmap for where it stands.
Why
The parsers already produce a model that mirrors the file format and knows nothing about CSS or the DOM — it already runs unchanged in Node. Extraction is that model with a different emitter, not a second implementation to keep in agreement with the first.
That distinction matters more than it sounds. Most pipelines run one tool to extract text and a different one to display the file, and the two disagree: the text you indexed came from somewhere the viewer cannot point at. Here both come from the same parse of the same bytes.
The expected shape
Sketched to show the direction. Names and signatures will change before any of it is released.
extract.ts
import { MemoryByteSource } from '@apertura/core';
import { openDocx } from '@apertura/docx';
import { toMarkdown, toBlocks } from '@apertura/extract';
const document = await openDocx(new MemoryByteSource(bytes));
// Headings, lists and tables survive as Markdown structure.
const markdown = toMarkdown(document);
// Or as data, when a pipeline wants structure rather than syntax.
const blocks = toBlocks(document);
// [{ kind: 'heading', level: 2, text: '...', anchor: 'p42' },
// { kind: 'table', rows: [...], anchor: 'tbl7' }, ...]What it will and will not do
- Structure, not layout. Headings, lists, tables, footnotes and their order. Not page numbers, not column positions — a pipeline does not want those and reproducing them here would be inventing information.
- Tables as tables. Including merged cells, which is where most extractors quietly produce nonsense.
- Anchors on everything. See citation anchors.
- No OCR, no images-to-text. What is not in the file will not appear.