fix(doc): preserve symbol checkbox states

[HanZephyr]

Legacy DOC checkbox symbols stored as U+0028 plus sprmCSymbol currently become indistinguishable opening parentheses. Resolve the symbol font through SttbfFfn and emit Unicode unchecked/checked boxes for the supported Wingdings and Wingdings 2 glyphs. Character-run properties are applied before piece properties; unknown fonts or glyphs preserve the source character.

Eight synthetic in-memory DOC tests cover both fonts, private-use codes, ordinary Unicode/text, piece overrides, and malformed font tables. No application documents are included.

Validation: cargo fmt --all --check; workspace/all-target/all-feature Clippy; cargo test --locked (301 passed at initial run, plus the expanded 8-test symbol suite); Node build and 19 tests; Python wheel build and 11 tests; Wasm Clippy/build and 8 tests.

Format references: MS-DOC character properties, SttbfFfn.

---

Summary by cubic

Fixes legacy DOC symbol checkboxes so they no longer convert to plain parentheses. The converter now resolves the symbol font through SttbfFfn and emits Unicode □/☑ for supported Wingdings/Wingdings 2 glyphs; unsupported fonts or glyphs keep the original character.

Details

• Piece symbol properties override character-run symbol properties.
• Malformed or missing font tables fall back to the source text.
• Synthetic DOC tests cover both fonts, private-use codes, overrides, and malformed tables.

^{Written for commit 6b6bd43. Summary will update on new commits.}

[cubic-dev-ai]

1 issue found across 3 files

Confidence score: 3/5

• src/formats/doc/mod.rs: the symbol_at path skips symbols inherited from the active STSH or character style, leaving U+0028 unchanged and potentially producing incorrect document characters; resolve the style-chain symbol before applying CHPX and piece processing.

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="src/formats/doc/mod.rs">

<violation number="1" location="src/formats/doc/mod.rs:799">
P2: When `sprmCSymbol` comes from the active STSH or character style, this branch leaves `U+0028` unchanged because `symbol_at` skips the style-chain symbol. Resolve the style-chain symbol before applying CHPX and piece properties.</violation>
</file>

<sub>Heads up: you’re close to your flex budget. Increase your flex budget so reviews don’t pause.

Fix all with cubic | Re-trigger cubic</sub>

[cubic-dev-ai]

P2: When sprmCSymbol comes from the active STSH or character style, this branch leaves U+0028 unchanged because symbol_at skips the style-chain symbol. Resolve the style-chain symbol before applying CHPX and piece properties.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At src/formats/doc/mod.rs, line 799:

<comment>When `sprmCSymbol` comes from the active STSH or character style, this branch leaves `U+0028` unchanged because `symbol_at` skips the style-chain symbol. Resolve the style-chain symbol before applying CHPX and piece properties.</comment>

<file context>
@@ -793,6 +796,7 @@ impl Assembler {
                 c if c.is_control() => {}
                 c => {
                     let style = self.char_style(fc, i);
+                    let c = if c == '(' { self.symbol_at(fc, i).unwrap_or(c) } else { c };
                     para.push_char(c, style);
                 }
</file context>

[HanZephyr]

Thanks for reviewing. I checked this against MS-DOC: section 2.9.336 prohibits UpxChpx from containing properties that are preserved across sprmCIstd. Section 2.6.1 explicitly includes the symbol state, font, and character code (sprmCSymbol) among those preserved properties. Therefore, a conforming paragraph or character style cannot define sprmCSymbol, and resolving it from CHPX followed by piece properties is intentional.

References:

• UpxChpx: https://learn.microsoft.com/en-us/openspecs/office_file_formats/ms-doc/0188ecda-b590-4cb4-bb95-e76a47a9a2e2
• Character Properties (sprmCIstd): https://learn.microsoft.com/en-us/openspecs/office_file_formats/ms-doc/7022285b-9621-42e9-ad4d-4e02c115ef18

Supporting a malformed document that places this property in a style would be a separate compatibility extension, rather than a missing step for conforming DOC files. I am leaving the implementation unchanged for this finding.