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.
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.
Moving to NEW based on comment 1
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.
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.
(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.
(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.
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.
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
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.
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.
(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.
Based on comments 10 and 11 is ok. Verified.