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
This is indeed a minor bug in the layout... Taking it.
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.
Thanks for interesting in this problem "Version" is most old version where bug appears, not current version Changing back to 3.3.1
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.
(This is an automated message.) Setting priority to highest as this is a 4.0 MAB. This is part of an effort to make the importance of MAB reflected in priority too.
Moving to mab4.1 (Bug 60270) because: - 4.0 reached EOL (End Of Life) - bug confirmed in 4.1
reproducible with 4.2.4.2 too moving to mab4.2 list since 4.1.x is EOL
reproducible with 4.3.0.1
bug is still existent in 4.3.1.1
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
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.
still present in 4.4.0 beta1 moving to mab4.3 list since 4.2. reached EOL
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...
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...
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.
proposed patch to make .doc layout similar to .odt layout submitted at https://gerrit.libreoffice.org/#/c/16123/1
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; }
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.
Created attachment 119708 [details] my little example for the keep with paragraph test here my little example created with 5.0.3.1
(In reply to Marc Kaulisch from comment #18) > 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. Of course I use 5.0.3.1... one zero too much...
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.
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.
(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.]
(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