Bug 148139 - Row height when text is wrapped is being lost after saving document
Summary: Row height when text is wrapped is being lost after saving document
Status: RESOLVED DUPLICATE of bug 146668
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
7.3.1.3 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-03-22 14:50 UTC by Rafael Lima
Modified: 2023-06-14 20:25 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
Sample ODS file (24.94 KB, application/vnd.oasis.opendocument.spreadsheet)
2022-03-22 14:50 UTC, Rafael Lima
Details
other document to reproduce the problem (18.50 KB, application/vnd.oasis.opendocument.spreadsheet)
2022-07-26 18:12 UTC, Stefan_Lange_KA@T-Online.de
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Rafael Lima 2022-03-22 14:50:45 UTC
Created attachment 179041 [details]
Sample ODS file

On some occasions LO Calc is not saving row height to the file when text is wrapped, so closing and reopening it will cause the row height to consider a single line of text instead of automatically adjusting to the text height.

Steps to reproduce:
1) Open the sample ODS file (make sure you have the font Carlito installed)
2) Notice that rows 8, 22 and 27 do not adjust automatically for height, even though text is wrapped; Also notice that other rows do adjust automatically with the exact same format settings.
3) Double-click the edges of the row numbers to auto-adjust height. This will work OK and height will be adjusted.
4) Save and close the file
5) Reopen the file
6) Notice that rows 8, 22 and 27 lost their new height

One thing that I noticed is that this bug happens when the wrapped text results in a single word remaining in the second line. This may explain why the problem does not happen in rows 2, 5, 7, etc since the second line of wrapped text has more than a single word.

System info:
Version: 7.3.1.3 / LibreOffice Community
Build ID: 30(Build:3)
CPU threads: 16; OS: Linux 5.13; UI render: default; VCL: kf5 (cairo+xcb)
Locale: pt-BR (pt_BR.UTF-8); UI: en-US
Ubuntu package version: 1:7.3.1~rc3-0ubuntu0.21.10.1~lo2
Calc: threaded
Comment 1 m_a_riosv 2022-03-23 15:37:45 UTC
Reproducible
Version: 7.2.6.2 (x64) / LibreOffice Community
Build ID: b0ec3a565991f7569a5a7f5d24fed7f52653d754
CPU threads: 4; OS: Windows 10.0 Build 19044; UI render: Skia/Vulkan; VCL: win
Locale: es-ES (es_ES); UI: en-US Calc: CL
Version: 7.4.0.0.alpha0+ (x64) / LibreOffice Community
Build ID: ab4cffecd614d9443af5f9763d83add29178ade0
CPU threads: 4; OS: Windows 10.0 Build 19044; UI render: default; VCL: win
Locale: es-ES (es_ES); UI: en-US Calc: threaded
Comment 2 Stefan_Lange_KA@T-Online.de 2022-07-26 18:12:54 UTC
Created attachment 181427 [details]
other document to reproduce the problem

I have found nearly the same behavior in one of my own documents and with the attached test document "Test_Textumbruch.ods" I think one can show when the error occurs.
I have changed repeatedly the width of column A, set for all rows "Optimal height" and saved + reopened the document.
Result:
The height of rows 1 and 2 was always correctly after save + reopen the document.
The height of rows 3..6 was not correctly at reopen when the word "Weimar" was separated by hyphenation.
Found and reproduced with
Version: 7.4.0.1 (x64) / LibreOffice Community
Build ID: 43e5fcfbbadd18fccee5a6f42ddd533e40151bcf
CPU threads: 4; OS: Windows 10.0 Build 19044; UI render: default; VCL: win
Locale: de-DE (de_DE); UI: de-DE
Calc: CL
Comment 3 Stéphane Guillou (stragu) 2023-06-14 20:16:48 UTC
Not reproduced in 6.0, so looks like the same regression as bug 146668.

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