Created attachment 194189 [details] Example for the bug Text in 2 columns with the feature 'Evenly distribute contents to all columns'. Table property 'Allow table to split across pages and columns' unchecked. There isn't enough space on a certain page, so the splitting feature is considered. After saving the file and opening again, the 9 row table in the attached example is split between 5 columns and 3 pages (!). After hitting enter or deleting an empty line right before the table, the program changes the table to a form as intended. But that's not ideal in a 300-500 pages document. The bug is not present when the 'Evenly distribute contents to all columns' is unchecked. Possible solution: the 'Allow table to split across pages and columns' should be a stronger parameter than 'Evenly distribute contents to all columns'.
After further testing, the Writer splits all tables in a weird way when in columns regardless of the table property 'Allow table to split across pages and columns'. There are differences in the method, but all are buggy. So the main problem is the feature 'Evenly distribute contents to all columns' when it interacts with tables.
Reproducible Version: 24.2.3.2 (X86_64) / LibreOffice Community Build ID: 433d9c2ded56988e8a90e6b2e771ee4e6a5ab2ba CPU threads: 16; OS: Windows 10.0 Build 22631; UI render: default; VCL: win Locale: es-ES (es_ES); UI: en-US Calc: CL threaded and Version: 24.8.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: 658a212585c56540a17c41111e6829716d4ef4e3 CPU threads: 16; OS: Windows 11 X86_64 (10.0 build 22631); UI render: default; VCL: win Locale: es-ES (es_ES); UI: en-US Calc: CL threaded
On my installed LOs: First with the issue Version: 7.4.7.2 (x64) / LibreOffice Community Build ID: 723314e595e8007d3cf785c16538505a1c878ca5 CPU threads: 16; OS: Windows 10.0 Build 22631; UI render: Skia/Raster; VCL: win Locale: es-ES (es_ES); UI: es-ES Calc: CL The last one that works Version: 7.2.7.2 (x64) / LibreOffice Community Build ID: 8d71d29d553c0f7dcbfa38fbfda25ee34cce99a2 CPU threads: 16; OS: Windows 10.0 Build 22631; UI render: Skia/Raster; VCL: win Locale: es-ES (es_ES); UI: en-US Calc: CL
Created attachment 194196 [details] Sample It's not totally clear which steps are needed to trigger the bug with the original example. However I'm able to reproduce it: 1. Open the sample file 2. Delete the yellow highlighted text 3. Save & File -> Reload Fine with Version: 7.1.8.0.0+ (x64) / LibreOffice Community Build ID: a94b58277c7aeaa83ce14347cd0b8f7137969d03 CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: default; VCL: win Locale: nl-NL (nl_NL); UI: en-US Calc: CL
(In reply to Telesto from comment #4) > Created attachment 194196 [details] > Sample > > It's not totally clear which steps are needed to trigger the bug with the > original example. > > However I'm able to reproduce it: > 1. Open the sample file > 2. Delete the yellow highlighted text > 3. Save & File -> Reload Bibisected with linux-64-7.3, the same look, but corrected simply by clicking into the table, started in 6433dc223f6d21570e7132c4a580d186a5d5a334 Revert "Revert "sw_fieldmarkhide: init fieldmark mode from options"" Bibisecting with linux-64-7.5, the correction started requiring Enter instead of clicking with c605283ad6785dea762feab5fdffd9d27e75c292 sw: fix spurious layout invalidation from ~SwCallLink() There are other reports referencing these commits.