Bug 34957 - ODT containing multi-page table with table setting "Keep with next paragraph" is pushed to next page
Summary: ODT containing multi-page table with table setting "Keep with next paragraph"...
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
3.3.1 release
Hardware: All All
: highest minor
Assignee: Justin L
URL:
Whiteboard: target:5.2.0
Keywords:
Depends on:
Blocks:
 
Reported: 2011-03-02 22:29 UTC by sasha.libreoffice
Modified: 2020-05-05 08:27 UTC (History)
11 users (show)

See Also:
Crash report or crash signature:


Attachments
table in Writer behaves strange with certain option (55.10 KB, application/vnd.oasis.opendocument.text)
2011-03-02 22:29 UTC, sasha.libreoffice
Details
ODT example illustrating effect of table setting (9.55 KB, application/vnd.oasis.opendocument.text)
2014-09-28 15:07 UTC, Owen Genat (retired)
Details
Zip containing several example documents and PDF evidence. (559.07 KB, application/force-download)
2015-05-04 08:11 UTC, Justin L
Details
fairly comprehensive testing suite with results PDFs (updated) (2.35 MB, application/zip)
2015-06-09 05:50 UTC, Justin L
Details
my little example for the keep with paragraph test (9.61 KB, application/3dr)
2015-10-18 07:04 UTC, Marc Kaulisch
Details

Note You need to log in before you can comment on or make changes to this bug.
Description sasha.libreoffice 2011-03-02 22:29:32 UTC
Created attachment 44056 [details]
table in Writer behaves strange with certain option

table in Writer behaves strange when set option "Keep with next paragraph":
it begins from new page.
Explanations in attachment.
reproduced on Mandriva 64 bit and windows XP 32 bit
Comment 1 Cédric Bosdonnat 2011-03-03 05:23:29 UTC
This is indeed a minor bug in the layout... Taking it.
Comment 2 Marc Kaulisch 2012-08-22 11:11:18 UTC
this can be reproduced with the newest LO 3.6.1.1 (Windows 7 64 bit) and is really annoying, because of paragraphs explaining some content of the table should be kept with table, but also the caption (above the table) should be kept with the table.
Comment 3 sasha.libreoffice 2012-08-22 11:53:31 UTC
Thanks for interesting in this problem
"Version" is most old version where bug appears, not current version
Changing back to 3.3.1
Comment 4 tommy27 2013-07-31 19:58:44 UTC
confirmed with LibO 4.0.4 and 4.1.0 on Win7 64bit

moving it to mab4.0 because 3.6 has reached EOL so we are in the process of closing the meta bug.
Comment 5 Björn Michaelsen 2014-01-17 09:58:32 UTC Comment hidden (obsolete)
Comment 6 Stéphane Guillou (stragu) 2014-02-12 07:30:08 UTC
Moving to mab4.1 (Bug 60270) because:
- 4.0 reached EOL (End Of Life)
- bug confirmed in 4.1
Comment 7 tommy27 2014-05-12 19:40:51 UTC
reproducible with 4.2.4.2 too

moving to mab4.2 list since 4.1.x is EOL
Comment 8 Marc Kaulisch 2014-06-27 10:44:00 UTC
reproducible with 4.3.0.1
Comment 9 Marc Kaulisch 2014-08-11 11:15:31 UTC
bug is still existent in 4.3.1.1
Comment 10 Owen Genat (retired) 2014-09-28 15:07:16 UTC
Created attachment 107012 [details]
ODT example illustrating effect of table setting

This example displays the same under GNU/Linux using:

- v3.3.4.1 OOO330m19 Build: 401
- v3.4.6.2 OOO340m1 Build: 602
- v3.5.7.2 Build ID: 3215f89-f603614-ab984f2-7348103-1225a5b
- v3.6.7.2 Build ID: e183d5b
- v4.0.6.2 Build ID: 2e2573268451a50806fcd60ae2d9fe01dd0ce24
- v4.1.6.2 Build ID: 40ff705089295be5be0aae9b15123f687c05b0a
- v4.2.6.3 Build ID: 3fd416d4c6db7d3204c17ce57a1d70f6e531ee21
- v4.3.2.2 Build ID: edfb5295ba211bd31ad47d0bad0118690f76407d
- v4.4.0.0.alpha0+ Build ID: df73f4115cfe4d07e4159adf087571687eb173ec TinderBox: Linux-rpm_deb-x86_64@46-TDF, Branch:master, Time: 2014-09-25_23:06:16
Comment 11 Owen Genat (retired) 2014-09-28 15:49:54 UTC
Bug 84084 added to See Also list as it describes a similar result for DOC but for the "Keep with next paragraph" setting against paragraph text in a table. It is not clear to me what the behaviour should be for this setting (fo:keep-with-next="always") against paragraph text and/or a table. Currently these are the resultant effects in a multi-page table for two file formats:

- ODT, paragraph setting (in table): no effect on table.
- DOC, paragraph setting (in table): table pushed to next page.
- ODT, table setting: table pushed to next page.
- DOC, table setting: table pushed to next page.

Presumably content should be influenced by this setting in a consistent manner i.e., paragraph kept with paragraph and table row kept with table row? I would think that pushing content to the next page makes more sense (for a multi-page table) than having no effect - especially for the table setting. Pushing content is a clear visual indicator that the setting is in effect. How else can a table be forced to commence on a new page via styles?

Summary amended for clarity.
Comment 12 tommy27 2014-11-22 19:11:35 UTC
still present in 4.4.0 beta1 
moving to mab4.3 list since 4.2. reached EOL
Comment 13 Marc Kaulisch 2014-11-24 08:55:36 UTC
may this problem affect also other bugs such as: https://bugs.freedesktop.org/show_bug.cgi?id=62613
I am not able to test this properly, sorry...
Comment 14 Justin L 2015-05-01 13:20:03 UTC
This bug can be "avoided" by forcing bDontSplit to false in sw/source/core/layout/tabfrm.cxx

bDontSplit = false;   //proof of concept to avoid bug 34957
    if ( bDontSplit )
    {
        while ( GetFollow() && !GetFollow()->IsJoinLocked() )

However, at this point where we need to make a decision based on table size, the table size appears not be be calculated yet - and no easy way to do that...
Comment 15 Justin L 2015-05-04 08:11:03 UTC
Created attachment 115298 [details]
Zip containing several example documents and PDF evidence.

Proposed bugfix submitted:  https://gerrit.libreoffice.org/15617

This bug should not be considered a MAB. The workaround is simply to turn off “keep with next” if the table is so large that it is a meaningless setting anyway.  Since the bug/fix changes the current behaviour of ODT formatted documents, I'll only submit to the 5.0 tree to give others time to identify any unintended side effects, and not push to the (almost) stable 4.4 tree.

The bug mentioned in comment #13 is not connected with this fix.  .DOC format does not have a “keep with next” table setting, only paragraph settings.  This bug / fix does not deal with paragraph settings, only the table setting.

Provided is a suite of test documents.  The incorrect behaviour in exampleSuite-odt-LO436.pdf was produced on Windows.  The correct behaviour was produced on an Ubuntu 14.04 derivative.

Example 1: simple test that works in all cases, since everything fits on a single page.

Example 2a: demonstrates comment #2 and the reason why this is marked as a MAB. If the preceding paragraph / table / following paragraph were larger than one page, the preceding paragraph's “keep with next” would be ignored.  That is now fixed.

Example 2b: demonstrates both “keeps” working together properly.  This was already working before, and is not broken by the “fix”.

Example 3: demonstrates when it is proper for the table to start on a new page.  This was already working before, and is not broken by the “fix”.

Example 4: demonstrates what happens when the table itself fits on the page, but there is not enough room for the “kept” paragraph.  This was not working before, and is still identically “broken” (in my opinion) after the “fix”.  However, it is similar behaviour to MS Word's paragraph setting, so I'm not going to try and change this behaviour.

Example 5: demonstrates what happens if the table itself is too big to fix on a single page.  This was the actually reported bug.  Before, the table started on a brand new page.  Now, it does not leave a gap.

Example 6: is the same as example 4 except that the table is larger than one page.  Before, the table started on a brand new page.  Now it does not leave a gap.
Comment 16 Justin L 2015-06-06 17:01:11 UTC
proposed patch to make .doc layout similar to .odt layout submitted at https://gerrit.libreoffice.org/#/c/16123/1
Comment 17 Justin L 2015-06-09 05:50:11 UTC
Created attachment 116396 [details]
fairly comprehensive testing suite with results PDFs (updated)

example 2b.doc required some anti-looping code, so I added 
        if (bMoveable &&
            !(bMovedFwd && bEmulateTableKeep) )

Looping also occurred if bTryToSplit (a row in half) was enabled.  Split would call lcl_RecalcSplitLine and several validation checks related to ContainsContent() would fail.  So I forced splitting mid-row off with 
            if ( !IsKeepFwdMoveAllowed(bEmulateTableKeep) )
            {
                bTryToSplit = false;
            }
Comment 18 Marc Kaulisch 2015-10-18 07:00:56 UTC
Justin_L, is your fix integrated into 5.0.0.3?
I still have a weired behaviour.
Use case (very often for me):
Table larger than a page and I want to keep the next paragraph directly to the table - then table starts at new page 
- this behaviour is not nice because I say that the table can be split

Then I add a caption at the beginning of a table: Now I have a caption on a anew page follow by empty space, then a table over a page and then the paragraph that really hangs at the table?
In my opinion this is bad behaviour?

My expectation would be that the caption is more important then the next paragraph...

I use 5.0.0.3 on a Windows 10 (64bit) computer.
Comment 19 Marc Kaulisch 2015-10-18 07:04:16 UTC
Created attachment 119708 [details]
my little example for the keep with paragraph test

here my little example created with 5.0.3.1
Comment 20 Marc Kaulisch 2015-10-18 07:04:51 UTC Comment hidden (no-value)
Comment 21 Commit Notification 2015-12-03 19:13:24 UTC
Justin Luth committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=04164c70f23ff49c308f62f36e45a589afa168d0

tdf#34957 - don't push multi-page table to next page.

It will be available in 5.2.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 22 Commit Notification 2015-12-12 16:24:52 UTC
Matúš Kukan committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=0769ad9284c4d71ab11e4460c0f380eca8d4c788

test for tdf#34957: change font in test document to make it work here

It will be available in 5.2.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 23 Justin L 2017-05-19 12:57:31 UTC
(In reply to Justin L from comment #17)
> fairly comprehensive testing suite with results PDFs (updated)

Kerning needs to be enabled (starting in 5.4) for these tightly formatted documents to look right.  [Default paragraph - Position - enable Pair Kerning.]
Comment 24 Justin L 2020-05-05 08:27:24 UTC
(In reply to Justin L from comment #17)
> fairly comprehensive testing suite with results PDFs (updated)

Some of the DOCX files (like 2a) have "keep-with-next" set on supposedly "normal" paragraphs, so watch out for that. Round-trip those first before testing.

Test 4d for .doc fails to split table after LO 6.0 commit 9206a08ada00e8762c4a634f242bd566028964bb by Author: Eike Rathke on Fri Nov 17 11:03:45 2017 +0100
    Upgrade to ICU 60.1
    
which I assume just exposed a problem with the calculation with header size