diff options
author | Miklos Vajna <vmiklos@collabora.com> | 2019-10-01 17:55:58 +0200 |
---|---|---|
committer | Mike Kaganski <mike.kaganski@collabora.com> | 2019-10-11 11:43:17 +0200 |
commit | 7040869501dc2b5752822285c3e0616edd6276ef (patch) | |
tree | 81275a59eda48685951a21a33364eec2176fc952 | |
parent | sw: WW8: fix crashtesting asserts on fdo45983-1.doc export to ODT (diff) | |
download | core-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.doc | bin | 0 -> 62976 bytes | |||
-rw-r--r-- | sw/qa/extras/layout/layout.cxx | 17 | ||||
-rw-r--r-- | sw/source/core/layout/flylay.cxx | 4 | ||||
-rw-r--r-- | sw/source/core/layout/tabfrm.cxx | 12 |
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 Binary files differnew file mode 100644 index 000000000000..4428a7daf7b3 --- /dev/null +++ b/sw/qa/extras/layout/data/tdf124601b.doc 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(); |