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: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: All All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Writer-Tables-Enhancements
  Show dependency treegraph
 
Reported: 2019-02-01 18:46 UTC by Aron Budea
Modified: 2020-02-04 09:15 UTC (History)
2 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

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