Download it now!
Bug 123116 - Always allow table row to break across pages when longer than a page
Summary: Always allow table row to break across pages when longer than a page
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: All All
: medium enhancement
Assignee: Justin L
URL:
Whiteboard: target:7.0.0
Keywords:
Depends on:
Blocks: Writer-Tables-Enhancements DOCX-compatiblityMode-15
  Show dependency treegraph
 
Reported: 2019-02-01 18:46 UTC by Aron Budea
Modified: 2020-05-12 16:41 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
Sample ODT (9.59 KB, application/vnd.oasis.opendocument.text)
2019-02-01 18:46 UTC, Aron Budea
Details
the result (6.95 KB, application/pdf)
2020-05-10 12:49 UTC, BogdanB
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Aron Budea 2019-02-01 18:46:58 UTC
Created attachment 148852 [details]
Sample ODT

Table rows have the following setting: Allow row to break across pages and columns.

The setting is normally enabled, but when disabled, and when a table row is taller than a page, the rest of the row becomes hidden, and falls of the page.
I can't find any reasonable explanation of this behavior, and suggest changing it to always allow a row to break when it reaches full page length, regardless of the setting.
 
Attaching a sample, it also includes a piece of text that gets hidden due to the current behavior. Changing the behavior could lead to the layout of existing files getting changed, though I can't imagine any files purposefully having such a table (apart from hiding something).

The behavior also has interop aspects with MS Word:
- DOC files and DOCX files in compatibility mode behaves the same as Writer does currently,
- DOCX files not in compatibility mode have the layout as proposed: the very tall row starts on a new page, but is allowed to break further to the next page.

Let's not deal with the interop part here, though. And frankly, I wouldn't care if LO changed the behavior, and treated all files like that, unless there is a compelling argument of possible side-effects.
Comment 1 Mike Kaganski 2019-02-02 09:47:08 UTC
Actually, I wholeheartedly support this. It doesn't make sense to insist on some pedantic to-the-letter conformance to standards in cases of invalid layout arising from such conformance - simply because the invalid layout would be considered as a program error.

By the way, is there actually a requirement to disallow the breaking at all costs in the standard? I suppose it would be better to fix standard if so.
Comment 2 Xisco Faulí 2019-03-13 19:04:51 UTC
Moving to NEW based on comment 1
Comment 3 Justin L 2020-03-05 04:47:49 UTC
WIP patch: https://gerrit.libreoffice.org/c/core/+/90005

The good thing about the current method is that is DOES match MSWord 2003. So I probably should at the minimum try to match Word compatibility mode. Whether to do a LO compatibility mode check is another question... Probably if Word thought they needed to do it with a compat switch, LO should do the same. The difference is that MSWord has a "change this document out of compatibility mode" function, but I don't recall seeing anything like that in LO.
Comment 4 Justin L 2020-03-06 09:14:55 UTC
Tested with Word 2016, 2013, and 2010. All open a .doc WITHOUT splitting the row - like LO currently - taking up only one page (plus a blank page).

2013/2016 open an .odt file by splitting the row - taking up three pages. 2010 however looks the same as .doc - all on one page.

For .docx, all open WITHOUT splitting the row IN COMPATIBILITY MODE (when compatibleMode is not defined, or is <= 14 which is 2010).  If compatibleMode is set to 15 (for 2013/2016), then it splits the row - taking up three pages. So this means that 2010 never splits the row.

This all confirms everything that Aron said initially. Since Word 2010 will be end of life in eight months, its behaviour has less significance.

However, I think we might as well worry about interoperability at the same time. With a layout compat flag, we can avoid regressions in LO and at the same time match compatibility with how MSO handles the .doc and .docx files.
Comment 5 Mike Kaganski 2020-03-06 09:28:55 UTC
(In reply to Justin L from comment #4)

I don't think we should think about compatibility here. The problematic case is when there's a too tall row; and I don't see why should we care about such an invalid legacy layout case. The logic behind compatibility option might be "this breaks existing documents consciously created like that" - but I fail to see why would someone ever consciously do that.
Comment 6 Justin L 2020-03-06 09:42:53 UTC
(In reply to Mike Kaganski from comment #5)
Interoperability is the big concern here. Any documents authored in LO might be unusable in MSO.  At least if they look bad in LO, then the user will try to fix them up.
Comment 7 Commit Notification 2020-03-12 08:11:09 UTC
Justin Luth committed a patch related to this issue.
It has been pushed to "master":

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

tdf#123116 sw layout: allow rows larger than page to split anyway

It will be available in 7.0.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 Justin L 2020-03-20 05:14:27 UTC
In reply to Justin L from comment #4)
> For .docx, all open WITHOUT splitting the row IN COMPATIBILITY MODE (when
> compatibleMode is not defined, or is <= 14 which is 2010).  If
> compatibleMode is set to 15 (for 2013/2016), then it splits the row - taking
> up three pages.

Setting compat=15 was done in https://git.libreoffice.org/core/commit/f25985c55541cbbc9a4fc79e660592d3d0485196   for bug 131304


So at this point, Word and LO should act very compatibly. A patch to remove the artificial page-break in LO only (as requested in comment 5) is at https://gerrit.libreoffice.org/c/core/+/90131
Comment 9 Commit Notification 2020-04-04 12:03:52 UTC
Justin Luth committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/60a1b40cf363a54b64b84afcfad7fd08bc6ce770

tdf#123116 sw layout: don't "page-break" before oversized row

It will be available in 7.0.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 BogdanB 2020-05-10 12:49:06 UTC
Created attachment 160595 [details]
the result

This is what I get in
Version: 7.0.0.0.alpha1
Build ID: 6a03b2a54143a9bc0c6d4c7f1...
CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: gtk3; 
Locale: ro-RO (ro_RO.UTF-8); UI: en-US
Calc: threaded

It's ok like that? I am not sure about the final results because you were talking about 3 pages, and I have just 2.
Comment 11 Justin L 2020-05-11 17:36:13 UTC
(In reply to BogdanB from comment #10)
> It's ok like that? I am not sure about the final results because you were
> talking about 3 pages, and I have just 2.
Three pages is how MS Office is going to show it, and how it looks with only comment 7's patch.

The way you see it with 2 pages seems to be the "most intelligent" way of handling it - i.e. not leaving large blocks of empty space that serve no purpose.

So yes, the intention is that it will only take two pages.
Comment 12 BogdanB 2020-05-12 16:41:02 UTC
Based on comments 10 and 11 is ok. Verified.