Bug 165063 - LAYOUT: table row exactly 0.85cm is significantly taller than other exactly 0.85cm rows.
Summary: LAYOUT: table row exactly 0.85cm is significantly taller than other exactly 0...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
25.2.0.0 alpha0+
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected
Depends on:
Blocks: DOCX-Tables
  Show dependency treegraph
 
Reported: 2025-02-05 16:21 UTC by Justin L
Modified: 2025-02-22 18:28 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
forum-pl-2716.docx: example document (93.80 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2025-02-05 16:21 UTC, Justin L
Details
forum-pl-2716min.docx: a more minimal version (32.72 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2025-02-22 14:41 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-02-05 16:21:40 UTC
Created attachment 199002 [details]
forum-pl-2716.docx: example document

A cell now shows 3 (empty) paragraphs instead of 2. (The cell actually has 14 empty paragraphs in it...) 

This started with 25.2 commit bfefb2bebd71fc63026b92b23555ce57e4feb536
Author: Mike Kaganski on Thu Sep 19 18:43:35 2024 +0500
    Re-calculate the available space before calling lcl_RecalcSplitLine

due to replacing nRemainingSpaceForLastRow with getRemainingAfter()

Steps to reproduce.
1.) open forum-pl-2716.docx

On page 2, the second row is taller than all the others. They should all be the same height, since they are all sized as "exactly 0.85cm".

I'm not sure why an "exactly" sized row would be different after Mike's commit. Not marking as a regression since it looks like just exposing that failure.

Found by Collabora's mso-test

Perhaps it is worth noting that I also saw (ambiguous) changes to ooo67042-2.doc that also pointed to this commit. In that case there are some arguable improvements on page 2 at least.
Comment 1 Justin L 2025-02-22 14:41:34 UTC
Created attachment 199381 [details]
forum-pl-2716min.docx: a more minimal version

I had a hard time minimizing this example (using Word 2010). Anything that seemed to affect that merged row apparently caused it to re-validate something, and the resulting table written out was read OK by LO.

So I'm guessing that the math "just doesn't add up" in the table description.