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
Created attachment 186105 [details] Test document showing the buggy behavior
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
Created attachment 186482 [details] Testcase. Insert table in footer and save as docx -> Expected result
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
Created attachment 186486 [details] Broke the testcase Testcase reduced and reproduced buggy behavior
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.
(In reply to Dieter from comment #6) > 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 Bibisected with linux-64-4.3 to 1c6fb266567c8e397e3c65663b21f0fa50696aa5 fdo#75260: These old hacks no longer make sense. Bug 106390 referenced this commit and has some fixes, but I don't see attachment 186486 [details] in a working state in 5.4, 6.1 or 6.2.