https://bugs.documentfoundation.org/show_bug.cgi?id=172169
Bug ID: 172169
Summary: Line spacing height calculation unintentionally
changed in LO 7.1 - only uses SwTextPortion now
Product: LibreOffice
Version: 7.1 all versions
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: bisected, regression
Severity: normal
Priority: medium
Component: Writer
Assignee: [email protected]
Reporter: [email protected]
CC: [email protected]
Blocks: 109235
Created attachment 207144
--> https://bugs.documentfoundation.org/attachment.cgi?id=207144&action=edit
69647_linespacingHeight.odt: example document (exaggerated)
See bug 172113 for a general discussion about line spacing.
The way that the height of line spacing is calculated was (apparently
unintentionally) changed to exclude almost everything except simple text, in
LO 7.1 commit d336e6c26012255015d3fc0caf8e7fafe14bd8f2
Author: Daniel Arato (NISZ) on Fri Aug 28 13:13:58 2020 +0200
tdf#69647 sw layout: fix line spacing with inline pictures
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101272
This change was not hidden behind a compatibility flag (as it was considered
the intention of the ODF standard), and it does not (always) match how
Microsoft formats handle this either. Thus it is a regression for both ODF and
MSO formats.
But perhaps this should just be treated as an opportunity to only 'fix' this in
a way that matches how MS Word handles these situations (since it
unintentionally improved this for tabstops, footnotes/endnotes/hidden/ and
perhaps other portions listed in sw/source/core/inc/txttypes.hxx)? Surprisingly
there has not been an outcry against that patch - it really ought to have
triggered many OIT regressions... With such limited feedback, it should be
pretty safe to 'revert' back to the original behaviour for only selected
portions.
Steps to reproduce
1.) open 69647_linespacingHeight.odt in LO
Note that the double-spacing always seems to be based on the 12pt text height,
not on the 60pt footnote number (page 1) or the 60pt page-number-field (page
2), etc. Prior to LO 7.1, the line spacing gap above the line was based on the
60pt height.
2.) On page 1, also change the font of the word 'they' to 60pt. Notice that
(because this word comes before the footnote character) the double spacing gap
increases. (This is how the spacing looked in 7.1) Now undo that change and
instead change the font size of the word 'this' and notice that (because it
comes after the footnote) it doesn't affect the double spacing gap (as long as
the chosen size is less-than-or-equal-to the font size of the earlier footnote
character). Undo. [This is a secondary aspect of this bug report - TextHeight
needs to be changed even if the Height() matches.
3.) round-trip as DOCX, and compare how it looks in LO compared to MS Word.
On page 1 things look the same because MS Word apparently does not use
numbering/footnotes/tab-stops/hidden-text in its line-spacing calculations. [So
this is an interoperability improvement that probably should be retained as
native behaviour.]
Note on page 2 that MS Word uses the height of the field to determine the line
spacing gap below that line.
[For MS Word's exception of bullets/numbering: this bug is irrelevant since
they can only exist on the first line of a paragraph, and LO doesn't use the
first line in any of its line-spacing calculations.]
So my initial impression is that we should bring back InTextGrp() - except for
FieldMark, Drop, InNumberGrp(), Expand/Blank/PostIts, Hidden, Footnote
Referenced Bugs:
https://bugs.documentfoundation.org/show_bug.cgi?id=109235
[Bug 109235] [META] Paragraph line spacing bugs and enhancements
--
You are receiving this mail because:
You are the assignee for the bug.
