Context
Discovered during peer review of #143 ([120.8] regression suite — final sub-PR for #120).
packages/docx-core/SUPPORT.md Table A row for text.ts:replaceParagraphTextRange lists element set w:ins, w:del, w:rPrChange. The current implementation (#136) emits w:ins and w:del correctly but does NOT emit w:rPrChange, even when the replacement runs differ in formatting from the original.
The Group A regression test in #143 asserts the actual current behavior (ins/del only) without checking rPrChange — locking the gap into the test suite as a known limitation.
The gap
replaceParagraphTextRange accepts a ReplacementPart[] argument that can specify addRunProps (bold, italic, color changes). When these differ from the source run's properties, the new content effectively has different formatting than the original. OOXML's tracked-change model would expect a w:rPrChange to record the prior run-property state.
Current behavior:
- Old runs are wrapped in
<w:del> (correct)
- New runs are wrapped in
<w:ins> (correct)
- The fact that the new runs have DIFFERENT
<w:rPr> than the old runs is NOT captured as a property change — it's just an insertion of new-formatted content + deletion of old-formatted content
For pure text replacements with same formatting, this is fine. For formatting-aware replacements (e.g., AI changing bold-text-X to italic-text-Y), the lack of rPrChange means the document's revision history doesn't fully capture the formatting transition.
Proposal
When ReplacementPart.addRunProps is provided AND results in <w:rPr> that differs from the source run's <w:rPr>:
- Emit a
<w:rPrChange> inside each new run's <w:rPr> recording the source run's prior properties.
- Reuse
buildRPrChangeElement from the emitter module.
Acceptance criteria
- New tests in
text.test.ts cover: (a) replacement with same formatting → no rPrChange (current behavior preserved); (b) replacement with different formatting → rPrChange emitted with source run's prior rPr.
- The Group A regression test in
canonical-emission-regression.test.ts is updated to assert rPrChange when applicable.
- SUPPORT.md note for this row is updated to "Verified by [120.8] regression test (after #)".
Related
Context
Discovered during peer review of #143 ([120.8] regression suite — final sub-PR for #120).
packages/docx-core/SUPPORT.mdTable A row fortext.ts:replaceParagraphTextRangelists element setw:ins, w:del, w:rPrChange. The current implementation (#136) emitsw:insandw:delcorrectly but does NOT emitw:rPrChange, even when the replacement runs differ in formatting from the original.The Group A regression test in #143 asserts the actual current behavior (ins/del only) without checking rPrChange — locking the gap into the test suite as a known limitation.
The gap
replaceParagraphTextRangeaccepts aReplacementPart[]argument that can specifyaddRunProps(bold, italic, color changes). When these differ from the source run's properties, the new content effectively has different formatting than the original. OOXML's tracked-change model would expect aw:rPrChangeto record the prior run-property state.Current behavior:
<w:del>(correct)<w:ins>(correct)<w:rPr>than the old runs is NOT captured as a property change — it's just an insertion of new-formatted content + deletion of old-formatted contentFor pure text replacements with same formatting, this is fine. For formatting-aware replacements (e.g., AI changing bold-text-X to italic-text-Y), the lack of rPrChange means the document's revision history doesn't fully capture the formatting transition.
Proposal
When
ReplacementPart.addRunPropsis provided AND results in<w:rPr>that differs from the source run's<w:rPr>:<w:rPrChange>inside each new run's<w:rPr>recording the source run's prior properties.buildRPrChangeElementfrom the emitter module.Acceptance criteria
text.test.tscover: (a) replacement with same formatting → no rPrChange (current behavior preserved); (b) replacement with different formatting → rPrChange emitted with source run's prior rPr.canonical-emission-regression.test.tsis updated to assert rPrChange when applicable.Related