https://bugs.documentfoundation.org/show_bug.cgi?id=168753
BogdanB <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED CC| |[email protected] | |g --- Comment #4 from BogdanB <[email protected]> --- I tried to bibisect the solution because since 26.2 it is working well. Before this commit, the document hang, so I could not export to PDF. After this commit, I could open the document and export as PDF directly. commit 6aec3c203e936bad60f565a73a365dfab573aa5b Author: Mike Kaganski <[email protected]> Date: Mon Jan 26 15:29:24 2026 +0500 tdf#170477 follow-up: reimplement the fix by cleaning up code This is an alternative fix to the bug. The idea is, that we shouldn't call MoveFwd in SwTabFrame::MakeAll in case of floating tables. In commit 45574624ff05673d44f11cdbbbb49e1af599133e (tdf#120262 sw floattable: no split when none of first row fits the vert space, 2023-07-19) a code was added, that made sure that for floating tables MoveFwd was called with bMoveAlways = true. Obviously, for that bug, this code path was used at that time. However, the unit test for that but doesn't pass the code path these days. What happens inside MoveFwd for a floating table is: 1. MoveFwd calls GetLeaf, which in turn calls GetNextFlyLeaf; 2. GetNextFlyLeaf splits the anchor (the new frame isn't yet moved), and creates a follow fly, which is still on the same page; 3. MoveFwd moves the whole table to the new fly, making the old fly empty; 4. The old fly calls its DelEmpty, breaking precede/follow chain and making the new fly standalone. In the end, the situation after the call is fundamentally the same as before, with exception of new garbage (empty fly) to clean later, and the split anchor that needs a join. This change avoids calling MoveFwd for floating tables in this case. It keeps all unit tests working, so hopefully this cleanup could be an improvement by simplifying code, and by avoiding a call to SwLayouter::InsertMovedFwdFrame, which itself is manual override of the normal layout process (IMO, the less it's used, the better). If it turns out problematic, it may be simply reverted (that's the idea of merging it only after the more conservative fix). Change-Id: I606976de629bb5514edafd1430704901241876cc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/198135 Tested-by: Jenkins Reviewed-by: Mike Kaganski <[email protected]> Signed-off-by: Xisco Fauli <[email protected]> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/199802 Please test if this bug is solved for you, and if not, please reopen this bug report. -- You are receiving this mail because: You are the assignee for the bug.
