Download it now!
Bug 105478 - DOC LAYOUT specified height row splits and flows back to previous page, despite not meeting minimum height (comment 9).
Summary: DOC LAYOUT specified height row splits and flows back to previous page, despi...
Status: REOPENED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
5.3.0.3 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: filter:doc
Depends on:
Blocks: DOC-Opening
  Show dependency treegraph
 
Reported: 2017-01-22 15:49 UTC by ndevenish
Modified: 2020-06-03 13:53 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
Doc file that reads badly in libreoffice (175.50 KB, application/msword)
2017-01-22 15:50 UTC, ndevenish
Details
PDF from MSO 2013 (281.16 KB, application/pdf)
2017-01-27 14:08 UTC, Buovjaga
Details
PDF from LibO 5.4 (191.18 KB, application/pdf)
2017-01-27 14:16 UTC, Buovjaga
Details
minHeightRow.doc: minimal test document (24.50 KB, application/msword)
2020-04-28 18:43 UTC, Justin L
Details

Note You need to log in before you can comment on or make changes to this bug.
Description ndevenish 2017-01-22 15:49:42 UTC
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
Comment 1 ndevenish 2017-01-22 15:50:26 UTC
Created attachment 130613 [details]
Doc file that reads badly in libreoffice
Comment 2 ndevenish 2017-01-22 15:52:15 UTC
Sorry; pages are 4,5,6, not 3,4,5
Comment 3 Buovjaga 2017-01-27 14:08:06 UTC
Created attachment 130718 [details]
PDF from MSO 2013
Comment 4 Buovjaga 2017-01-27 14:16:01 UTC
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
Comment 5 Buovjaga 2017-01-27 14:29:03 UTC
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.
Comment 6 QA Administrators 2018-01-28 03:24:57 UTC Comment hidden (obsolete)
Comment 7 QA Administrators 2020-01-29 03:29:12 UTC Comment hidden (obsolete, spam)
Comment 8 Justin L 2020-04-17 15:00:27 UTC Comment hidden (no-value)
Comment 9 Justin L 2020-04-28 14:39:05 UTC
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?
Comment 10 Justin L 2020-04-28 18:43:28 UTC
Created attachment 160038 [details]
minHeightRow.doc: minimal test document
Comment 11 Justin L 2020-04-30 06:59:28 UTC
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.
Comment 12 Mike Kaganski 2020-04-30 08:02:25 UTC
(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... ?
Comment 13 Justin L 2020-04-30 08:09:11 UTC
(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.
Comment 14 Mike Kaganski 2020-04-30 08:21:04 UTC
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.
Comment 15 Justin L 2020-04-30 08:34:06 UTC
(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.
Comment 16 Mike Kaganski 2020-04-30 08:35:56 UTC
Thanks Justin!
Comment 17 Justin L 2020-05-04 12:03:31 UTC
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.
Comment 18 Mike Kaganski 2020-05-04 12:24:20 UTC
(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.
Comment 19 Commit Notification 2020-05-11 08:15:20 UTC
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.
Comment 20 Justin L 2020-05-11 09:50:21 UTC
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.)
Comment 21 Justin L 2020-05-30 11:35:19 UTC
(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.
Comment 22 Commit Notification 2020-06-03 05:15:36 UTC
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.
Comment 23 Commit Notification 2020-06-03 13:49:48 UTC
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.
Comment 24 Justin L 2020-06-03 13:53:02 UTC
Reopened b/c inadequate fix has been reverted. See comment 21