sw/source/core/inc/frame.hxx | 2 ++
sw/source/core/layout/tabfrm.cxx | 12 ++++++++++++
2 files changed, 14 insertions(+)
New commits:
commit 1b2ac1f4171ecc359fce50ccfb81e65b787cea91
Author: Michael Stahl <michael.st...@cib.de>
AuthorDate: Fri Feb 28 18:39:41 2020 +0100
Commit: Gabor Kelemen <kelem...@ubuntu.com>
CommitDate: Thu Jan 13 13:51:48 2022 +0100
sw: layout: fix wrongly positioned table rows in --convert-to pdf
If the document is loaded via UI, the first layout action is triggered
from resizing the Window and the table is positioned properly on the
first try.
If the document is loaded via --convert-to, only getRendererCount()
formats the content of the table, and the table is positioned 3 times
but its first row is only positioned 2 times.
The first time the table id="56" is positioned, the previous table
id="50" is at correct Y 5988 but its content isn't formatted yet, so its
height is almost 0 (just table's border etc.), so the table ends up at
y = 6271.
The second time the table id="56" is positioned, the previous table
id="50" is at wrong Y 7937 and its content is valid, so its height
is 1203, so the table ends up at y = 9140.
The third time the table id="56" is positioned, the previous table
id="50" is at correct Y 5988 and its content is valid, so its height
is 1203, so the table ends up at correct y = 7191 ... but the first
SwRowFrame remains at y = 9140 and is never repositioned, and the lower
rows are cut off (invisible).
Change SwTabFrame::MakeAll() so that a MakePos() that moves the table
itself does not leave the first SwRowFrame's position valid, which
should ensure that all rows are repositioned.
(And work around C++'s particularly unhelpful type system.)
This happens since the earliest version checked, OOo 3.3.
Change-Id: If3dfe1ffcb81e03aa4f4bffcf33a237f0c92bd08
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89735
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.st...@cib.de>
diff --git a/sw/source/core/inc/frame.hxx b/sw/source/core/inc/frame.hxx
index ae5e8378ee4b..b85ea2b7a36f 100644
--- a/sw/source/core/inc/frame.hxx
+++ b/sw/source/core/inc/frame.hxx
@@ -130,6 +130,8 @@ namespace drawinglayer { namespace attribute {
class SAL_DLLPUBLIC_RTTI SwFrameAreaDefinition
{
private:
+ friend void FriendHackInvalidateRowFrame(SwFrameAreaDefinition &);
+
// The absolute position and size of the SwFrame in the document.
// This values are set by the layouter implementations
SwRect maFrameArea;
diff --git a/sw/source/core/layout/tabfrm.cxx b/sw/source/core/layout/tabfrm.cxx
index 060d5151e3bc..ddee61fceb1c 100644
--- a/sw/source/core/layout/tabfrm.cxx
+++ b/sw/source/core/layout/tabfrm.cxx
@@ -1808,6 +1808,14 @@ namespace {
return bRet;
}
}
+
+// extern because static can't be friend
+void FriendHackInvalidateRowFrame(SwFrameAreaDefinition & rRowFrame)
+{
+ // hilariously static_cast<SwTabFrame*>(GetLower()) would not require
friend declaration, but it's UB...
+ rRowFrame.setFrameAreaPositionValid(false);
+}
+
void SwTabFrame::MakeAll(vcl::RenderContext* pRenderContext)
{
if ( IsJoinLocked() || StackHack::IsLocked() || StackHack::Count() > 50 )
@@ -2003,6 +2011,10 @@ void SwTabFrame::MakeAll(vcl::RenderContext*
pRenderContext)
{
m_bCalcLowers = true;
}
+ if (GetLower())
+ { // it's possible that the rows already have valid pos - but it
is surely wrong if the table's pos changed!
+ FriendHackInvalidateRowFrame(*GetLower());
+ }
}
//We need to know the height of the first row, because the master needs
