[Libreoffice-bugs] [Bug 134298] Picture overlappes page with content, so it is not readible anymore

[bugzilla-daemon at bugs.documentfoundation.org]

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

--- Comment #2 from Ilhan Yesil <ilhanyesil at gmx.de> ---
concerning commit:

commit 6f5024de2e1a5cc533527e45b33d9a415467c48d
Author: Mike Kaganski <mike.kaganski at collabora.com>
Date:   Thu Dec 8 23:01:03 2016 +0300

    tdf#104425 sw: split rows w/large min height (fix layout loop)

    This solves the problem of rows with too big minimal height causing
    layout failure (the table just goes out of page, does not flow to
    next page).

    It does so with three steps:
    1. Currently, a row with a minimum height that flows to next page
    repeats whole min height on that (and possibly following) pages.
    If this behaviour continued, then that would cause layout loop:
    the row min height would be too high for the page, so it would
    keep flowing to next pages (actually just go beyond the botom
    because of layout failure). To mitigate this, the patch changes
    the behaviour to measure total height of all frames of the row:
    the function lcl_calcHeightOfRowBeforeThisFrame calculates the
    total height of previous row frames for the same row, then in
    places where we need to get min height, this value is subtracted
    from row min total height. On following pages the min height of
    frames will get less each time.

    2. When the row is split, the possibility to split depends on if
    the minimum height of the row fits into the vertical space left.
    The minimum height is found as maxinum of two values: minimal
    contents of the row (e.g., height of first line of text, or an
    object, or lower table cell), and the minimum height setting.
    As the minimum height setting should not prevent the cell to
    flow, (it only should ensure that total height is no less), we
    should not consider the setting when the split is performed
    (we should be able to keep on first page as little as required).
    To allow this, a new bool member introduced in SwRowFrame:
    m_bIsInSplit, with its setter and getter. When it is true,
    the routines that calculate min height ignore the min height
    setting. It is set in lcl_RecalcSplitLine around lcl_RecalcRow
    and SwRowFrame::Calc that decide if it's possible to keep part of
    row's content on first page, and update table's height to fit
    the rest of space.

    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.
    To try to fix that, I call SwTabFrame::Shrink in lcl_RecalcSplitLine
    after lcl_ShrinkCellsAndAllContent before lcl_RecalcRow.

    Unit test included.

    Change-Id: I8422e43cff7d6b5955541ed3fe930779429ed55b
    Reviewed-on: https://gerrit.libreoffice.org/31774
    Reviewed-by: Mike Kaganski <mike.kaganski at collabora.com>
    Tested-by: Jenkins <ci at libreoffice.org>
    Reviewed-by: Miklos Vajna <vmiklos at collabora.co.uk>

-- 
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/20200625/8c91da17/attachment.htm>