Bug 154302 - Formatting nested tables spanning multiple pages is broken when "Allow row to break across pages and columns" is disabled on parent table (document specific)
Summary: Formatting nested tables spanning multiple pages is broken when "Allow row to...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
7.5.1.2 release
Hardware: x86-64 (AMD64) Windows (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Writer-Tables-Nested
  Show dependency treegraph
 
Reported: 2023-03-21 08:17 UTC by n.jeker
Modified: 2023-04-10 13:49 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:


Attachments
Test document showing the buggy behavior (22.72 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2023-03-21 08:18 UTC, n.jeker
Details
Testcase. (13.44 KB, application/vnd.oasis.opendocument.text)
2023-04-05 08:07 UTC, Dieter
Details
Broke the testcase (10.85 KB, application/vnd.oasis.opendocument.text)
2023-04-05 10:22 UTC, n.jeker
Details

Note You need to log in before you can comment on or make changes to this bug.
Description n.jeker 2023-03-21 08:17:56 UTC
Description:
Creating a nested table that spans over multiple pages breaks as soon as an additional table is inserted in the document footer, see attached test document.

Steps to Reproduce:
1. Create two levels deeply nested table in document body
2. Fill table with text spanning multiple pages
3. Add a table in the documents footer

Actual Results:
Broken formatting, stray table lines over the footer

Expected Results:
Table continuation on new page without overlapping the footer


Reproducible: Always


User Profile Reset: No

Additional Info:
Version: 7.5.1.2 (X86_64) / LibreOffice Community
Build ID: fcbaee479e84c6cd81291587d2ee68cba099e129
CPU threads: 16; OS: Windows 10.0 Build 22621; UI render: Skia/Raster; VCL: win
Locale: en-US (en_CH); UI: en-US
Calc: threaded
Comment 1 n.jeker 2023-03-21 08:18:58 UTC
Created attachment 186105 [details]
Test document showing the buggy behavior
Comment 2 Dieter 2023-04-05 08:05:55 UTC
N.Jeker, thank you for reporting the bug. Test document is a docx-file. Does the bug only occur after saving a odt-file as docx? Could you add an odt-file in this case as test file?

=> NEEDINFO

I can't confirm with a file created on my own. Tested with odt and docx.

Version: 7.5.2.1 (X86_64) / LibreOffice Community
Build ID: e8bf3b441b8370f8440b0339fd9490765a8d57ca
CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win
Locale: de-DE (de_DE); UI: en-GB
Calc: CL threaded
Comment 3 Dieter 2023-04-05 08:07:01 UTC
Created attachment 186482 [details]
Testcase.

Insert table in footer and save as docx -> Expected result
Comment 4 n.jeker 2023-04-05 10:20:32 UTC
Dieter, thanks for looking into this and trying to reproduce it.

The document I initially had the problem with came directly from Word, I tried to reduce it as much as possible. If I convert my test document to odt, the incorrect rendering is still visible. Removing the footer content and empty columns on the tables didn't fix it.

I narrowed down the culprit to disabling "Allow row to break across pages and columns" in the parent tables table options. Sadly, the behavior isn't consistent, there is likely a second setting influencing it.

I was able to reduce your test document to two nested tables each with only a single cell. Disabling "Allow row to break across pages and columns" on the parent table breaks it, enabling it again fixes it. Sadly, I wasn't able to reproduce the bug in a new document, I'm likely missing a second setting influencing the bug.



I hadn't access to a Windows machine, but the behavior is the same on macOS.

Version: 7.5.1.2 (X86_64) / LibreOffice Community
Build ID: fcbaee479e84c6cd81291587d2ee68cba099e129
CPU threads: 4; OS: Mac OS X 12.6.3; UI render: default; VCL: osx
Locale: de-CH (en_CH.UTF-8); UI: en-US
Calc: threaded
Comment 5 n.jeker 2023-04-05 10:22:01 UTC
Created attachment 186486 [details]
Broke the testcase

Testcase reduced and reproduced buggy behavior
Comment 6 Dieter 2023-04-10 13:49:19 UTC
I confirm behaviour for this specific document. Let's set status to NEW, but since we can't reproduce it from scratch I don't know , if a developer will try to fix it.

Steps:
1. Open attachment 186486 [details] => Document shows buggy behaviour
2. Delete some paragraphs
3. Strg+Z => bug is reproducible
4. Delete some paragraphs
5. In parent table diable "Allow row to break across pages and columns"
6. Add some paragraphs => O. K.