fix(style-engine): resolve bold and italic from the complex-script toggles

[Nathaniel-260]

The bug

Hebrew and Arabic Word writes bold-for-complex-script as w:bCs alone whenever the
styled selection is single-script — no w:b alongside it. Word renders such a run
bold. SuperDoc reads only w:b, so a document whose headings are bold in Word is
painted at normal weight.

This is the shape of a real reported document (a Hebrew Torah-study text). Its
heading 2–heading 5 styles are:

<w:style w:type="paragraph" w:styleId="2">
  <w:name w:val="heading 2"/>
  <w:rPr>
    <w:rFonts w:ascii="FrankRuehl DP" w:hAnsi="FrankRuehl DP" w:cs="FrankRuehl DP"/>
    <w:bCs/>                      <!-- no <w:b/> -->
    <w:szCs w:val="28"/>
  </w:rPr>
</w:style>

and its runs carry <w:rtl/>.

Reproduce

Any Hebrew .docx whose headings were bolded in Word will do; the smallest recipe:

1. In Word, type a Hebrew line, apply Heading 2, and press Ctrl+B while the
   selection is Hebrew only. Word writes <w:bCs/> into the style with no <w:b/>.
2. Open the file in SuperDoc.

Word shows the heading bold; SuperDoc shows it at normal weight.

Measurement

Chrome, packaged dist, getComputedStyle on the run element inside .superdoc-line:

	font-weight
the reported document, as-is	400 on all ten headings
the same document, <w:b/> completed next to each <w:bCs/>	700 on all ten
the same document, unchanged, with this patch applied to the compiled bundle and nothing else	700 on all ten

The change

normalizeRunAttrsFromOoxml is the seam. It already receives the full
RunProperties — boldCs, iCs, cs, rtl — and everything downstream carries a
single bold, so the formatting stack has to be selected here.

Per ECMA-376 Annex I, w:rPr/w:rtl (§17.3.2.30) and w:rPr/w:cs (§17.3.2.7) each
select the complex-script variants of the character-formatting toggles. That is the
stack selection contracts/src/direction-context.ts already describes:

This context is preservation-only in Wave 1a. Wave 1b implements the
stack-selection logic (resolveRunScriptContext returns whether to render with the
CS or Latin stack).

resolveRunScriptContext does not exist yet; this covers the two toggles.

Why the Latin toggle stays a fallback

Word decides the stack per character, not per run. A run carrying only w:b is bold
there for whatever Latin text it holds, and plenty of existing documents carry w:b
alone on right-to-left runs — SuperDoc's own format.apply writes them that way.
Reading w:bCs strictly would turn those runs normal: a regression in the opposite
direction, and a wider one. Per-character parity needs the run text next to the
properties, which this layer does not receive.

Known limit

A run whose Hebrew is implied only by its text, with neither w:rtl nor w:cs set,
still resolves through the Latin toggles. Measured: such a run stays at 400 with this
patch. Word picks the stack from the Unicode script of the text in that case, which
needs information this layer does not have.

Out of scope, deliberately

w:szCs and w:rFonts/@cs are the other two members of the same stack. Both change
size and font resolution for every right-to-left run — a much larger behavioural
change than the toggles, and one that deserves its own measurement.

Tests

Four cases added to normalize.test.ts: the CS toggles on a w:rtl run and on a
w:cs run, the Latin toggles kept when no complex-script signal is present, and the
fallback on a complex-script run with no CS variant.

What I ran locally (Windows, Node 22, Bun 1.3.13):

• bun test in style-engine — 182 pass
• bun test in layout-engine (964), word-layout (172), common (121),
  geometry-utils (7) — all pass
• vp fmt --check on both changed files — clean

Not run: the full pnpm test. pnpm will not start in my checkout, and
bun test in document-api panics with integer overflow — it does the same on an
unmodified tree here, so it is environmental and unrelated to this change.

---

Fixes #3959.

[qodo-code-review]

Qodo reviews are paused for this user.

Troubleshooting steps vary by plan Learn more →

On a Teams plan?
Reviews resume once this user has a paid seat and their Git account is linked in Qodo.
Link Git account →

Using GitHub Enterprise Server, GitLab Self-Managed, or Bitbucket Data Center?
These require an Enterprise plan - Contact us
Contact us →

[cubic-dev-ai]

No issues found across 2 files

_{Re-trigger cubic}