path: root/sw/source/core/layout/tabfrm.cxx
diff options
authorJustin Luth <>2020-03-06 21:26:37 +0300
committerMike Kaganski <>2020-04-04 14:02:47 +0200
commit60a1b40cf363a54b64b84afcfad7fd08bc6ce770 (patch)
tree3dbc2ea87377ef328946302d6791770825a2bef9 /sw/source/core/layout/tabfrm.cxx
parente692f53d32eda0afccbe067f019aaf4e683529a1 (diff)
tdf#123116 sw layout: don't "page-break" before oversized row
followup to LO 7.0 commit b271cc46851c61ddef20dc869bf339c857f76b18 THIS PATCH INTENTIONALLY BREAKS COMPATIBILITY WITH MSO. In the rather rare case of a table row that is larger than the page, but is nevertheless set to not allow splitting, historically this oversized row has started on a new page and disappeared into the bottom of the page. The commit mentioned above allowed the row to spill over onto the next page, but kept the "page break" feature for maximum compatibility and interoperability with MSWord. However, all of that seems completely senseless, so the most natural thing for the document to do would be to completely ignore the do-not-split-row setting and let everything flow naturally, without leaving a potentially large gap in order to start on a new page. Just let the oversized row stay attached to the prior row. The cases are rare enough that interoperability isn't important. In any case, for .doc documents authored by LibreOffice, Word is still going to try to squeeze it all on one page anyway, so even if we do leave a gap and start a new page, there will still be a difference. Now that compatibilityMode=15 for new .docx files, MSO almost perfectly matches the behaviour prior to this patch, so this is the one case where users might raise a complaint. The prior patch was committed first just to prove that we could fallback to a more compatible state in case this radical departure from the norm is unacceptable. Change-Id: I47c78526d4c4fda2c48e38fb64788bafbc06f2c8 Reviewed-on: Tested-by: Jenkins Reviewed-by: Mike Kaganski <>
Diffstat (limited to 'sw/source/core/layout/tabfrm.cxx')
1 files changed, 2 insertions, 7 deletions
diff --git a/sw/source/core/layout/tabfrm.cxx b/sw/source/core/layout/tabfrm.cxx
index be9fb1aef224..9adfcbef6988 100644
--- a/sw/source/core/layout/tabfrm.cxx
+++ b/sw/source/core/layout/tabfrm.cxx
@@ -1061,7 +1061,7 @@ bool SwTabFrame::Split( const SwTwips nCutPos, bool bTryToSplit, bool bTableRowK
// A row larger than the entire page ought to be allowed to split regardless of setting,
// otherwise it has hidden content and that makes no sense
- if ( !pRow->GetPrev() && pRow->getFrameArea().Height() > FindPageFrame()->getFramePrintArea().Height() )
+ if ( pRow->getFrameArea().Height() > FindPageFrame()->getFramePrintArea().Height() )
pRow->SetForceRowSplitAllowed( true );
bSplitRowAllowed = false;
@@ -3546,12 +3546,6 @@ bool SwTabFrame::ShouldBwdMoved( SwLayoutFrame *pNewUpper, bool &rReformat )
return true;
- // Unsplitable rows have always started on a new page, so don't movebwd, even though we now allow splitting in some cases.
- // This also matches Word - so good for interoperability (tdf#123116)
- const SwRowFrame* pFirstRow = GetFirstNonHeadlineRow();
- if ( pFirstRow && pFirstRow->IsForceRowSplitAllowed() )
- return false;
bool bFits = nSpace > 0;
if (!bFits && aRectFnSet.GetHeight(getFrameArea()) == 0)
// This frame fits into pNewUpper in case it has no space, but this
@@ -3562,6 +3556,7 @@ bool SwTabFrame::ShouldBwdMoved( SwLayoutFrame *pNewUpper, bool &rReformat )
// #i26945# - check, if follow flow line
// contains frame, which are moved forward due to its object
// positioning.
+ const SwRowFrame* pFirstRow = GetFirstNonHeadlineRow();
if ( pFirstRow && pFirstRow->IsInFollowFlowRow() &&