Summary
A single trailing space immediately before <w:br/> produces a spurious empty line in the rendered output, when that space happens to land at the line-wrap boundary. Word renders the same paragraph without the empty line.
The two files in the repro below differ by exactly one character — that space — and render differently in SuperDoc but identically in Word.
Versions
superdoc 2.10.0 (@superdoc/docx-engine 0.9.0) — reproducessuperdoc 2.8.0 (@superdoc/docx-engine 0.7.0) — reproduces- Chromium 141, headless and headed,
ui: false
Repro
Take any stock Word document and replace the body with:
<w:p>
<w:pPr><w:jc w:val="both"/></w:pPr>
<w:r><w:t xml:space="preserve">P10 abc abc abc abc abc dddddddddd </w:t></w:r>
<w:r><w:br/></w:r>
<w:r><w:t xml:space="preserve">AFTER the break</w:t></w:r>
</w:p>
<w:p><w:pPr>
<w:sectPr>
<w:type w:val="continuous"/>
<w:pgSz w:w="11906" w:h="16838"/>
<w:pgMar w:top="1440" w:right="1440" w:bottom="1440" w:left="1440"
w:header="708" w:footer="708" w:gutter="0"/>
<w:cols w:num="2" w:space="708"/>
<w:docGrid w:linePitch="360"/>
</w:sectPr>
</w:pPr></w:p>Note the trailing space in dddddddddd . The two columns matter only because they make the measure narrow enough for that space to reach the wrap boundary; see "Width dependence" below.
Actual
Three .superdoc-line elements, the middle one empty:
top=290 h=23 "P10 abc abc abc abc abc dddddddddd"
top=313 h=23 "" <-- spurious
top=335 h=23 "AFTER the break"
Delete the one trailing space and the empty line disappears:
top=290 h=23 "P10 abc abc abc abc abc dddddddddd"
top=313 h=23 "AFTER the break"
Expected
Two lines in both cases. Word lays out both files identically — measured through the Word object model, vertical position of each rendered line:
one-space 72.00pt 'P10 abc abc abc abc abc dddddddddd <BR>'
89.25pt 'AFTER the break'
one-nospace 72.00pt 'P10 abc abc abc abc abc dddddddddd<BR>'
89.25pt 'AFTER the break'
A space at the end of a line is not measured — it is collapsed at the line end. A space immediately before <w:br/> is always at a line end by definition, so it should never be able to force a wrap.
Width dependence
The bug only shows when the trailing space lands within roughly one space-width of the measure. To confirm this rather than guess, I generated 40 paragraphs identical except for the length of the pre-break text, growing one character at a time, in one document:
- with the trailing space: 3 of 40 paragraphs rendered an extra empty line (the three whose text ends nearest the column edge)
- without it: 0 of 40
So it is not specific to any one string — it is whichever paragraph happens to end near the boundary. That is what makes it hard to spot: in a real document it looks random.
Not RTL-specific
First found in a Hebrew RTL two-column document, but it reproduces with w:bidi and w:rtlGutter stripped and with plain English text, exactly as shown above.
Impact
In a two-column Hebrew document this fires on ordinary text — manual line breaks are common, and a trailing space before them is what Word itself leaves behind when a user edits. The result is stray blank lines scattered through the document that are not in the file and do not appear in Word.
Unrelated to #3944, which is a different document-level failure in the same layout path.
Summary
A single trailing space immediately before
<w:br/>produces a spurious empty line in the rendered output, when that space happens to land at the line-wrap boundary. Word renders the same paragraph without the empty line.The two files in the repro below differ by exactly one character — that space — and render differently in SuperDoc but identically in Word.
Versions
superdoc2.10.0 (@superdoc/docx-engine0.9.0) — reproducessuperdoc2.8.0 (@superdoc/docx-engine0.7.0) — reproducesui: falseRepro
Take any stock Word document and replace the body with:
Note the trailing space in
dddddddddd. The two columns matter only because they make the measure narrow enough for that space to reach the wrap boundary; see "Width dependence" below.Actual
Three
.superdoc-lineelements, the middle one empty:Delete the one trailing space and the empty line disappears:
Expected
Two lines in both cases. Word lays out both files identically — measured through the Word object model, vertical position of each rendered line:
A space at the end of a line is not measured — it is collapsed at the line end. A space immediately before
<w:br/>is always at a line end by definition, so it should never be able to force a wrap.Width dependence
The bug only shows when the trailing space lands within roughly one space-width of the measure. To confirm this rather than guess, I generated 40 paragraphs identical except for the length of the pre-break text, growing one character at a time, in one document:
So it is not specific to any one string — it is whichever paragraph happens to end near the boundary. That is what makes it hard to spot: in a real document it looks random.
Not RTL-specific
First found in a Hebrew RTL two-column document, but it reproduces with
w:bidiandw:rtlGutterstripped and with plain English text, exactly as shown above.Impact
In a two-column Hebrew document this fires on ordinary text — manual line breaks are common, and a trailing space before them is what Word itself leaves behind when a user edits. The result is stray blank lines scattered through the document that are not in the file and do not appear in Word.
Unrelated to #3944, which is a different document-level failure in the same layout path.