Description: Trying to read a job application form, supplied in Doc format - On pages 3, 4 and 5 the reference fields are interleaved with the "Information in support of your application" multi-page table, whereas these are supposed to be in-order, at the end of the section. The "Information in support" header is only supposed to be shown once, where it is also rendered twice here. Seems to be no attachment field on bug report so document is: http://www.diamond.ac.uk/Careers/dms/HR/Application-Form---Standard---April-2016/Application%20Form%20-%20Standard%20-%20April%202016.doc or https://www.dropbox.com/s/8etoici1t3o0jj9/BugReport_ApplicationForm.doc Steps to Reproduce: 1.Open document 2.View pages 3,4,5 Actual Results: Referee sections interleaved with giant box. Header for "Support Information" duplicated. Expected Results: Referee sections should be in order, after the "support information" giant, multi-page cell. Support information should be two pages - one header, one empty page (with box). Reproducible: Always User Profile Reset: No Additional Info: User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.87 Safari/537.36
Created attachment 130613 [details] Doc file that reads badly in libreoffice
Sorry; pages are 4,5,6, not 3,4,5
Created attachment 130718 [details] PDF from MSO 2013
Created attachment 130719 [details] PDF from LibO 5.4 LibO Version: 5.4.0.0.alpha0+ Build ID: b41186a2fc49e440890b8c86e5367352ffaf9cd6 CPU Threads: 4; OS Version: Windows 6.29; UI Render: default; TinderBox: Win-x86@42, Branch:master, Time: 2017-01-26_01:50:40 Locale: fi-FI (fi_FI); Calc: group
Confirmed and splitting report (note See also) Let this be about how the table rows appear on the wrong places. "Please explain any gaps in your employment history" is the first occurrence, on pg 2 in LibO, on pg 3 in MSO. Second is "1.1 REFERENCES" on pg 4 in LibO, on pg 5 in MSO.
** Please read this message in its entirety before responding ** 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 http://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://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Dear ndevenish, 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 http://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://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
This is much more useable in 7.0+. The layout code for some reason decides to split a row that shouldn't be split. If you edit the document, push "INFORMATION IN SUPPORT OF YOUR APPLICATION" onto the next page, and then delete your carriage-returns, it will not flow back. So the general principle is right, but something in the layout triggers an "I must split" scenario.
Hmm, I'm wrong in comment 8. Only the last row is marked as do not split. Based on playing around using Word 2003, I noticed that the row height for "INFORMATION IN SUPPORT OF YOUR APPLICATION" is "at least 25cm". There is a bit more than 7cm available space on the previous page. Changing that value to 7cm makes it flow back. Changing it to 8cm forces it to the next page. LO does know about row height (although it is not visible in the table properties), and it does seem to follow the same layout principle. If I modify the source document and remove one carriage return from that section, then it loads as expected. 25cm should fit nicely in the 27cm available on the page, so why is it failing?
Created attachment 160038 [details] minHeightRow.doc: minimal test document
The root problem here seems to have been caused by LO 5.3.0.1's fix for bug 104425. https://cgit.freedesktop.org/libreoffice/core/commit/?id=6f5024de2e1a5cc533527e45b33d9a415467c48d A minimum height for a table cell should be honoured. Otherwise what is the point, since a table grows to fill the space it needs anyway, and then there is no need for a minimum height (unless your content doesn't fill all of the space). But obviously this is tricky based on the history and fallout of that bugfix.
(In reply to Justin L from comment #11) > A minimum height for a table cell should be honoured. Otherwise what is the > point, since a table grows to fill the space it needs anyway, and then there > is no need for a minimum height (unless your content doesn't fill all of the > space). But obviously this is tricky based on the history and fallout of > that bugfix. Yes, but LibreOffice does honour the minimum height of *rows* (not cells). When a row requires that its height should be no less than X, and the X is greater than space available on page, then it must be split anyway, despite it being less than X on that page. But then, if it's split half way, how should it meet the minimal height requirement? by summing the total height of that row's parts on several pages. Now, if the row is required to split, and it's the total height that is taken into account, then how is the current behaviour wrong? Is there some specification that requires that in this case, the split must only be performed when the whole page is filled with this row? I'm inclined to consider this a corner case where LibreOffice's interpretation is one of possible ways to interpret UB, and is more logical than of Word; and possibly should not be changed... ?
(In reply to Mike Kaganski from comment #12) > possible ways to interpret UB, and is more logical than of Word Well, at least for loading MS format documents, MS interpretation would win out. I too would probably hesitate changing ODT's interpretation once again. For OP's document, MS interpretation certainly fits much better.
So the problem is relation between "allow to split between pages" and "minimal row height"? In Word, even if a row is allowed to split, it isn't allowed to split until minimal height is reached (or a whole page is filled), right? and in LO, "allow row to split" has now higher priority. > For OP's document, MS interpretation certainly fits much better Well, any use of corner cases makes hard time for interop. If OP document had "do not split this row" flag set, which is logical, no problem would result... but of course, we can have a new compat setting, yes.
(In reply to Mike Kaganski from comment #14) > So the problem is relation between "allow to split between pages" and > "minimal row height"? In Word, even if a row is allowed to split, it isn't > allowed to split until minimal height is reached (or a whole page is > filled), right? and in LO, "allow row to split" has now higher priority. I think you have it exactly right. Don't worry about it for now - I'm researching a fix. We can just re-use an existing compat flag like TABLE_ROW_KEEP.
Thanks Justin!
So it is interesting that if the content is LESS THAN the minimum height, then LO already doesn't try to split the row. However, if the content is MORE THAN the minimum height, then it will split the row at any point. I think this phenomenon is described by: > 3. It turns out, that if contents of the splitted cell has less > height than the min height setting, then following happens. > In SwTabFrame::Split, all rows below splitted one are moved to > follow flow table; then table frame's Shrink method used to shrink > the freed height. At this moment, still, the height of splitted > row is too high, and total height of table is too high. Then, > lcl_RecalcSplitLine is called, where row is first shrunk, and then > lcl_RecalcRow and SwRowFrame::Calc try to move contents and resize > the splitted row. They get the minimum height of content (we already > don't consider the min height setting), but then "last row will fill > the space in its upper" (see SwRowFrame::Format). Row returns its > previous size, table does not resize, it doesn't fit to page, and > split fails. Proposed patch (for just MS formats) is at https://gerrit.libreoffice.org/c/core/+/93414 For MS Word documents, the answer is obviously to follow MS layout, and not to split unless the minimum size fits. But considering this mild discrepancy, should we make the same change to ODT - in order to be interoperable at design time with MS? After all, it acted this way until LO 5.3.
(In reply to Justin L from comment #17) > For MS Word documents, the answer is obviously to follow MS layout, and not > to split unless the minimum size fits. But considering this mild > discrepancy, should we make the same change to ODT - in order to be > interoperable at design time with MS? After all, it acted this way until LO > 5.3. Sounds reasonable to not multiply special cases, so my take (however more logical I consider the current way) is to do it uniformly in "MS way" both for MS formats and ODF, too.
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/aa5dc0b48cd4db6883c9b52c68b16170c9c81d1f tdf#105478 sw layout: treat minHeight as "do not split row" It will be available in 7.0.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.
So, in the end, the patch doesn't care if DOC or ODT. MinHeight on a row will always be obeyed. Two exceptions. If minHeight is greater than the page height, it is ignored. Second exception (which apparently is what Word does) is that minHeight only applies to the first page (seems obvious, right?). Word, however, seems to apply the minimum to each page that the row lands on - aka enforcing it multiple times. (Somewhere, there is a bug report/unit test that shows this, but I can't find it back.)
(In reply to Commit Notification from comment #19) > Justin Luth committed a patch related to this issue. > tdf#105478 sw layout: treat minHeight as "do not split row" This has caused regression bug 133441 and likely will need to be reverted/reopened.
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/4e81ef96e3e1c10ca5162e4e4971c803780a75b4 Revert "tdf#105478 sw layout: treat minHeight as "do not split row"" It will be available in 7.1.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-7-0": https://git.libreoffice.org/core/commit/0fe109a27c9a1b10b0b8a3314cb55926ecf103ae Revert "tdf#105478 sw layout: treat minHeight as "do not split row"" It will be available in 7.0.0.1. 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.
Reopened b/c inadequate fix has been reverted. See comment 21
repro 7.6+