https://bugs.documentfoundation.org/show_bug.cgi?id=174099
Bug ID: 174099
Summary: Justified paragraph ending in NO-BREAK SPACE + space:
last word wraps alone and preceding line is stretched
Product: LibreOffice
Version: 26.2.2.2 release
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: medium
Component: Writer
Assignee: [email protected]
Reporter: [email protected]
Description:
In a justified paragraph whose text ends with U+00A0 followed by one or more
U+0020 (or <text:s/>), the last word moves to a line of its own and the
previous line is justified across the full width. A paragraph ending in U+00A0
alone, or in an ordinary space alone, lays out correctly. The same sequence in
the middle of a paragraph is also fine.
Steps to Reproduce:
1. Open the attached nbsp-trailing-space.odt.
2. Compare the last line of each of the four justified paragraphs. All four
have the same text; they differ only in how they end:
A: NBSP (U+00A0)
B: space + text:s
C: NBSP + space
D: NBSP + text:s
3. Optionally, File > Export as PDF to see the same layout in the output.
Actual Results:
In paragraphs C and D, the last word "occaecat:" (with its trailing NBSP) is
moved onto a line of its own. The line before it is then treated as a full line
and justified across the whole width, so its words are spread far apart.
These paragraphs fit in four lines, like A and B; they are laid out in five.
Expected Results:
C and D lay out exactly like A (ends with NBSP only) and B (ends with space +
text:s): "occaecat:" stays at the end of the fourth line, and the fourth line,
being the last line of the paragraph, is not stretched.
A trailing space after an NBSP at the end of a paragraph should be ignored for
layout, as a trailing space after any other character is.
Reproducible: Always
User Profile Reset: No
Additional Info:
Works: 25.8.1.1, 26.2.1.2
Broken: 26.2.2.2, 26.2.3, 26.8.1.1
Only the end of a justified paragraph (or a line ending in a manual line break)
is affected. NBSP + space in the middle of a paragraph lays out correctly, as
does a paragraph ending in NBSP alone (A) or in a space alone (B).
Bibisected with win64-26.2-2022: the first bad build is source
f28d05f3beb8f57f182150afca06a2395eb55a57, the libreoffice-26-2 backport of
e3c068cb190e6cf04a49f9984f984d5ef72f9d9a ("tdf#167946: reimplement the fix for
tdf#120677"). The previous build, source
d2367dd71f4511c147339b059f23af5829e97195, lays out the attached document
correctly.
Analysis (from reading the code, not yet tested with a build): since that
commit, SwBlankPortion formats via SwTextPortion::Format, so an NBSP goes
through SwTextGuess::Guess. When blanks follow the NBSP up to the paragraph
end, maybeAdjustPositionsForBlockAdjust() asks for a trailing SwHolePortion by
returning false. SwTextPortion::Format_ (case B2) only creates that hole, and
resets bFull, when !InExpGrp(), and PortionType::Blank is in the EXP group. So
the NBSP portion stays "full", and SwBlankPortion::Format triggers an underflow
that moves the preceding word to the next line.
Consistent with this: a left-aligned paragraph ending in NBSP + space lays out
correctly, but breaks the same way once Tools > Options > Writer >
Compatibility > "Word-compatible trailing blanks" is enabled, since that option
makes maybeAdjustPositionsForBlockAdjust() take the same path for non-justified
text.
A possible fix is to exempt blank portions at the two
maybeAdjustPositionsForBlockAdjust() call sites in SwTextGuess::Guess, as field
portions already are (rPor.InFieldGrp() || rPor.IsBlankPortion() || ...). I
intend to submit this to Gerrit with a unit test.
--
You are receiving this mail because:
You are the assignee for the bug.
