fix(layout): paint the Word 97-2003 run effects and the double strike

[Nathaniel-260]

The bug

The Font dialog's Effects group in Word writes four run flags — w:outline,
w:shadow, w:emboss, w:imprint — and Word still honours all four. They
predate the w14: effect family, so a document can carry them with no w14:
counterpart anywhere.

SuperDoc imports them, keeps them, and exports them correctly. It never paints
them. Applying one to a selection writes the file and leaves the page identical.

w:dstrike is the same seam from the other side. normalizeRunAttrsFromOoxml
already emits doubleStrike and it reaches the painter — the painter simply
never reads it, so a double strikethrough is drawn as a single line.

Reproduce

1. Open any .docx in SuperDoc.
2. Select a word and apply format.apply({ target, inline: { outline: true } })
   (or shadow / emboss / imprint / dstrike).
3. Export the document: the flag is there, canonical.
4. Look at the page: nothing changed. For dstrike, a single line.

Or in Word: type a word, Font → Effects → Outline, save, open in SuperDoc.

Measurement

Chrome, packaged dist, one effect per run so each pixel is attributable, with
getComputedStyle on the .superdoc-text-run element and a byte-compare of
a PNG clip of the line before and after:

applied	in the exported document.xml	painted, before	painted, with this patch
outline	<w:outline/>	nothing — PNG identical, 768/768 bytes	hairline stroke, fill emptied
shadow	<w:shadow/>	nothing — PNG identical	text-shadow, one offset copy
emboss	<w:emboss/>	nothing — PNG identical	light edge up-left, dark down-right
imprint	<w:imprint/>	nothing — PNG identical	the mirror of emboss
dstrike	<w:dstrike/>	line-through solid	line-through double

The four flags never reached paint at all. Dumping the keys of the TextRun the
painter receives, on a run carrying each flag, gave:

outline / shadow / emboss / imprint →  kind|text|fontFamily|fontSize|color|script|pmStart|pmEnd
dstrike                             →  kind|text|fontFamily|fontSize|strike|doubleStrike|color|script|pmStart|pmEnd

So dstrike was a painter-only gap, and the other four were dropped one layer
earlier, in the normalizer. Both halves are in this patch, and the same dump with
the patch applied shows outline / shadow / emboss / imprint on the run
alongside doubleStrike.

The change

style-engine/normalize/run-attrs.ts passes the four flags through as
authored, including an explicit false — <w:shadow w:val="0"/> is how Word
clears an inherited effect, and dropping the key would let a lower cascade layer
switch it back on. This mirrors the vanish / specVanish lines directly below.

contracts carries them on RunMarks, next to strike, so every run kind
that supports inline formatting has them.

painters/dom/runs/text-run.ts draws them in a small applyLegacyRunEffects,
called after applyTextEffects so it can see what an authored w14: effect
already wrote:

• it stands aside when the run carries a w14:textOutline that actually
  painted a stroke, or a w14:textFill, rather than relying on declaration
  order — order would have left its empty fill behind on a run whose
  w14:textOutline has no fill of its own, turning an authored outline into a
  hollow glyph. The test is what was written, not whether the object exists:
  <w14:textOutline w14:w="0"><w14:noFill/></w14:textOutline> — what Word
  writes for "no outline" — is a present object that paints nothing, and
  standing aside for it would leave the run blank;
• it stands aside for a w14:shadow in the same way, since that is the authored
  form of the same drop shadow — while emboss and imprint, which have no w14:
  counterpart and are not drop shadows, keep composing;
• and it appends its shading to any existing text-shadow instead of
  assigning over it, because w14:glow is a different effect from an embossed
  edge and the two compose as two shadow layers — assigning would let a glow
  silently erase an emboss on the same run.

The outline empties the glyph through -webkit-text-fill-color, not color.
The stroke is currentColor, and currentColor resolves against the element's
own color; clearing color takes the stroke down with the fill, and a run
carrying <w:outline/> with Automatic color — exactly what the Font dialog
writes — would paint nothing at all. normalizeRunAttrsFromOoxml deliberately
reports Automatic as no color, so that is the default path, not an edge case.

doubleStrike draws its own line. It is a separate RunMarks field and a
separately settable run attribute, so a run carrying only w:dstrike still has a
strikethrough; reading the line off strike alone would render it undecorated.
render-line.ts re-derives the decoration on the two paths that lift an underline
onto a line overlay, so that rule now lives in one shared helper rather than in
three places that had already drifted.

The outline also fixes the formatting marks it would otherwise empty.
-webkit-text-fill-color is inherited and beats a child's own color, so the
· and → marks rendered inside an outlined run would have come out as hairline
rings. Both ::after rules opt back out — they are chrome, not document text.

Five signatures gate paint reuse, and all five count the new flags —
textRunMergeSignature, hashRunVisualMarks, deriveBlockVersion,
deriveParagraphBlockVersion and hashParagraphBlockForTableVersion. Without them an edit that flips only <w:emboss/>
leaves the already-painted span on screen — the same "the file changed and the
page did not" symptom, one layer up — and two adjacent runs differing only in one
flag merge into a single span, painting one run's effect over the other's text.

On fidelity, stated rather than hidden

• outline is faithful — a hairline stroke with the fill removed is what Word
  draws. Stroke weight scales with font size, with a floor so it does not round
  away on a low-density screen.
• shadow is a hard-edged offset copy, as in Word. The blur Word applies at
  large display sizes is not reproduced.
• emboss / imprint keep the authored glyph color and add a light edge on one
  side and a dark edge on the other; the direction is what separates the two.
  Word instead paints the glyph itself near the page color and lets the edges
  carry the shape. Doing that in paint needs the resolved page background, which
  the painter does not have — and guessing it wrong turns the text invisible.
  That is the one place this trades the last of the fidelity for legibility, and
  the reasoning is in the source rather than only here.

This is the same trade applyTextEffects already makes for w14:glow, which it
approximates with concentric zero-offset shadows.

One CSS constraint

text-decoration-style is a single value for the whole decoration set, so a run
that is both underlined and double-struck can keep only one of the two styles.
The underline already claimed it, and it claimed it from an authored value
(w:u/@w:val) while w:dstrike has no style to lose — so the underline keeps
its style and the strike stays single. A visible shortfall on a rare combination,
rather than a wrong underline on a common one.

Deliberately not in scope

w:kern is measured as written-but-not-drawn in the same dialog — the painter
sets font-kerning: none unconditionally and nothing opts a run back in. It is
left out on purpose: kerning changes glyph advance widths, so it is a
measurement change, not a paint-only one, and it belongs with the layout path
rather than in this patch.

Tests

Added, and each was watched fail before it passed — the fix was disabled in place
and the suites re-run:

• painters/dom, 18 new cases: the hollow outline; an outlined run with no
  explicit color staying visible (the case that goes blank if the fill is
  cleared through color); the single offset shadow; emboss vs imprint differing
  by side; both scaling with font size; standing aside for w14:textOutline;
  standing aside for w14:textFill; standing aside for w14:shadow; composing with w14:glow; the double strike;
  a run carrying only doubleStrike; the underline keeping its style against
  a double strike; no effect painting nothing; and the merge signature changing
  for each of the five flags. With the painter pass disabled, 5 go red; with the
  fill cleared through color again, 2 go red; with the ordering reverted, 1 goes
  red; with doubleStrike dropped from the decoration test, 1 goes red.
• layout-bridge, 2 new cases on hashRunVisualMarks: a different hash for
  each flag, and the flags distinguished from one another. Both go red when the
  five lines are removed from the hash.
• style-engine, 3 new cases: the flags carried through, an explicit false
  preserved, and absence staying absent. With the four normalizer lines removed,
  2 go red.

packages/layout-engine/painters/dom + layout-bridge + layout-resolved + contracts
                                       4215 passed  (190 files)
packages/layout-engine/style-engine    181 passed   (bun test, whole package)
tsc -b tsconfig.references.json        clean
vp lint / vp fmt --check               no new findings

A note on how this was reviewed: three independent review passes were run over
the change across two rounds. They found eleven real defects, including two that
an earlier revision of this patch introduced — the invisible default-color
outline and the missed invalidation signatures. All are fixed here, each with a
test that was watched go red first.

[cubic-dev-ai]

All reported issues were addressed across 7 files

<sub>Reply with feedback, questions, or to request a fix.

Re-trigger cubic</sub>

[cubic-dev-ai]

All reported issues were addressed across 6 files (changes from recent commits).

<sub>Reply with feedback, questions, or to request a fix.

Re-trigger cubic</sub>