Related: tdf#156318 sw floattable: fix handling of vert orient == top

The bugdoc resulted in a layout loop on load. It was created by forcing
pages to be in a single column + increasing the top+bottom margin of the
page to 2.5cm.

The problem was that the SwFormatVertOrient's m_eOrient is usually
text::VertOrientation::NONE ("from top" with 0 offset), but here it's
text::VertOrientation::TOP. These are meant to be more or less
equivalent, but SwToContentAnchoredObjectPosition::CalcPosition() has
different codepath for them.

Fix the problem by making sure that TOP doesn't have a vertical offset
for follow fly frame: do this by realizing that in case the "orient
frame" and the "anchor" is not the same that may need no action, since
the fly frame case changes the "orient" to the follow anchor and the
"anchor" is the master anchor.

The original scenario still needs more work, we don't hang anymore but
the follow fly appears on page 3 instead of page 2.

Change-Id: I1596a07b78575583070d494ddb8e1400e5653820
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156392
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins

1 files changed, 2 insertions, 0 deletions

diff --git a/sw/source/core/inc/frame.hxx b/sw/source/core/inc/frame.hxx
index d405da36515b..d57654f6a9e7 100644
--- a/sw/source/core/inc/frame.hxx
+++ b/sw/source/core/inc/frame.hxx
@@ -874,6 +874,8 @@ public:
     inline bool IsTextFrame() const;
     SwTextFrame* DynCastTextFrame();
     const SwTextFrame* DynCastTextFrame() const;
+    SwPageFrame* DynCastPageFrame();
+    const SwPageFrame* DynCastPageFrame() const;
     inline bool IsNoTextFrame() const;
     // Frames where its PrtArea depends on their neighbors and that are
     // positioned in the content flow