Render-fidelity round: package tolerance, section defaults, style provenance, and Word-Compare input-revision policy

[JSv4]

Comparing real-world documents surfaced a cluster of fidelity gaps against what Word's own
Compare produces — outright failures on Word-tolerated broken packages, dropped page setup,
leaked template defaults, and an input-revision policy that turned out to model Word's
Combine rather than its Compare. Each fix below was decoded from Word's observed output
for the shape in question, implemented test-first with a synthetic reproducer, and gated on
the full suite (4,247 passing).

Word-tolerated broken packages no longer abort the compare

A package can declare a relationship whose target part is missing from the ZIP (an orphaned
docProps/thumbnail.jpeg reference is the wild-caught case). Word opens such a document and
silently drops the dangling reference on save; the Open XML SDK instead throws from its eager
part-tree load, so the compare failed outright — and surfaced as an empty result through the
WASM bridge, which swallows engine exceptions. OpenXmlMemoryStreamDocument now removes
dangling internal relationships (package- and part-level) before handing the package to the
SDK. Relationships whose target URI cannot even be resolved are left alone so stranger
breakage keeps its existing diagnostics.

A one-sided trailing w:sectPr diffs against the default section

A body with no trailing section properties reads as the default section — Word's rule.
Previously, when only the revised side had one, its page setup was dropped entirely (a
two-column revision rendered single-column); when only the original had one, the original's
page setup survived accept. Now a right-only sectPr is adopted (properties only —
header/footer references belong to the header/footer machinery) under a w:sectPrChange
archiving the default section, and a left-only sectPr is replaced by the default section with
the left's properties archived. Accept reproduces the revised page setup; reject restores the
original's.

Identical Strict OOXML inputs return a transitional package

Strict inputs were already normalized to transitional before any diff (Word converts on
open), but the identical-package shortcut returned the input bytes untouched — a strict
package that LibreOffice renders poorly and python-docx refuses to open. Both shortcut
sites now normalize a strict left on the way out; byte-identical transitional inputs still
return an exact detached clone.

Document-default deltas are stated on the updated style, both ways

The compare output keeps the original package's docDefaults, so an updated shared style
must state the revised side's effective formatting explicitly. That held only for properties
the revised side declared. Two mirror-image leaks are closed:

• A property the original's docDefaults declare and the revised side leaves at its built-in
  default (paragraph spacing, kerning, ligatures) kept ruling the output through the retained
  part — an original template with spacing after=160 line=278 rendered every revised
  paragraph double-spaced. The style's current payload now materializes the built-in default
  for exactly those properties (w:spacing 0/240/auto attribute-wise, w:kern 0,
  w14:ligatures none), which is what Word writes there.
• Conversely, a property the revised side declares in its docDefaults and the original
  lacks is now materialized into the style's current payload — a revised template with
  declared spacing rendered single-spaced before.

A style-less original adopts the revised document's style definitions

When the original has no styles part at all, the output carried no style definitions either,
so inserted content that styles itself through pStyle (bullet lists, header/footer stories)
lost its formatting. Word's output for this shape carries every style definition from the
revised document unchanged while document defaults remain the stock backfill; with no
original definitions there is nothing to collide with or preserve, so the wholesale copy is
adopted.

The engine selector models Word's Compare input-revision policy

Word's Compare treats tracked changes already present in either input as accepted — its own
dialog says so — and its outputs confirm it: text an input had struck through is absent from
the result entirely, the surviving delta is re-detected under the compare author, and the
output carries a single revision author. The selector profile (DocxCompare.Compare, and
with it compareDocuments on npm, the redline CLI, and the MCP compare tools) instead
carried the inputs' own markup through under the original authors — Word's Combine
behavior; the oracle outputs the old behavior was verified against turned out to be
Combine-shaped. The pre-accept flatten now runs on the selector path, and preservation stays
an explicit opt-in on the raw DocxDiff API (DocxDiffSettings.PreserveInputRevisions).
Callers passing revision-free documents see no change. The diff-engine architecture doc is
corrected accordingly.

A materialized concrete font clears the theme reference it overrides

Effective-formatting resolution merged rFonts attribute-wise across style layers, so
materializing ascii="Times New Roman" from the revised side could leave a lower layer's
asciiTheme riding along — and in OOXML a theme attribute outranks the literal in the same
slot, so the output still rendered the theme font. Substituted (the theme font is rarely
installed where the output renders), that put body text in a different-metric family and
repaginated whole documents: one running-header fixture family rendered 20 pages against
Word's 15 from this alone. Each rFonts slot now overrides as a pair — a layer declaring the
concrete attribute clears the theme attribute from the accumulation, and vice versa — which
is the concrete-only payload Word writes.

An experiment that instead removed the document-defaults projection's consumer gates was
measured and reverted: it projected deltas onto dozens of documents whose Word outputs carry
an EMPTY updated style, so those gates encode observed Word behavior, and the code comment
now says so.

The output fontTable is the union of both inputs' declarations

A font only the revised document's fontTable declares (a Word alias like
"Times New Roman (Body CS)" matches no installed face) was missing from the left-based
output's table, leaving LibreOffice no substitution hint for revised-sourced content naming
it — it fell back to a different-metric family. Word's compare output carries the union, so
right-only declarations are now appended verbatim, minus embedded-font relationship children
whose ids belong to the other package.

Validation

• Every fix landed test-first: 13 new tests across five files, each watched failing before
  the code change, plus two deliberate re-pins where the old behavior was itself the bug
  (strict self-compare byte-preservation; the selector's preserve pin).
• Full suite: 4,247 passed / 0 failed / 3 skipped.
• Rendering the affected document shapes through LibreOffice confirms the intended effect in
  every case: the two-column adoption, the spacing materializations, and the style adoption
  each reproduce Word's own compare output for the same inputs where they previously
  diverged; accept/reject round-trips hold at the property level.