Function reconstruct_preordered 

pub fn reconstruct_preordered(pages: &[Page]) -> Document

Like reconstruct, but for pages whose spans are already in true reading order — one TextSpan per visual line, columns already linearised and inter-word spacing already correct (what kopitiam_pdf::extract_mupdf produces via the ported MuPDF stext engine).

Why a separate entry point (integration choice (a))

reconstruct does its own layout analysis: split_columns re-orders a page into reading-order column groups and group_lines re-groups spans by shared baseline. Both are exactly the work the MuPDF engine has already done — feeding its pre-ordered output back through them risks double processing: split_columns’s midpoint heuristic could re-interleave a layout the boxer already linearised, and baseline re-grouping could merge two already-distinct lines. So this variant trusts the incoming order: it takes each span as one line, in the given sequence, and skips split_columns + baseline re-grouping entirely.

Everything downstream of layout is deliberately kept — heading, list, table, figure, citation, and paragraph detection ([build_blocks]) and the cross-page paragraph merge ([merge_page_breaks]) all run unchanged on the ordered lines. That is the whole point of reusing this pipeline rather than mapping straight to the AST (option (b)): the semantic classifiers are engine-independent and worth keeping.

The one capability lost relative to reconstruct is per-line cell splitting for table detection: with one span per line the line has a single cell, so multi-column table recognition degrades to best-effort. Headings, lists, paragraphs, citations, and cross-page merge are unaffected.