sw/source/core/inc/frame.hxx | 2 ++
sw/source/core/layout/tabfrm.cxx | 12 ++++++++++++
2 files changed, 14 insertions(+)
New commits:
commit 068c133ac41c97652909b88c432e3b73010efc3e
Author: Michael Stahl <michael.st...@cib.de>
AuthorDate: Fri Feb 28 18:39:41 2020 +0100
Commit: Michael Stahl <michael.st...@cib.de>
CommitDate: Mon Mar 2 10:47:04 2020 +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 a97c719aaa78..4a72db8f802b 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 48de92a8dc64..2a957de66933 100644
--- a/sw/source/core/layout/tabfrm.cxx
+++ b/sw/source/core/layout/tabfrm.cxx
@@ -1810,6 +1810,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 )
@@ -2005,6 +2013,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
_______________________________________________
Libreoffice-commits mailing list
libreoffice-comm...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-commits
