summaryrefslogtreecommitdiff
path: root/sw/source/core
diff options
context:
space:
mode:
authorMiklos Vajna <vmiklos@collabora.com>2019-10-01 17:55:58 +0200
committerMiklos Vajna <vmiklos@collabora.com>2019-10-02 01:06:46 +0200
commit489eef894e7034873ad262f9dfca554022db1b09 (patch)
tree878d6281511e46c50a7d09d3be46bc5ccc0f9677 /sw/source/core
parent727ca36e83868acbe40aaa239cefc69659b9bc39 (diff)
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. ] Change-Id: I6b3b672fc82c6c67dbbdd35c349613fe4cda610d Reviewed-on: https://gerrit.libreoffice.org/79980 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
Diffstat (limited to 'sw/source/core')
-rw-r--r--sw/source/core/layout/flylay.cxx4
-rw-r--r--sw/source/core/layout/tabfrm.cxx12
2 files changed, 13 insertions, 3 deletions
diff --git a/sw/source/core/layout/flylay.cxx b/sw/source/core/layout/flylay.cxx
index 4a7030ea241e..1589c12670fe 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 4395bd231900..7333acc59c9d 100644
--- a/sw/source/core/layout/tabfrm.cxx
+++ b/sw/source/core/layout/tabfrm.cxx
@@ -3839,11 +3839,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();