fix(super-editor): preserve generated line breaks in DOCX export#3630
fix(super-editor): preserve generated line breaks in DOCX export#3630caio-pizzol wants to merge 1 commit into
Conversation
|
The Status: PASS Here's what I checked and why it holds:
One non-blocking note (not a spec violation): the split path replaces the original If you'd like the schema citations hardened, re-run with the |
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
0a2be53 to
8a8d6f5
Compare
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 8a8d6f5379
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| } else if (part === '\n' && lineBreakNodeType) { | ||
| // `lineBreak` disallows marks (`marks: ''` in its schema); a break carries | ||
| // no run formatting, so create it bare. | ||
| nodes.push(lineBreakNodeType.create()); |
There was a problem hiding this comment.
Count lineBreaks in rewrite diffs
When this helper materializes \n as a lineBreak node, later rewrites over that same content use the executor's diff model, which still calls textBetweenWithTabs(..., '', '') and charOffsetToDocPos without counting lineBreak nodes. For example, rewriting an existing Alpha<lineBreak/>Beta range to the same visible text Alpha\nBeta is not detected as a no-op: the prefix/suffix trim maps both sides of the \n to the position before the existing break and inserts another lineBreak. Please update the text/offset accounting for lineBreak at the same time as creating these nodes.
Useful? React with 👍 / 👎.
Multi-line text passed into text-mode mutations stored newlines as a raw \n inside one <w:t>, which Word collapses on open while SuperDoc renders it as a break. Convert newlines to lineBreak nodes at creation, and split any residual raw newline into <w:t>/<w:br/> within one run on export, so the break serializes as a Word-native <w:br/> (ECMA-376 17.3.3.1). - buildTextWithTabs: normalize \n, \r\n, \r to lineBreak nodes, gated on parent admission for text*-only parents (e.g. total-page-number) - materializeLineBreak: prefer lineBreak over hardBreak so a structural kind:'lineBreak' is a soft break, not a page break - del-translator: rename every <w:t> in a split run to <w:delText> (17.3.3.7 requires delText for all deleted text)
8a8d6f5 to
fa210d4
Compare
Fixes SD-3278.
Generated multiline text could look correct in SuperDoc but export as raw newlines inside
<w:t>, which Word and LibreOffice do not treat as manual line breaks.This change:
\n/\r\n/\rtext into soft line break nodes<w:br/>lineBreakedits as soft breaks, not page breaks<w:delText>when runs are split around breaksFollow-ups are tracked separately for import-side normalization and tracked inserted breaks inside
<w:ins>.