path: root/sw/source
diff options
authorMichael Stahl <>2021-04-27 20:07:14 +0200
committerMichael Stahl <>2021-04-28 10:51:42 +0200
commitca19177728c66d913996a48c91a0ba47d08825d6 (patch)
tree4f4b1c3c02d32e69d7a3a5837ee5afde0b489bb4 /sw/source
parentc06f05e28cb66bd2aac5ea65bcfa3732808c51c6 (diff)
sw: layout: let nested table move forward
The problem is that a nested table at the bottom of the page doesn't fit into its cell, but it is split and its first row still remains on the page where it doesn't fit. The outer table 3 tries to split with bTryToSplit=true. In SwTabFrame::MakeAll(), first a split of the nested table 435 with bTryToSplit=true is attempted; this fails and is partially undone - the follow flow line is removed, but the last 2 rows remain in follow. The bTryToSplit=false is skipped because there's only one row now. Then MoveFwd() is tried, but it fails because the top-level table doesn't have a previous frame. Then bTryToSplit=false is tried, and succeeds, again leaving row 436 on page 1 and other 2 in follow. Now another attempt with bTryToSplit=true is made, failing again, not effectively changing anything. During all of this, growing of the outer cell frame 434 and row frame 433 is prevented by the outer table 3 having a follow flow line, see SwRowFrame::GrowFrame(). The result is that cell 434 has content area height 190 but the table 435 with its single row is all valid with height 406, so it's cut off in the rendering. This doesn't happen for SwTextFrame inside table because that one does the MoveFwd(). Plausibly it's the inner table's responsibility to finish with a valid state that fits the constraints of the current page; there are some checks in lcl_RecalcSplitLine() to check for no content frame in the row but none for the row being too small to contain the content that was formatted. So the only valid results for the inner table are that it either moved forward, or it left behind a row containing no content (such as that produced by its own failed attempt to split with bTryToSplit=true), which could be handled by the outer table split code - but the latter could be insufficient in case the outer table is itself a follow, or at least would require further changes in lcl_RecalcSplitLine(). So fix this by removing a condition in MoveFwd() that doesn't make any sense to me - why is it relevant for an inner table during a split of the outer table whether the outer table itself can move forward? Change-Id: I1e01ce233383cc70b9aea72d25369b7278eb75f0 Reviewed-on: Tested-by: Jenkins Reviewed-by: Michael Stahl <>
Diffstat (limited to 'sw/source')
1 files changed, 1 insertions, 2 deletions
diff --git a/sw/source/core/layout/flowfrm.cxx b/sw/source/core/layout/flowfrm.cxx
index 4da7afb622df..407232509e09 100644
--- a/sw/source/core/layout/flowfrm.cxx
+++ b/sw/source/core/layout/flowfrm.cxx
@@ -1952,8 +1952,7 @@ bool SwFlowFrame::MoveFwd( bool bMakePage, bool bPageBreak, bool bMoveAlways )
// Allow the MoveFwd even if we do not have an IndPrev in these cases:
if ( m_rThis.IsInTab() &&
( !m_rThis.IsTabFrame() ||
- ( m_rThis.GetUpper()->IsInTab() &&
- m_rThis.GetUpper()->FindTabFrame()->IsFwdMoveAllowed() ) ) &&
+ m_rThis.GetUpper()->IsInTab() ) &&
nullptr != m_rThis.GetNextCellLeaf() )
bNoFwd = false;