A recent regression, backported to 7.6, causes the last text run to follow the page break (move to the next page) instead of come before it. Steps to reproduce: -Open attachment 190646 [details] (page-section-breaks.RTF) -Notice that on the first page, we only have "page " instead of "page 1" I found it with the 7.6 bibisect as commit 950464e95723d153e571c657cbceb15a77373075 Author: Michael Stahl on Wed Nov 15 19:41:49 2023 +0100 writerfilter: remove DomainMapper::text() handling of paragraph break Convert all remaining callers to utext(). Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159485 Likely this has just exposed some kind of general text failure, so I won't mark it as a true regression.
confirmed with bibisect 24.2 that is was commit 15f54c82d136e6fee3a65494f3b5271857b5d6b8 Author: Michael Stahlon Wed Nov 15 19:41:49 2023 +0100 writerfilter: remove DomainMapper::text() handling of paragraph break Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159485
Interestingly, this is fixed by the framePr-related https://gerrit.libreoffice.org/c/core/+/160655, even though it isn't broken by the framePr change to sal_utext. Reconfirmed by the bisected commit is to blame by clean compiling. It is the change to lcl_endSectionGroup that triggers the problem, since it is exposed to a lot more "code" than just finishParagraph. bRemove is excessively triggered..., and forcing it to false also fixes the problem.
Interesting test: change the charRun "1" into "xyz" and only the "z" will get pulled to the second page. In the "good" case, we never run into the "lcl_endSectionGroup" dummy para code. I think this is ultimately tied back to the framePr thing, which FORCES m_bNeedPar to false. So, instead of ending the \page with a dummy \par, we just jump into the header/footer import and end up at the \sect without ever calling \par. For this particular document, I don't expect bRemove has come into play, although I'm sure it will in many other cases..., related to IsInHeaderFooter.
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/798649ec30b536614048aa457fb9c8d4dce30b31 tdf#158583 tdf#158586 RTF writerfilter: only startRun for real frame It will be available in 24.8.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Justin Luth committed a patch related to this issue. It has been pushed to "libreoffice-24-2": https://git.libreoffice.org/core/commit/465cc1bbbe86b2affc112c6be79c7c0e9ea885e6 tdf#158583 tdf#158586 RTF writerfilter: only startRun for real frame It will be available in 24.2.0.0.beta2. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Justin Luth committed a patch related to this issue. It has been pushed to "libreoffice-7-6": https://git.libreoffice.org/core/commit/ee4a371e7cd6029978260b7692fe5b5db00dce8b tdf#158583 tdf#158586 RTF writerfilter: only startRun for real frame It will be available in 7.6.5. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.