Created attachment 179861 [details] Playground with screenshots to reproduce the bug I observed this bug in Version: 7.4.0.0.alpha0+ / LibreOffice Community Build ID: f775b625b497b4fa6731bddd433916dde52fbb2e CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: gtk3 Locale: de-DE (de_DE.UTF-8); UI: en-US Calc: threaded but it is also present in earlier versions. I expect that the binding of Format>Paragraph>Indents and Spacings also concatenates with a subsequent table. Otherwise one would risk a widowed table remaining separated from its headline. If a table is below a headline and if it does not fit to the same page together with it (respecting the table breaking properties of the table: possibly the first part of the table including its own table headline not fitting on the same page), then I expect the headline to move to the next page together with the table. Sometimes undoing a one keystroke operation does not undo it, you may have to undo one more step and redo it later, in order to return to the old state. I guess there is some <= rather than < (or >= than >) bug in the responsible computations of necessary space. See attached example.
Also found in Version: 6.4.0.0.beta1+ (x64) Build ID: e75dd1fc992f168f24d66595265a978071cdd277 CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: default; VCL: win; Locale: nl-NL (nl_NL); UI-Language: en-US Calc: CL and in Version: 6.0.6.0.0+ Build ID: c30963b8b4bbbe42a24b97aafa161eff9d7ccdd4 CPU threads: 4; OS: Windows 6.3; UI render: default; Locale: nl-NL (nl_NL); Calc: CL and in Version: 5.3.1.0.0+ Build ID: aa09fd58bd499a2a2c3a32c5f613892bad54076c CPU Threads: 4; OS Version: Windows 6.29; UI Render: default; Layout Engine: new; Locale: nl-NL (nl_NL); Calc: CL and in Versie: 5.1.6.2 Build ID: 07ac168c60a517dba0f0d7bc7540f5afa45f0909 CPU Threads: 4; Versie besturingssysteem:Windows 6.2; UI Render: GL; Locale: nl-NL (nl_NL); Calc: CL it's fine with Versie: 5.0.6.3 (x64) Build ID: 490fc03b25318460cfc54456516ea2519c11d1aa Locale: nl-NL (nl_NL)
Created attachment 180105 [details] Bibisect log Bisected to: author Tobias Lippert <drtl@fastmail.fm> 2015-09-27 21:30:20 +0200 committer Oliver Specht <oliver.specht@cib.de> 2015-11-04 14:30:17 +0000 commit 20538f233fe120b33a23d594458d4639b0c9670e (patch) tree bdb24e0c6c6a10f1bb002ccee8e4eec4e773eccb parent aa334d55ee34c125f6f4fdfaadbc1ed8fa33f5bc (diff) tdf#83910 Formatting of lines which consist of a single dummy line only The document which is attached to the ticket runs into an infinite loop because GetLineNr() does not increase since only dummy lines are added during formatting.
@Justin, More a long shot from me.. I bibsected this one to Tobias Lippert. I don't think he being around anymore.. The reason for the change was a bug 83910 (infinite loop) for DOCX file.. However it breaks do not split paragraphs for some reason. So the fix might be done at the wrong place.. at least that's my first bold guess .. and well you're the DOCX expert who might know.. Feel free to unCC, if uninterested..
Dear Adalbert Hanßen, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
(In reply to QA Administrators from comment #4) > Dear Adalbert Hanßen, > > To make sure we're focusing on the bugs that affect our users today, > LibreOffice QA is asking bug reporters and confirmers to retest open, > confirmed bugs which have not been touched for over a year. > > There have been thousands of bug fixes and commits since anyone checked on > this bug report. During that time, it's possible that the bug has been > fixed, or the details of the problem have changed. We'd really appreciate > your help in getting confirmation that the bug is still present. > > If you have time, please do the following: > > Test to see if the bug is still present with the latest version of > LibreOffice from https://www.libreoffice.org/download/ > > If the bug is present, please leave a comment that includes the information > from Help - About LibreOffice. > > If the bug is NOT present, please set the bug's Status field to > RESOLVED-WORKSFORME and leave a comment that includes the information from > Help - About LibreOffice. > > Please DO NOT > > Update the version field > Reply via email (please reply directly on the bug tracker) > Set the bug's Status field to RESOLVED - FIXED (this status has a particular > meaning that is not > appropriate in this case) > > > If you want to do more to help you can test to see if your issue is a > REGRESSION. To do so: > 1. Download and install oldest version of LibreOffice (usually 3.3 unless > your bug pertains to a feature added after 3.3) from > https://downloadarchive.documentfoundation.org/libreoffice/old/ > > 2. Test your bug > 3. Leave a comment with your results. > 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; > 4b. If the bug was not present in 3.3 - add 'regression' to keyword > > > Feel free to come ask questions or to say hello in our QA chat: > https://web.libera.chat/?settings=#libreoffice-qa > > Thank you for helping us make LibreOffice even better for everyone! > > Warm Regards, > QA Team > > MassPing-UntouchedBug The issue is still not solved. The bug is still present in Version: 26.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 8ffeca7af4302da21d33494342017c3737d540e1 CPU threads: 8; OS: Linux 6.8; UI render: default; VCL: gtk3 Locale: sv-SE (de_DE.UTF-8); UI: en-US Calc: threaded as one can easily see by adding a single space above the first heading in the example already attached to the bug report: The image goes to the next page, but the other chained paragraphs stay on the old one. I would have expected that they are all together shifted to the next page. (Note: the concatenated things easily fit on a page). The second example, where a Heading is concatenated with a table below it, goes to the next page, as soon as one adds a single forced line break above it. By shifting it together with the table to the next page, the heading (above the table) is not split from the table, which is ok. However the next cell in the table actually is split from its predecessors by a page break, which it should not do, because the paragraph in the first cell has the property "keep with the next paragraph". The table however has the property to split across pages and columns, but not the one to split a row across pages. If one changes the table properties to prevent splitting it (none of both check marks), the table is split off from the heading above it when the heading plus the table don't fit onto the page any more because of the vertical position of booth of them together due to what is above them. This should NOT HAPPEN! One might discuss whether the chaining (keep together) properties of cells or of the whole table are stronger than the chaining properties of paragraphs. Also a user might state requirements which become physically impossible: chain more than would ever fit on a page. In such a case LO Writer would have to decide whether to * add a page break which contradicts the keep together properties of paragraphs or cells or tables. If I were asked, I would propose to flag the situation with some triangular road sign: Chaining properties could not be met. I wouldn't move the text invisibly below the bottom edge, as if it were covered by a passe-partout, like in a picture frame. This would prevent editing the parts covered by the passe-partout. * or to enlarge the page shown on the screen but show the part that does not fit on a colored background or below a colored dotted line to alert the user of his impossible requirements. I would strongly advocate for such a solution. The dotted line might be accompanied by a yellow triangular road sign with a broken chain on it. The examples in the attachment are far away from requesting concatenated items not fitting on a page. Does the page split algorithm only look ahead for a single chaining property neglecting that there might be more than one? Or is there an "off by one" error?
Tobias, can you take a look?
Hello Bogdan, sorry, I do not have capacity to look into this. Best, Tobias
The commit from 2015 is - return ( rLine.GetLineNr() > nOrphLines ) && IsBreakNow( rLine ); + bool isOnFirstLine = (rLine.GetLineNr() == 1 && !rLine.GetPrev()); + if ( isOnFirstLine && rLine.GetCurr()->IsDummy()) { + return IsBreakNow( rLine ); + } + if ( rLine.GetLineNr() > nOrphLines ) { + return IsBreakNow( rLine ); + } + return false; Oliver, you were the commiter back then. Please can you take a look?