Bug 157468

Summary: A specific XLSX imports ignoring the "optimal row height" property, rows keep single-line
Product: LibreOffice Reporter: Mike Kaganski <mikekaganski>
Component: CalcAssignee: Not Assigned <libreoffice-bugs>
Status: RESOLVED DUPLICATE    
Severity: normal CC: aron.budea, miguelangelrv
Priority: medium Keywords: regression
Version: 3.6.0.4 release   
Hardware: All   
OS: All   
URL: https://ask.libreoffice.org/t/excel-created-have-word-wrap-enabled-but-libre-dont-adjust-the-row-height-correctly/96314/
Whiteboard:
Crash report or crash signature: Regression By:
Attachments: A sample file from the Ask question

Description Mike Kaganski 2023-09-27 07:18:09 UTC 
Created attachment 189844 [details]
A sample file from the Ask question

Opening the attachment has all the rows single-line, unlike in Excel.
Also in LO 3.5 and earlier, the import made row heights fit the content.
In current versions, deleting columns (e.g., column A) suddenly re-calculates the row heights; undoing the column removal does not restore the incorrect single-line row heights.
Exporting the document with incorrect row heights to PDF (and printing) makes the invisible (trimmed) content of the cells to become visible above (overlapping other cells).

All of this seems to be related to each other.

Ref: https://ask.libreoffice.org/t/excel-created-have-word-wrap-enabled-but-libre-dont-adjust-the-row-height-correctly/96314/
Comment 1 m_a_riosv 2023-09-29 18:52:04 UTC 
For seems it works fine with master:
Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 5e9c8d21874eea8cb5adf2ecab1905295af2308f
CPU threads: 16; OS: Windows 10.0 Build 22621; UI render: Skia/Raster; VCL: win
Locale: es-ES (es_ES); UI: en-US
Calc: CL threaded Jumbo


Reproducible with
Version: 7.6.1.2 (X86_64) / LibreOffice Community
Build ID: f5defcebd022c5bc36bbb79be232cb6926d8f674
CPU threads: 16; OS: Windows 10.0 Build 22621; UI render: Skia/Vulkan; VCL: win
Locale: es-ES (es_ES); UI: en-US
Calc: CL threaded
Comment 2 m_a_riosv 2023-09-29 18:54:55 UTC 
Maybe in relation with 147620
Comment 3 Mike Kaganski 2023-09-29 19:02:23 UTC 
(In reply to m.a.riosv from comment #1)

Thank you!

*** This bug has been marked as a duplicate of bug 123026 ***