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.
Created attachment 159851 [details] Text of cell a:4
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
Created attachment 159882 [details] screenshot shows the failure added screenshot
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)
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
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
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
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.
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
(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
In fact, the issue is back if 4b743de97fc133623e46827869c4ea3eb845ad47 is reverted in a local build
(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.