Created attachment 198834 [details] forum-mso-de-130675.docx: clear example document I have seen a lot of documents affected by 25.2 commit 4f5b896d004af023f210f235aeafa9abc50068d2 Author: Oliver Specht on Thu Jun 27 08:57:43 2024 +0200 tdf#155229 Calculate row height incl. border if 'atLeast' is set In most of them, I assumed it just exposed some other spacing issue. But this particular document shows a very large difference from MS Word 2019 on the very first page (where before we were pretty close to per-pixel perfection), so I think it probably exposes an edge case or a bug and is worth investigating. Steps to reproduce. 1.) open forum-mso-de-130675.docx Notice that the last row on page 1 contains the "Text" "Olivia...". It should have 3 more rows, ending with "Hallo. (conter) Ich bin Simon." A4 paper size, Calibri font, row height atLeast 1.5cm - I don't see anything jumping out at me as to what would be wrong here, but something is definitely amiss. Found by Collabora's mso-test Since I'm creating an issue about this, let me at least mention the other documents I found. -forum-mso-en-2385.docx: 54 pages instead of 42 pages - mostly near end of doc -forum-mso-de-130675.docx: 6 pages instead of 4 pages. -forum-mso-en-18195.docx: table doesn't quite fit on first page... -ooo50668-1.doc: loads slowly now - off by one line before page break. -forum-mso-en4-129146.doc: off by one line
Created attachment 198835 [details] forum-mso-de-130675.docx_mso.pdf: how it looks in Word 2019 (In reply to Justin L from comment #0) > -forum-mso-de-130675.docx: 6 pages instead of 4 pages. Duhh - that is the one I'm reporting on...
(In reply to Justin L from comment #0) > before we were pretty close to per-pixel > perfection) That is a bit of an exaggeration, but we did happen to be a whole lot closer... First - ignore the horizontal shift and table width difference. The table is 102%, and we simply can't handle that. Another thing rather unique about this document is that only the first row follows the TABLE's cell margins. The other rows have their own custom border spacing. We can't (really) handle that either. (reported as bug 165424) However, this document has me pretty convinced that comment 0's patch is simply, fundamentally wrong, and probably should just be reverted. 1.) we can't trust what the box says its border width or border spacing are. 2.) IIUC, this patch was trying to only add the BORDER width. However, it is actually adding both the top border and the top border spacing. [To add the border alone would use CalcLineWidth().] So in the case of this document, it is adding the border padding (0.5cm or 284) and the hairline border (10), which is why the rows are so much taller than they should be. 3.) Based on some testing I have done, it suggest that both the top and bottom borders are "added" to the spacing for atLeast heights, even in our IsCollapsingBorders() case.
Created attachment 199433 [details] 164907_atLeast_vs_exact.docx: example document This is even weirder than expected. "exact" is affected by bottom border spacing, but not by top spacing. The table grows if ANY bottom spacing is added. "atLeast" also affected by the top border line
(In reply to Justin L from comment #2) > it suggests that both the top and bottom borders are "added" to the spacing Probably not true.
Created attachment 199434 [details] 164907_atLeast_vs_exact2.docx: a bit more complex than the previous example
WIP patch at sw: Calculate row height adds border if 'atLeast' set #2 [NEW]
I should have mentioned that I also noticed Oliver's patch fixing forum-mso-en-435.doc. [top and bottom border spacing = 0 - atLeast 0.60cm] forum-mso-en4-129146.doc: ends up being improved by Oliver's patch. No top/bottom border padding in this case either. ooo50668-1.doc: also no top/bottom padding. Assume other factors at play. Before the patch certainly wasn't correct either. forum-mso-en-18195.docx: also no top/bottom padding. Oliver's patch improved things in the first few lines. LOTS of other factors coming into play to distort the comparison of the rest of the table. forum-mso-en-2385.docx is too big/complex to be worth spending any time on it. No interesting unit tests found either - although n780853.docx was almost interesting. But the minimum height must not be needed...
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/e9ed6f1d2cc145e7514bf0a27b8c77f370ceab2d tdf#164907 sw: Calculate row height adds border if 'atLeast' set #2 It will be available in 25.8.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Justin Luth committed a patch related to this issue. It has been pushed to "libreoffice-25-2": https://git.libreoffice.org/core/commit/2a47fa27a1ce9bf115ab9f060c61217a51da644a tdf#164907 sw: Calculate row height adds border if 'atLeast' set #2 It will be available in 25.2.2. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.