summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorMiklos Vajna <vmiklos@collabora.com>2019-10-01 17:55:58 +0200
committerMike Kaganski <mike.kaganski@collabora.com>2019-10-11 11:43:17 +0200
commit7040869501dc2b5752822285c3e0616edd6276ef (patch)
tree81275a59eda48685951a21a33364eec2176fc952
parentsw: WW8: fix crashtesting asserts on fdo45983-1.doc export to ODT (diff)
downloadcore-7040869501dc2b5752822285c3e0616edd6276ef.tar.gz
core-7040869501dc2b5752822285c3e0616edd6276ef.zip
tdf#124601 sw FollowTextFlow: fix vert pos of objects outside the current cell
There were two problems here: 1) CalcHeightWithFlys() considered all follow-text-flow objects when determining the cell size, while wrap-through objects should never influence the layout of text (i.e. when they conflict, the second should have priority). 2) Once the cell had correct height, the oscillaction described in the SwFlyFreeFrame::CheckClip() comment started. Such a position update was already disabled for headers, but footers have exactly the same problem. In the case of the bugdoc, we jumped between 14618 and 14744 twips, till finally layout loop control kicked in. [ FollowTextFlow is meant to be same behavior as Word's layoutInCell shape property, so this is expected to improve rendering of existing documents. It's not likely that any user would opt in for FollowTextFlow to have the old close-but-not-exactly-matching behavior. ] (cherry picked from commit 489eef894e7034873ad262f9dfca554022db1b09) Conflicts: sw/qa/extras/layout/layout.cxx Change-Id: I6b3b672fc82c6c67dbbdd35c349613fe4cda610d Reviewed-on: https://gerrit.libreoffice.org/80595 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
-rw-r--r--sw/qa/extras/layout/data/tdf124601b.docbin0 -> 62976 bytes
-rw-r--r--sw/qa/extras/layout/layout.cxx17
-rw-r--r--sw/source/core/layout/flylay.cxx4
-rw-r--r--sw/source/core/layout/tabfrm.cxx12
4 files changed, 30 insertions, 3 deletions
diff --git a/sw/qa/extras/layout/data/tdf124601b.doc b/sw/qa/extras/layout/data/tdf124601b.doc
new file mode 100644
index 000000000000..4428a7daf7b3
--- /dev/null
+++ b/sw/qa/extras/layout/data/tdf124601b.doc
Binary files differ
diff --git a/sw/qa/extras/layout/layout.cxx b/sw/qa/extras/layout/layout.cxx
index 0ac66283857b..2dbd8a10a550 100644
--- a/sw/qa/extras/layout/layout.cxx
+++ b/sw/qa/extras/layout/layout.cxx
@@ -3124,6 +3124,23 @@ CPPUNIT_TEST_FIXTURE(SwLayoutWriter, testTdf127235)
pDoc->getIDocumentLayoutAccess().GetCurrentViewShell()->CalcLayout();
}
+CPPUNIT_TEST_FIXTURE(SwLayoutWriter, testTdf124601b)
+{
+ // Table has an image, which is anchored in the first row, but its vertical position is large
+ // enough to be rendered in the second row.
+ // The shape has layoutInCell=1, so should match what Word does here.
+ createDoc("tdf124601b.doc");
+ xmlDocPtr pXmlDoc = parseLayoutDump();
+
+ sal_Int32 nFlyTop = getXPath(pXmlDoc, "//fly/infos/bounds", "top").toInt32();
+ sal_Int32 nSecondRowTop = getXPath(pXmlDoc, "//tab/row[2]/infos/bounds", "top").toInt32();
+ // Without the accompanying fix in place, this test would have failed with:
+ // - Expected greater than: 3736
+ // - Actual : 2852
+ // i.e. the image was still inside the first row.
+ CPPUNIT_ASSERT_GREATER(nSecondRowTop, nFlyTop);
+}
+
CPPUNIT_PLUGIN_IMPLEMENT();
/* vim:set shiftwidth=4 softtabstop=4 expandtab: */
diff --git a/sw/source/core/layout/flylay.cxx b/sw/source/core/layout/flylay.cxx
index 49afefe7a828..3fb75b92b113 100644
--- a/sw/source/core/layout/flylay.cxx
+++ b/sw/source/core/layout/flylay.cxx
@@ -501,11 +501,11 @@ void SwFlyFreeFrame::CheckClip( const SwFormatFrameSize &rSz )
!GetDrawObjs() && !GetAnchorFrame()->IsInTab() )
{
SwFrame* pHeader = FindFooterOrHeader();
- // In a header, correction of the position is no good idea.
+ // In a header or footer, correction of the position is no good idea.
// If the fly moves, some paragraphs have to be formatted, this
// could cause a change of the height of the headerframe,
// now the flyframe can change its position and so on ...
- if ( !pHeader || !pHeader->IsHeaderFrame() )
+ if ( !pHeader )
{
const long nOld = getFrameArea().Top();
diff --git a/sw/source/core/layout/tabfrm.cxx b/sw/source/core/layout/tabfrm.cxx
index 8bb52b87ee8c..0fb98f161648 100644
--- a/sw/source/core/layout/tabfrm.cxx
+++ b/sw/source/core/layout/tabfrm.cxx
@@ -3852,11 +3852,21 @@ long CalcHeightWithFlys( const SwFrame *pFrame )
// OD 30.09.2003 #i18732# - only objects, which follow
// the text flow have to be considered.
const SwFrameFormat& rFrameFormat = pAnchoredObj->GetFrameFormat();
+ bool bFollowTextFlow = rFrameFormat.GetFollowTextFlow().GetValue();
const bool bConsiderObj =
(rFrameFormat.GetAnchor().GetAnchorId() != RndStdIds::FLY_AS_CHAR) &&
pAnchoredObj->GetObjRect().Top() != FAR_AWAY &&
- rFrameFormat.GetFollowTextFlow().GetValue() &&
+ bFollowTextFlow &&
pAnchoredObj->GetPageFrame() == pTmp->FindPageFrame();
+ bool bWrapThrough = rFrameFormat.GetSurround().GetValue() == text::WrapTextMode_THROUGH;
+ if (pFrame->IsInTab() && bFollowTextFlow && bWrapThrough)
+ {
+ // Ignore wrap-through objects when determining the cell height.
+ // Normally FollowTextFlow requires a resize of the cell, but not in case of
+ // wrap-through.
+ continue;
+ }
+
if ( bConsiderObj )
{
const SwFormatFrameSize &rSz = rFrameFormat.GetFrameSize();