Bug 166474 - FILEOPEN DOC/X: table's atLeast row height is too small.
Summary: FILEOPEN DOC/X: table's atLeast row height is too small.
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
25.2.2.2 release
Hardware: All All
: medium normal
Assignee: Justin L
URL:
Whiteboard: target:25.8.0
Keywords: bibisected, bisected, filter:doc, filter:docx, regression
Depends on:
Blocks: DOCX-Tables
  Show dependency treegraph
 
Reported: 2025-05-06 00:52 UTC by Justin L
Modified: 2025-05-07 00:41 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
forum-en-16602.doc: a DOC example (47.50 KB, application/msword)
2025-05-06 00:52 UTC, Justin L
Details
forum-mso-en4-688446.docx: looks like a good example document (16.74 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2025-05-06 01:37 UTC, Justin L
Details
bug 166474_atLeastTopMargin_overlays.zip: proof for https://gerrit.libreoffice.org/c/core/+/184999 (8.16 MB, application/zip)
2025-05-06 19:13 UTC, Justin L
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Justin L 2025-05-06 00:52:07 UTC
Created attachment 200667 [details]
forum-en-16602.doc: a DOC example

Similar to bug 165492, it appears that "at least" rows also need to add in the top cell margin to the minimum row height. (So bug 164907 comment 4 was correct after all.)

Another not-so-good-example is forum-de-1412.doc. You can also use sw/qa/extras/ooxmlexport/data/tdf165492_atLeastWithBottomSpacing.docx.

Wow, this is unbelievable. I must have done ALL my testing wrong earlier. I must have continued to mix up "exact" and "atLeast" all the time. In the very examples I was using to try to prove that the top margin didn't matter, it clearly shows that it is needed. I'm so confused.

Steps to reproduce:
1.) open tdf165492_atLeastWithBottomSpacing.docx
2.) Notice that the left table has rows set to "atLeast" 2cm. Notice that "Table Options" has a top cell margin of zero.
3.) Change the cell margin to 1cm. The table always grows (even if the bottom margin is set to 0).

So Oliver was right after all in bug 155229 with his 25.2 commit. (The problem with bug 164907 wasn't Oliver's patch, but that we didn't import the right margins for those rows.
Comment 1 Justin L 2025-05-06 01:37:08 UTC
Created attachment 200668 [details]
forum-mso-en4-688446.docx: looks like a good example document
Comment 2 Justin L 2025-05-06 19:13:41 UTC
Created attachment 200678 [details]
bug 166474_atLeastTopMargin_overlays.zip: proof for https://gerrit.libreoffice.org/c/core/+/184999

-forum-en-16602.doc: I modified this document to remove the unknown font from the top - which was obscuring the overlay. Now it clearly shows the improvement.

-forum-de3-4765.doc: clear win on page 1, and on page 2 the table bottom is now correct size.

-forum-mso-de-130675.docx: page 1 (row 1) and 4 (overall table size) are clear examples of IMPROVED.

-forum-mso-en-18478.docx: probably the clearest example of improvement. PERFECT.

-moz1300315-1.docx: another excellent example of great improvement.

-ooo16597-4.docx: no change b/c NO minimum height specified. Other factors must be at play - it never imported the second row well.

-fdo70481-1.docx: page 8 - only the first row has a specified height - which is now increased by a minimal 0.03cm. 2 specified rows on page 9 also grow almost imperceptibly. Nothing on page 10 specifies a row height. IMPROVED, but not a clear example.

-forum-mso-de-136760.docx: so tiny it is hard to discuss it. The first table grew slightly, but it still should grow a bit more. IMPROVED. The second table now starts more-or-less in the correct spot now. It must be "at least" 0.04cm which makes my patch irrelevant since the text is larger than the min size. Other factors must be coming into play, because now the overall-text is pushed down a bit (from the first table) and thus the lucky coincidence of the remaining text being "perfect" is lost. (Note that "Soll werden zu:" was initially worse, so that helps to prove "lucky coincidence".)

-forum-mso-en4-688446.docx: this looks bad in the overlay, but I don't have the Tahoma font - so blaming it on that (since my substitute is much wider and thus probably also taller). Plus, this is about 4 separate tables, so "other factors" may also be at play.
Comment 3 Commit Notification 2025-05-06 21:41:15 UTC
Justin Luth committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/b3e1d66d944106bef177a01f7d180ed507c9716c

tdf#166474 revert tdf#164907 sw: Calculate row height ... #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.