@apertura/docx-view

Translates resolved WordprocessingML properties into CSS declarations. Runs after style resolution, never during parsing. Keeping the two apart is what makes it possible to lay the same document out at different zoom levels, to export it without a DOM, and to fix a rendering bug without touching the parser. Declarations are emitted as shared classes through a {@link StyleSheetBuilder} rather than as inline styles. In a document with 200 000 runs the difference is roughly 200 000 style attributes versus about fifty CSS rules, which shows up directly in style recalculation time and in memory.

Renders a Word document as paginated, virtualised pages. The pipeline runs in three stages that are deliberately kept apart: rendering turns the model into DOM without knowing about pages, the layout engine measures that DOM and decides where pages break, and the virtualiser decides which of those pages exist in the document at any moment. Because the stages do not know about each other, changing the zoom re-runs only layout, and scrolling re-runs only virtualisation.

Paginates a document by measuring its rendered content. Word does not store pages; it stores a flow, and where the pages fall depends on the fonts available, the printable area and the line-breaking of the renderer. Viewers usually sidestep this by trusting Word's cached `lastRenderedPageBreak` hints, which reproduces the pagination of whatever machine last opened the file and silently disagrees with what the reader now sees. This engine measures the content as it will actually be displayed and breaks accordingly. Three properties make it viable on very large documents: - Blocks are flowed in chunks, so a chunk costs one forced layout rather than one per block. - The main thread is released between pages, so a 2000-page document paginates without freezing the page and can report progress. - Finished pages leave the measuring frame immediately, so peak memory is proportional to a page, not to the document.

Mounts only the pages near the viewport. This is what makes very large documents usable. A 1500-page document contains on the order of a million DOM nodes; creating them all costs seconds of layout and hundreds of megabytes, and the browser then repeats that work on every resize. Here each page is a fixed-size box from the start — the layout engine already knows every page's dimensions — so the scrollbar is correct immediately and the content of a page is created only when it approaches the viewport and discarded once it leaves. Because page geometry never depends on the mounted content, mounting and unmounting cannot shift the scroll position, which is the failure mode that makes naive virtualisation jitter. Visibility is decided from geometry in one place, and `IntersectionObserver` and `scroll` merely signal that a recalculation is due. Relying on the observer alone is tempting but fragile: it interacts badly with `content-visibility`, is silently unavailable in some embedded contexts, and when it fails it fails invisibly — the document simply stops rendering pages. Recomputing from rectangles is cheap enough to be the source of truth.

Resolves theme colour and font references into concrete values. Word rarely writes a literal colour. It writes "accent1, 40% lighter", encoded as a theme slot plus `themeTint`/`themeShade` modifiers, and the actual RGB lives in `theme1.xml`. A viewer that reads only `w:color/@w:val` renders every themed document in black, which is the single most visible difference between a correct DOCX renderer and an approximate one.

Base stylesheet of the DOCX renderer. Only structural rules live here: the sheet of paper, the page frame, table defaults, and the small amount of chrome the viewer adds. Everything derived from the document itself is emitted as generated classes, so this file never needs to change when format support grows.

Breaks every paragraph of a subtree that can be broken here.

Breaks one paragraph into explicit lines. Returns whether it did. The paragraph must already be laid out: the width it is broken to is the width the browser gave it, which for a cell of an automatically sized table cannot be known any other way.

A profile with every counter at zero, ready to be filled.

Creates the fixed-size container of a page. The dimensions come from the section, not from the content, which is what lets the scrollbar be correct before any page has been mounted.

The boxes text has to flow around, in viewport coordinates. A float narrows the *line boxes* beside it and not the block that holds them, so a paragraph standing next to a picture has the full width of the column and lines that are considerably shorter. Nothing about the paragraph itself says so, which is why the obstacles have to be found from outside and passed in.

Measured heights of the running head and foot, applied to the page box. A header is not confined to the top margin: it starts at the header offset and grows downward, and when it outgrows the margin Word moves the body text down to clear it rather than letting the two overlap.

Quotes a font family name when it needs it, so CSS stays valid.

Renders a single block.

Renders a list of blocks into a container.

Renders inline content into a container. The renderer emits one `<span>` per formatting run rather than per source run: consecutive runs that resolve to the same formatting are merged, which is a large win on documents produced by Word, where a single sentence is routinely split into a dozen runs by spell-check state and revision ids that have no visual effect.

Renders an OMML expression as MathML. MathML is the right target: every current browser renders it natively, it stays selectable and searchable, it scales with the surrounding text, and it needs no external library. The alternative approaches — rasterising equations, or shipping a full TeX layout engine — either lose the text or add megabytes to the bundle for a feature most documents use sparingly. The mapping covers the constructs Word actually produces. Anything unmapped degrades to its concatenated text rather than disappearing, so an unsupported construct still shows its symbols.

Renders a paragraph. Headings are emitted as `h1`..`h6` so the document has real structure for screen readers and for the browser's own outline, rather than a wall of visually-styled `div`s.

Renders a table. Real tables, not a grid of divs: `<table>` gives correct column sizing, cell merging through `rowspan`/`colspan`, and accessible semantics for free, and the browser's table layout algorithm is closer to Word's than anything that could reasonably be reimplemented.

Cuts an element into two at a global text offset. The element is cloned twice and the text on the wrong side of the cut removed from each copy, which preserves the full ancestor chain of every run: a split in the middle of bold text must leave bold text on both pages.

Splits the body into sections. Section properties live on the *last* paragraph of the section they describe, with the final section's properties on the body itself. Reading them as if they applied forwards puts every page setup one section out of place.

Splits a paragraph element so that its first part fits into `availableHeight`. Returns `undefined` when no useful split exists: the element has a single line, or not even one line fits, in which case the caller moves it whole.

Splits a table across a page boundary. Whole rows first, because that is where Word breaks whenever it can. But a row is not an indivisible unit, and treating it as one is not a small simplification: a row taller than the text area can then never be broken, so it goes on one page in its entirety and overflows it. The minutes of a committee — a two-column table whose right column runs for pages — comes out with the whole debate on one sheet and three empty ones after it. Measured on such a document: Word 28, 39, 37, 37, 25 lines per page, ours 16, 2, 100, 37, 2. So a row that cannot fit is divided through its cells, which is what Word does: the cell borders are left open at the boundary and the row continues on the next page. `w:cantSplit` is what forbids it, and the caller checks that.

A section of the document, together with the blocks that belong to it.

Options that control what the renderer produces.

Options controlling pagination.

Where the time of a layout pass went, in milliseconds. Quality has never been the only axis: a rule that gains a page of fidelity and doubles the time is a different answer from one that gains it for free, and until this existed the corpus run could not tell the two apart — it timed the whole run and nothing inside it. The split is the one the pipeline already has. `renderMs` is turning the model into DOM, which is our own code; `paginateMs` less `renderMs` is asking the browser where everything landed, which is the browser's. A change that moves the second without moving the first has changed how much layout we ask for, not how much work we do. Recorded only when asked for, so a reader pays nothing.

Result of laying out a document.

Why one page came out the way it did. The line report can say a page holds the wrong content; it can never say *why*, and the answer is almost always one of a handful of decisions the engine made and then forgot. A page that ends with nine hundred pixels free ended for a reason — a hard break, a section, a column levelling that chose a height — and that reason is the fix. Without it every pagination defect starts with an hour of reconstructing what the engine was thinking. Recorded only when asked for, so a reader pays nothing.

How many paragraphs each path took. Named to match `LayoutProfile`, which is what a run actually passes in: the question "how much of this document did the new path handle" belongs beside the timings, not in a second place a reader has to find.

One laid-out page.

A field whose value depends on the final pagination.

Everything the renderer needs while producing DOM for one document.

The docx renderer plugin for {@link FormatRegistry }.