Download it now!
Bug 129619 - Layout: Table breaks in unexpected places when all paragraphs marked keep-with-next (see comment 12 and comment 14)
Summary: Layout: Table breaks in unexpected places when all paragraphs marked keep-wit...
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.1.0.4 release
Hardware: All All
: low normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, regression
Depends on:
Blocks: DOCX-Tables Writer-Table-Properties-Dialog
  Show dependency treegraph
 
Reported: 2019-12-26 00:29 UTC by mkassler
Modified: 2020-02-27 10:22 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
Test ODT (8.61 KB, application/vnd.oasis.opendocument.text)
2019-12-28 11:35 UTC, Timur
Details
ODT document (24.56 KB, application/vnd.oasis.opendocument.text)
2020-02-04 09:04 UTC, mkassler
Details
DOCX document showing bug between p.3 and p.4. (16.21 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2020-02-04 09:09 UTC, mkassler
Details

Note You need to log in before you can comment on or make changes to this bug.
Description mkassler 2019-12-26 00:29:59 UTC
Description:
When saving a Writer Table in Word .docx format, using 6.4 RC1 in Windows 64-bit, when 'Keep with Next Paragraph' has been selected and saved, this feature is not remembered when reopening the document. It would be useful to enable saving this feature.

Actual Results:
Keep with Next Paragraph feature selection in a Writer Table is forgotten when reopening document stored in .docx format (Windows 64)

Expected Results:
Keep with Next Paragraph command should be remembered and implemented when reopening document


Reproducible: Always


User Profile Reset: No



Additional Info:
Remember the Keep with Next Paragraph command
Comment 1 Xisco Faulí 2019-12-26 15:13:53 UTC Comment hidden (obsolete)
Comment 2 mkassler 2019-12-26 21:41:47 UTC
UNCONFIRMED.

When I set up a table in a Writer document that has more than one page I do not want the document to introduce page breaks between rows of the table. Ticking the box 'Keep with next paragraph' in Table Options does this.
        However, if I then save the document and reopen it the 'Keep with next paragraph' option is no longer ticked, and page breaks have been incorrectly introduced which have to be manually corrected.
Comment 3 Dieter 2019-12-27 13:19:11 UTC
I confirm it with

Version: 6.5.0.0.alpha0+ (x64)
Build ID: e26d89371f0e4f41476c9a99be01d98dedb76776
CPU threads: 4; OS: Windows 10.0 Build 18362; UI render: default; VCL: win; 
Locale: de-DE (de_DE); UI-Language: en-GB
Calc: threaded
Comment 4 Timur 2019-12-28 11:35:33 UTC
Created attachment 156811 [details]
Test ODT

Confirmation only is of little practical use. Let's triage a bug, adding test ODT.

Issue was reported for DOCX but is the same also for DOC.
Reopening is not explained where, and it's important to determine if filesave or fileopen, but I see that it's the same with reopen in LO and MSO.
Issue started already in OO/LO 3.3 so I formally mark Inherited.
But there was a significant change. DOC/DOCX saved in 3.3 would open as if there's no 'Keep with Next Paragraph' while at least current LO 6.5+ opens DOC/DOCX as if there *is* 'Keep with Next Paragraph', although it's not marked.

So bug seems to be just keeping the mark.
Comment 5 Timur 2019-12-28 12:01:50 UTC
Old wrong filesave behavior is in LO 5.0 and new correct in LO 5.2.
I set bibisectRequest to determine that improvement that needs to be accomplished in this bug with status of 'Keep with Next Paragraph'.
Comment 6 Aron Budea 2020-02-01 22:19:48 UTC
The improvement happened with the following commit, bibisected using repo bibisect-linux-64-5.2.

https://cgit.freedesktop.org/libreoffice/core/commit/?id=0d127baed75929e744d5b6249f510012cfbc0e88
author		Justin Luth <justin_luth@sil.org>	2015-11-27 19:03:40 +0300
committer	Justin Luth <justin_luth@sil.org>	2016-01-18 04:30:59 +0000

tdf#91083 - .doc: emulate table keep-with-next paragraph
Comment 7 Justin L 2020-02-03 05:46:07 UTC
(In reply to mkassler from comment #0)
> Keep with Next Paragraph command should be remembered and implemented when
> reopening document
Microsoft does not have a "keep with next paragraph" option for tables. An attempt to "figure it out on load" failed.  That attempt was "tdf#91083 ww8import: set table keep/split properties if emulated".

Problems with that emulation were seen in bug 104333 when:
tables that span multiple pages, and rows greater than one page
caused problems, so just removing the enhancement that tried
to emulate what the original odt looked like.

Since MS formats don't have a keep-with-next table-property and because a prior attempt to emulate that failed, I'm going to close this bug report, OK?
Comment 8 Justin L 2020-02-03 10:51:27 UTC
Michael emailed:
> Not OK. When a table spanning multiple pages is opened in Microsoft Word
> no page breaks are introduced between rows. LibreOffice puts in page breaks
> between rows. If 'Keep with Next' is selected then this mistake is fixed,
> but LibreOffice does not retain the 'Keep with Next' property.
>
> This bug has NOT been fixed, and should be fixed. This bug has been CONFIRMED.

Michael - please attach an .ODT example document that demonstrates the problem you are describing here (and in comment 2). See comment 1's helpful suggestions on a good sample document.
Comment 9 mkassler 2020-02-04 03:07:14 UTC
When I save my table as an .odt document the bug goes away. The bug appears when saving the document as a .docx document. So I don't see how sending you an .odt table would help.

Is it feasible for LibreOffice to check .docx documents to see if 'Keep with Next' has been selected for a table, and, if so, to retain the 'Keep with Next' setting when the table reopens? The bug is that LibreOffice does not retain the 'Keep with Next' setting after the document is closed.

Thanks for your help.
Comment 10 Justin L 2020-02-04 05:16:25 UTC
(In reply to mkassler from comment #9)
> When I save my table as an .odt document the bug goes away. The bug appears
> when saving the document as a .docx document. So I don't see how sending you
> an .odt table would help.
That's exactly why we want an .odt file :-).  We want to have a file that is "working properly".  All we have to do is save that example as a .docx and then we will see the problem you are mentioning.  So it gives us both a "good" and a "bad" reference point.

> Is it feasible for LibreOffice to check .docx documents to see if 'Keep with
> Next' has been selected for a table, and, if so, to retain the 'Keep with
> Next' setting when the table reopens?
Microsoft formats simply do not have a "keep with next" setting for tables. That's what I was explaining in comment 7.
Comment 11 Timur 2020-02-04 08:25:06 UTC
Reporter was asked in comment 8 for a file, which he didn't provide. Comment 9 is just repeating that does not add value. I attached ODT in comment 4.
Comment 12 mkassler 2020-02-04 09:04:33 UTC
Created attachment 157632 [details]
ODT document

As requested here is an .odt document in which the rows are kept together. When this document is saved as a .docx document the rows are no longer kept together.
Comment 13 mkassler 2020-02-04 09:09:59 UTC
Created attachment 157633 [details]
DOCX document showing bug between p.3 and p.4.

Although Microsoft Word does not have a 'keep with next' setting as a Table property, one can select 'keep with next' by going to the Paragraph format for a paragraph within a table.

I hope that this bug can be fixed.
Comment 14 Justin L 2020-02-04 10:14:37 UTC
Now we are getting somewhere. This is a layout bug - comment 13's document looks fine in MSWord 2003. It also looked fine in LibreOffice 4.0.

Bisected to LO 4.1 commit 84203fab20b7eb98f0d3667e6626f5c2139e5a7f by Oliver-Rainer Wittmann on 2013-05-11 20:52:52 +0100
Resolves: #i120016# refine condition for allowing split of a table row

https://cgit.freedesktop.org/libreoffice/core/commit/?id=84203fab20b7eb98f0d3667e6626f5c2139e5a7f

There is almost no need to set "keep with next" on a multi-page table. The only reason I can think of is to make sure that a caption for the table is not stranded, and so the table SHOULD break early in order to keep a part of the table with the caption.

The workaround for this particular document (which has no caption) is to select the whole table, and then to turn off the PARAGRAPH property "keep with next" (and don't re-enable it for the table either).
Comment 15 Justin L 2020-02-05 09:54:05 UTC
(In reply to mkassler from comment #13)
> I hope that this bug can be fixed.
It is highly unlikely that anyone will volunteer to take on this bug. Layout issues are super-nasty. Since this problem is a result of unnecessary document design (purposeless keep-with-next paragraph attributes) and the workaround/cleanup easily fixes the problem, it is very low priority.

I certainly will not be trying to hang myself with this issue...
Comment 16 mkassler 2020-02-05 22:46:33 UTC
Thanks for advising how to achieve the desired result. I suggest that the Writer Guide be updated to include this solution.
Comment 17 Timur 2020-02-26 08:54:52 UTC
Reporter set status Fixed, but that's reserved in Bugzilla when there was a fix, as explained in Status link. 
So, from Justin's explanation this is WontFix (to change code) or WorksForMe (to use with workaround). 
Or we may convert to Documentation type, which I prefer. 

But before we do it, let's clarify what's the workaround: I turned off paragraph property "keep with next" in this 10 pages .odt *but* got the same issue with table split and 11 pages when saving to .docx and reopening in LO.

Note: Same commit caused bug 89007 that was resolved. It's not clear which use cases it fixed.
Comment 18 Justin L 2020-02-27 09:15:49 UTC
(In reply to Timur from comment #17)
> But before we do it, let's clarify what's the workaround: I turned off
> paragraph property "keep with next" in this 10 pages .odt *but* got the same
> issue with table split and 11 pages when saving to .docx and reopening in LO.
It looks like comment 12's document was created by saving the .docx file as .odt and then adding in the table-keep-with-next. (Thus the paragraph properties are already tainted with the emulated keep-with-next - a clean ODT wouldn't normally have that.)

So the workaround for "Donald Hex.odt" is to both remove keep-with-next from all the paragraphs, and also from the table properties.
Comment 19 Timur 2020-02-27 10:22:35 UTC
Thanks. 
It's always good to update documentation, but use case here is not straight, so I'll just close as WFM.