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.
Keep with Next Paragraph feature selection in a Writer Table is forgotten when reopening document stored in .docx format (Windows 64)
Keep with Next Paragraph command should be remembered and implemented when reopening document
User Profile Reset: No
Remember the Keep with Next Paragraph command
Thank you for reporting the bug. Please attach a sample document, as this makes it easier for us to verify the bug.
(Please note that the attachment will be public, remove any sensitive information before attaching it.
See https://wiki.documentfoundation.org/QA/FAQ#How_can_I_eliminate_confidential_data_from_a_sample_document.3F for help on how to do so.)
I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' once the requested document is provided.
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.
I confirm it with
Version: 188.8.131.52.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
Created attachment 156811 [details]
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.
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'.
The improvement happened with the following commit, bibisected using repo bibisect-linux-64-5.2.
author Justin Luth <email@example.com> 2015-11-27 19:03:40 +0300
committer Justin Luth <firstname.lastname@example.org> 2016-01-18 04:30:59 +0000
tdf#91083 - .doc: emulate table keep-with-next paragraph
(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?
> 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.
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.
(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.
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.
Created attachment 157632 [details]
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.
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.
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
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).
(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...
Thanks for advising how to achieve the desired result. I suggest that the Writer Guide be updated to include this solution.
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.
(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.
It's always good to update documentation, but use case here is not straight, so I'll just close as WFM.