[Libreoffice-bugs] [Bug 105478] DOC LAYOUT specified height row splits and flows back to previous page, despite not meeting minimum height (comment 9).

[bugzilla-daemon at bugs.documentfoundation.org]

https://bugs.documentfoundation.org/show_bug.cgi?id=105478

--- Comment #17 from Justin L <jluth at mail.com> ---
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.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice-bugs/attachments/20200504/7461c670/attachment.htm>