diff options
author | Michael Stahl <michael.stahl@allotropia.de> | 2023-02-07 20:22:25 +0100 |
---|---|---|
committer | Michael Stahl <michael.stahl@allotropia.de> | 2023-02-08 11:03:36 +0000 |
commit | a0875d09d9eeb368e9e319f3f2f29ec3be71b56c (patch) | |
tree | 179c3f2e27c16226e166d25abf679672dcbe348f /codemaker | |
parent | 9bf7092aa05b47e6290d894edaf00f21038a636a (diff) |
editeng: remove SvxLRSpaceItem::nTxtLeft
Several parts of SvxLRSpaceItem appear to maintain an invariant of the
3 members nTxtLeft/nLeftMargin/nFirstLineOffset: nLeftMargin is either
equal to nTxtLeft if nFirstLineOffset is positive, otherwise equal to
nTxtLeft + nFirstLineOffset.
But not every part maintains it: there are functions SetLeftValue() and
SetLeft() which simply write into nLeftMargin regardless, and a
constructor that takes 3 separate numbers without any checks.
The constructor calls violate the invariant in 2 ways: nTxtLeft is
simply set to 0 (many cases), and one case in OutlineView::OutlineView()
that sets nTxtLeft to 2000 but the other 2 at 0.
Another odd thing is that the UNO services that expose SvxLRSpaceItem
either expose a property for MID_L_MARGIN or for MID_TXT_LMARGIN but
never both.
It looks like there are 2 distinct usages of SvxLRSpaceItem:
for anything that's applied to paragraphs, all 3 members are used;
for anything else, nTxtLeft is unused.
Try to simplify this by removing the nTxtLeft member, instead
GetTextLeft() simply calculates it.
Also assert in SetLeftValue()/SetLeft() that nFirstLineOffset is 0.
Change-Id: Ida900c6ff04ef78e92e8914beda1cc731a695b06
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146643
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
Diffstat (limited to 'codemaker')
0 files changed, 0 insertions, 0 deletions