Bug 132354

Summary:	Automatic Row height wrong after FileOpen (workaround: set height manually)
Product:	LibreOffice	Reporter:	Matthias Hellinghausen <mh>
Component:	Calc	Assignee:	Not Assigned <libreoffice-bugs>
Status:	RESOLVED FIXED
Severity:	normal	CC:	AdamT.Watts, himajin100000, mh, miguelangelrv, xiscofauli
Priority:	medium	Keywords:	bibisected, bisected
Version:	6.2 all versions
Hardware:	All
OS:	All
See Also:	https://bugs.documentfoundation.org/show_bug.cgi?id=130383
Whiteboard:
Crash report or crash signature:		Regression By:
Bug Depends on:
Bug Blocks:	125077
Attachments:	Text of cell a:4 screenshot shows the failure same file with older LO version

Description Matthias Hellinghausen 2020-04-23 13:10:06 UTC

Description:
Libreoffice 6.4.3.2 Calc:

the calculation of the "optimal Row height" fails after opening an ods file. 
When the "optimal Row height" is triggered again from the context menue, the Row Height will fit abain and the full Text of the cell will be displayed.

The calculation nmot fails in all cases, but depends on the width of the column and the length off the Text.

kind regards
Matthias



Steps to Reproduce:
1. long text that not fit in the cell (width) 
2. wrap text enabled
3. optimal row height enabled
4. save
5. reopen
6. 1-5 with different "column width"/"text length"

Actual Results:
after open the Row heigth calculated wrong

Expected Results:
all text of the cell should be displayed


Reproducible: Always


User Profile Reset: Yes



Additional Info:
n.a.

Comment 1 Matthias Hellinghausen 2020-04-23 13:12:40 UTC

Created attachment 159851 [details]
Text of cell a:4

Comment 2 m_a_riosv 2020-04-23 20:16:24 UTC

I can't repro.
Version: 6.4.3.2 (x64)
Build ID: 747b5d0ebf89f41c860ec2a39efd7cb15b54f2d8
CPU threads: 4; OS: Windows 10.0 Build 19613; UI render: GL; VCL: win; 
Locale: es-ES (es_ES); UI-Language: en-US Calc: CL

Comment 3 Matthias Hellinghausen 2020-04-24 06:27:10 UTC

Created attachment 159882 [details]
screenshot shows the failure

added screenshot

Comment 4 Matthias Hellinghausen 2020-04-24 06:32:34 UTC

Created attachment 159883 [details]
same file with older LO version

added screenshot

btw. with Version 6.0.7.3 the row height is OK after file open. 

Here the problem shows up with version 6.4.3 on different Linux maschines (ubuntu 16.04. and 18.04)

Comment 5 Xavier Van Wijmeersch 2020-04-24 08:55:50 UTC

cannot reproduce with

Version: 7.0.0.0.alpha0+
Build ID: 96f77910e86f88c99621a8b17c09fc69f9f1d8f3
CPU threads: 8; OS: Linux 5.4; UI render: default; VCL: gtk3; 
Locale: nl-BE (en_US.UTF-8); UI-Language: en-US
Calc: threaded

Comment 6 Adam 2020-05-15 20:48:16 UTC

Repro in 

Version: 6.4.3.2 (x64)
Windows 10.0 Build 18363


Version: 7.0.0.0.alpha0+ (x64)
Windows 10.0 Build 18363


Seems like it might be a dup of a pre-existing issue? 

https://bugs.documentfoundation.org/show_bug.cgi?id=34717

Comment 7 Xisco Faulí 2020-06-17 11:55:28 UTC

The issue started to happen after https://cgit.freedesktop.org/libreoffice/core/commit/?id=1e55a47e89a9d9d6cf9cb3993484022aaf2c097b. Before this commit the issue can be reproduced if recalculation on File Load for
ODF files is set to Always Recalculate in Tools/Options.../LibreOffice
Calc/Formula

Comment 8 Gessel 2022-03-24 13:46:37 UTC

I filed #148151 which appears to be a duplicate of this bug and #130383.

I found disabling Options->Calc->Defaults->Enable very large spreadsheets resolved the problem though at the expense of not supporting very large spreadsheets, which is obviously a suboptimal workaround.  If this is the same bug, I'd expect the same results.  I tested with your examples and got the same problems you report and these were resolved with the VLS feature disabled on my system.

Comment 9 Gabor Kelemen (allotropia) 2024-01-17 18:44:48 UTC

I can't reproduce this since 7.6 commit:

https://git.libreoffice.org/core/+/b1393fd5ce847f40abab49f57c67929bb0087fae

author	Maxim Monastirsky <momonasmon@gmail.com>	Fri Mar 17 14:54:30 2023 +0200
committer	Maxim Monastirsky <momonasmon@gmail.com>	Thu Mar 23 08:54:06 2023 +0000

sc drawstyles: ODF import and export

Comment 10 Xisco Faulí 2024-01-18 11:52:38 UTC

(In reply to Gabor Kelemen (allotropia) from comment #9)
> I can't reproduce this since 7.6 commit:
> 
> https://git.libreoffice.org/core/+/b1393fd5ce847f40abab49f57c67929bb0087fae
> 
> author	Maxim Monastirsky <momonasmon@gmail.com>	Fri Mar 17 14:54:30 2023
> +0200
> committer	Maxim Monastirsky <momonasmon@gmail.com>	Thu Mar 23 08:54:06 2023
> +0000
> 
> sc drawstyles: ODF import and export

Hi Gabor,
I think the commit you mentioned is incorrect since the issue is still reproducible in

Version: 7.6.5.0.0+ (X86_64) / LibreOffice Community
Build ID: ebc730f8657af18412c47fc671c3c459072da0ea
CPU threads: 8; OS: Linux 6.1; UI render: default; VCL: gtk3
Locale: es-ES (es_ES.UTF-8); UI: en-US
Calc: threaded

OTOH, the issue seems to be fixed in master/24.2 after

author	Khaled Hosny <khaled@libreoffice.org>	2023-07-17 12:38:41 +0300
committer	خالد حسني <khaled@libreoffice.org>	2023-07-23 06:01:56 +0200
commit 4b743de97fc133623e46827869c4ea3eb845ad47 (patch)
tree 6386636517576c81502367819996972877adc544
parent ea0f9776ed8e7e9809853d292923b86756274564 (diff)
tdf#156234: Don’t round glyph coordinates when doing subpixel positioning

Comment 11 Xisco Faulí 2024-01-18 11:55:46 UTC

In fact, the issue is back if 4b743de97fc133623e46827869c4ea3eb845ad47 is reverted in a local build

Comment 12 Gabor Kelemen (allotropia) 2024-01-18 14:23:59 UTC

(In reply to Xisco Faulí from comment #11)
> In fact, the issue is back if 4b743de97fc133623e46827869c4ea3eb845ad47 is
> reverted in a local build

Possible, thanks for digging into this. I was focusing on the automatic height being incorrect after save-reload, for that case my finding may be correct.