@eigenpal/docx-editor-core/editor

Run the pure layout compute pass (the 6 steps in this file's header), lifted verbatim from `useLayoutPipeline`. The adapter performs the DOM paint (`renderPages`), scroll-restore, `painter:painted`, and state writeback with the returned values.

declare function computeLayout(inputs: ComputeLayoutInputs): LayoutComputation;

declare function createLayoutScheduler(run: (state: EditorState) => void, scheduleFrame?: (cb: () => void) => number, cancelFrame?: (handle: number) => void): LayoutScheduler;

Clear the scroll-into-view flag on `transaction` in place. Call inside `dispatchTransaction` before `state.apply(transaction)`. `probeTr` should be a fresh `view.state.tr` used only for the one-shot drift canary (so the real transaction is never mutated by the probe).

declare function stripScrollFlag(transaction: Transaction, probeTr: Transaction): void;

interface ComputeLayoutInputs

interface LayoutComputation

rAF-coalescing layout scheduler shared by the React and Vue adapters (issue #696 Tier 2). Rapid doc-changing transactions (a burst of keystrokes) collapse to a single layout pass per animation frame: while a frame is pending, later `schedule` calls just replace the target state, so only the final state lays out.

`scheduleFrame`/`cancelFrame` are injected so a headless/test host can pass a synchronous stub; they default to requestAnimationFrame.

interface LayoutScheduler

Adapter-supplied block measurer (React's is caching).

type MeasureBlocksFn = (blocks: FlowBlock[], contentWidth: number | number[], pageGeometry?: FloatPageGeometry) => Measure[];