Bug 134298 - Picture overlappes page with content, so it is not readible anymore
Summary: Picture overlappes page with content, so it is not readible anymore
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
6.0.0.3 release
Hardware: All All
: medium normal
Assignee: Michael Stahl (allotropia)
URL:
Whiteboard: target:7.1.0 target:7.0.4
Keywords: bibisected, bisected, regression
Depends on:
Blocks:
 
Reported: 2020-06-25 13:11 UTC by Ilhan Yesil
Modified: 2020-12-14 06:57 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
Picture on first page instead on second (39.92 KB, application/vnd.oasis.opendocument.text-template)
2020-06-25 13:13 UTC, Ilhan Yesil
Details
Picture compared in LO MSO FO (165.48 KB, image/png)
2020-11-11 10:09 UTC, Timur
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Ilhan Yesil 2020-06-25 13:11:51 UTC
Description:
In our Company, we have a document with two pages. The first page consists of text and tables, the second page is covered by a big Picture. With LibreOffice 5.2, the document is opened as awaited with two pages, starting with 6.x, it is opened only with one page, where only the Picture is shown, but not the Content of the first page anymore.

I've striped out and deleted all Elements from the document, till a Skeleton remains, that still Show the problem.

Steps to Reproduce:
1. Open the attached document

Actual Results:
Picture that should be on second page, overlappes first page

Expected Results:
Picture should be on second page.


Reproducible: Always


User Profile Reset: No



Additional Info:
Bibisect gives:

ab89b966087d48e41d4bf4809a53e7e0e89cb86 is the first bad commit
commit 5ab89b966087d48e41d4bf4809a53e7e0e89cb86
Author: Jenkins Build User <tdf@pollux.tdf>
Date:   Wed Feb 8 17:28:37 2017 +0100

    source sha:6f5024de2e1a5cc533527e45b33d9a415467c48d
    
    source sha:6f5024de2e1a5cc533527e45b33d9a415467c48d

:040000 040000 a2271ed9126b9fd41910f2c5ddfccb009b613a0c 60351d50dec3d73fc14b629f3d9d1e57d2545a5f M      instdir

# bad: [b5b34aafb02f9070db485080b35ce0179c38b941] source sha:328f3e7e4c67bf2e09a56f199a4332f1b1fe3b11
# good: [f04172d4ac1553877deea87d267307ad3eb1c99b] source sha:4136757b4e51c4e6f7cb4132c95538a7f831ef2c
git bisect start 'origin/master' 'oldest'
# bad: [6a71512f3c2d554422bbd939e7740cf3ea128bf2] source sha:64b68e98d215f98f72fd6493b62517ab9984a8d2
git bisect bad 6a71512f3c2d554422bbd939e7740cf3ea128bf2
# bad: [103dcb92b5c7ec253b78108b207fd300a82d0f8e] source sha:d685b030aa0d7aa25d9666cd6857b7cb917e297c
git bisect bad 103dcb92b5c7ec253b78108b207fd300a82d0f8e
# bad: [80b2723f92bb07e654b8413a5ee48de3a3935e5f] source sha:53edf60c4ce6ed32f87471e018878c40b788005a
git bisect bad 80b2723f92bb07e654b8413a5ee48de3a3935e5f
# good: [776f3ca2b080e350f71de7f282204629d7842dce] source sha:de943f90ed1d1402d2eb9c778740b4e7dfcda92c
git bisect good 776f3ca2b080e350f71de7f282204629d7842dce
# bad: [86dba9a4f43b401f9ec1923c63e34d7365de95ef] source sha:111858d6c64e5c3790ec23853df564584f4c3f99
git bisect bad 86dba9a4f43b401f9ec1923c63e34d7365de95ef
# good: [1bd4872acd2f7999c3a46ac66ae9076b9bf9e88c] source sha:c54eb45230ef54c10e7a86d1c249ea42b07881fe
git bisect good 1bd4872acd2f7999c3a46ac66ae9076b9bf9e88c
# good: [793da6ca5bb7e3f0f71ffe7054f5f95ec396512c] source sha:cbf5b21f2a65bbb342295200f6ad93a00f90733e
git bisect good 793da6ca5bb7e3f0f71ffe7054f5f95ec396512c
# good: [50f83274c86ef1f57fcd4cd9bbc1dd169dc0f3e2] source sha:57d248bcec3c6ae3fa1a943a9fd92c566239787f
git bisect good 50f83274c86ef1f57fcd4cd9bbc1dd169dc0f3e2
# good: [c97758a11db1b0df3951d4eb31f2b72dc43edecd] source sha:9f2e5ca515908b0c663fcc1ce3bcdfbfd307cae5
git bisect good c97758a11db1b0df3951d4eb31f2b72dc43edecd
# good: [b706e003aa67bfcbce4013976429f14e7d21b149] source sha:53dbc419b2e886b345a3512cf11e035ff2b7651b
git bisect good b706e003aa67bfcbce4013976429f14e7d21b149
# good: [5ac9bd1a12d0e8ccea44828fcc3c41c6cebda092] source sha:424553f16092fa733855aec3eda2182ae095bb13
git bisect good 5ac9bd1a12d0e8ccea44828fcc3c41c6cebda092
# good: [c59db51cc3a97ace3cf7a1af84ed88eb836c8b43] source sha:7740e945e0c74d057c424cced079adc766cc5604
git bisect good c59db51cc3a97ace3cf7a1af84ed88eb836c8b43
# bad: [77894aec4c98d987d1759d12bb38d1c7d988bf01] source sha:13cba3505f3af25b640e9d3fa8e24ccdf1378c68
git bisect bad 77894aec4c98d987d1759d12bb38d1c7d988bf01
# bad: [5ab89b966087d48e41d4bf4809a53e7e0e89cb86] source sha:6f5024de2e1a5cc533527e45b33d9a415467c48d
git bisect bad 5ab89b966087d48e41d4bf4809a53e7e0e89cb86
# first bad commit: [5ab89b966087d48e41d4bf4809a53e7e0e89cb86] source sha:6f5024de2e1a5cc533527e45b33d9a415467c48d
Comment 1 Ilhan Yesil 2020-06-25 13:13:24 UTC
Created attachment 162400 [details]
Picture on first page instead on second
Comment 2 Ilhan Yesil 2020-06-25 13:15:50 UTC
concerning commit:

commit 6f5024de2e1a5cc533527e45b33d9a415467c48d
Author: Mike Kaganski <mike.kaganski@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@collabora.com>
    Tested-by: Jenkins <ci@libreoffice.org>
    Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Comment 3 Ilhan Yesil 2020-06-25 13:19:52 UTC
I found out, that in tabfrm.cxx
void SwTabFrame::MakeAll
is called again and again due to the introduced Shrink function, until it gaves up to layout the page.
Comment 4 Telesto 2020-06-25 14:06:04 UTC
Repro
Version: 7.1.0.0.alpha0+ (x64)
Build ID: aadcd6f90916bd2b9734ae793141d0c77cc5b46c
CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: default; VCL: win
Locale: nl-NL (nl_NL); UI: en-US
Calc: CL
Comment 5 Telesto 2020-06-25 14:06:35 UTC Comment hidden (obsolete)
Comment 6 Timur 2020-11-11 10:09:22 UTC
Created attachment 167188 [details]
Picture compared in LO MSO FO

Bug 138039 looks similar, just with more complicated sample attachment 167062 [details] compared as attachment 167187 [details].
Comment 7 Commit Notification 2020-11-16 13:44:44 UTC
Michael Stahl committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/6b92d2e8522ecc98d2c5532f5076c20ae295168e

tdf#138039 tdf#134298 sw: layout: fix overlap of fly and table

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 8 Commit Notification 2020-11-16 15:51:54 UTC
Michael Stahl committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/094ee3955ee81e1bc631d50cc216cbb17a777839

(related tdf#134298) sw: layout: avoid infinite loop in InternalAction()

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 9 Commit Notification 2020-11-16 15:52:05 UTC
Michael Stahl committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/b9ef71476fd70bc13f50ebe80390e0730d1b7afb

tdf#134298 sw: layout: remove left-over page frame without content

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 10 Michael Stahl (allotropia) 2020-11-16 15:56:39 UTC
this document had an additional problem compared to the other one;
there were 3 pages and page 2 was empty (without content).

fixed on master
Comment 11 Commit Notification 2020-11-16 20:28:27 UTC
Michael Stahl committed a patch related to this issue.
It has been pushed to "libreoffice-7-0":

https://git.libreoffice.org/core/commit/6f1cee347ea5057a3a1244d2f669fbb3fd272cbc

tdf#138039 tdf#134298 sw: layout: fix overlap of fly and table

It will be available in 7.0.4.

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.