Description: For a docx file created with MS Office, when there are two tables with few rows and text wrapping on another table is set to Around. It is being correctly rendered with older (7.6.7) but LibreOffice 24.2.3 renders it differently. The later table is overlapped to first table. Steps to Reproduce: 1. Create a document with MS Office, and insert two tables with a few rows in the header. 2. Set the text wrapping to Around on the later table and save the file as docx file 3.Open the document with Writer latest version. Actual Results: The later table on the header overlapped with first table. Expected Results: These table should not be overlapped. Reproducible: Always User Profile Reset: No Additional Info: MS Office 365
Created attachment 194242 [details] Docx file has 2 tables in header.
Created attachment 194246 [details] screenshot comparison between LO 24.8alpha1 (left) and MS 365 (right) Version: 24.8.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: ae798781ef4df7a1fdef13af0bc459bf4f6e7b4c CPU threads: 8; OS: Linux 6.5; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: CL threaded
I see the issue in a recent daily build, but 7.6.7 didn't look like MS 365 either. The tables already overlapped in LO 5.0.0.5. In 4.0.0.3, they didn't overlap (but they weren't aligned). A bibisect could be interesting, but I wouldn't call it a regression yet.
(In reply to ramchandrakc25 from comment #0) > It is being correctly rendered with older (7.6.7) but LibreOffice 24.2.3 > renders it differently. I'd be interested to see a screenshot of what you see in 7.6.7.
Created attachment 194261 [details] Screenshot for opening a file in different LibreOffice version and MS Office
Created attachment 194262 [details] Docx file has 2 tables with data in header
(In reply to Stéphane Guillou (stragu) from comment #4) > (In reply to ramchandrakc25 from comment #0) > > It is being correctly rendered with older (7.6.7) but LibreOffice 24.2.3 > > renders it differently. > I'd be interested to see a screenshot of what you see in 7.6.7. I am sorry that I did not test it fully before creating the issue, but when there was data on the table, it was being rendered correctly, and the LibreOffice version rendering it correctly was (6.4.7). I have attached the screenshots of all three versions (6.4.7 and 7.6.7 and MS Office)
I observe the following: - Version 6.x - vertical alignment is correct - horizontal alignment incorrect Version 7.x - vertical alignment is incorrect - horizontal alignment is correct. However on version 7.x if the document is changed for example by pressing an enter before the table, the vertical alignment auto-corrects itself. This rendering correction happens for this working session. If the file is closed and reopened, the issue is there again. It's as if the vertical alignment is ignored on the initial run and works correctly if a modification happens.
Bibisected with linux-64-7.6. Unfortunately there were many commits where it crashed upon opening the file (also on Windows). I did get a range and after some manual massage and some scripted git show passes I could examine the commits and their messages. The commits in the bibisect log show all source commits in double, so I had to use this to filter out dupes (uniq -u did not work for some reason, no matter if using sort): awk '!a[$0]++{print}' < /path/to/tdf161197_bisectlog_non_unique.txt This was the final script for the range of source commits (similar was used to first get the bibisect commits): while IFS="" read -r p || [ -n "$p" ]; do git show --no-patch "$p" >> /path/to/tdf161197_bisectlog.txt; done < /path/to/tdf161197_bisect_range_76.txt As the tables in the .docx are inside a header, this looked relevant from the listed commits: commit 16b59cee44c7f728b2fe6d7b624c494f649ee79f Author: Miklos Vajna <vmiklos@collabora.com> Date: Tue Apr 18 08:16:02 2023 +0200 sw floattable, layout: don't split inside headers/footers CppunitTest_sw_ww8export2's testTdf128700_relativeTableWidth had a layout loop in the SW_FORCE_FLY_SPLIT=1 case. This seems to happen because the footer had a big floating table, which doesn't fit the anchor's upper, but adding more pages won't help the table to fit. Fix the problem by not trying to split floating tables in headers/footers. An alternative would be to filter this out at import time, but then we would loose the setting on DOCX/DOC roundtrip, which is not ideal. It was runnable and showed the current state. Let's ask Miklos what he thinks.
Thanks for the bisect. This is definitely a bug that needs fixing, but I would classify it as "implementation error" than a regression, if this was truly working (by accident) when we tried to split floating tables in headers/footers. You can easily see that trying to split a floating table in a header and hoping that the next page will have more space for it is not really a sane idea :-) the very purpose of the header is it it'll be also repeated on the next page as well.