Bug 118086 - FILEOPEN: FORMATTING occasionally wrong row height
Summary: FILEOPEN: FORMATTING occasionally wrong row height
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
6.2.0.0.alpha0+
Hardware: x86-64 (AMD64) All
: medium normal
Assignee: Vasily Melenchuk (CIB)
URL:
Whiteboard: target:6.2.0 target:6.1.0.1 target:7.2.0
Keywords: bibisected, bisected, regression
Depends on:
Blocks:
 
Reported: 2018-06-09 22:36 UTC by Stefan_Lange_KA@T-Online.de
Modified: 2021-03-04 21:18 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
zip file with sheet document for demonstration + screenshot (84.45 KB, application/x-zip-compressed)
2018-06-09 22:37 UTC, Stefan_Lange_KA@T-Online.de
Details
zip file #2 with sheet document for demonstration + screenshots (589.67 KB, application/x-zip-compressed)
2018-06-10 12:13 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 Stefan_Lange_KA@T-Online.de 2018-06-09 22:36:49 UTC
In some cases in Calc rows are displayed with wrong height, but I don't know the circumstances when this happens.

Demonstrating the problem:
- open sheet document "Test_Zeilenhöhe_1.ods" from the attached zip file with LODev 6.2 alpha0
- all rows in the sheets "Tabelle1", "Tabelle2" and "Sheet5" (= copy of "Tabelle2") are displayed with the correct height
- in "Sheet3" and "Sheet4" (both are copied from "Tabelle1") the row 3 is displayed with a greater height
- select all (Ctrl + A) in "Sheet3" and/or "Sheet4" -> Format -> Row -> Optimal Height -> Add = 0 + OK -> all rows ar displayed with the correct height
- save the documment, close and re-open it
- in "Sheet3" and "Sheet4" row 3 is displayed with the wrong (greater) height again

tested with
Version: 6.2.0.0.alpha0+ (x64)
Build ID: cbe3ae1894800a5fddbd598403be54f9495cc964
CPU threads: 4; OS: Windows 10.0; UI render: GL; 
TinderBox: Win-x86_64@42, Branch:master, Time: 2018-06-09_04:05:33
Locale: de-DE (de_DE); Calc: CL
with OpenGL enabled as well as with OpenGL disabled

not reproduced with LO 6.1 beta and LO 6.0.5.1
Comment 1 Stefan_Lange_KA@T-Online.de 2018-06-09 22:37:59 UTC
Created attachment 142630 [details]
zip file with sheet document for demonstration + screenshot
Comment 2 Xavier Van Wijmeersch 2018-06-10 07:03:40 UTC
Cannot open your test file, got error file does not exist!!!
Comment 3 Stefan_Lange_KA@T-Online.de 2018-06-10 09:06:27 UTC
This is strange! I can open the zip file "Wrong row height.zip" (with Windows Explorer) as well as both conained files "Test_Zeilenhöhe_1.ods" (spreadshet for test) and "Wrong Row height.JPG" (Screenshot).
I have done this on the computer where I have reported the bug and also on a second computer.
Comment 4 MM 2018-06-10 10:06:06 UTC
Confirmed on ubuntu 16.04 x64 with Version: 6.2.0.0.alpha0+
Build ID: c4c56de1b0e62ec866b519b2b24c5e805f0a86d3
CPU threads: 2; OS: Linux 4.4; UI render: default; VCL: gtk2; 
TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2018-06-09_00:23:35
Locale: en-US (en_US.UTF-8); Calc: threaded

but not with Version: 6.1.0.0.alpha1+
Build ID: 47dc3115f12ff16dc326b6edd12c46e6a6ef1843
CPU threads: 2; OS: Linux 4.4; UI render: default; VCL: gtk2; 
TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2018-05-17_00:32:17
Locale: en-US (en_US.UTF-8); Calc:

Loading a file with v6.1 saved with v6.2 shows no problems, so the issue must be with loading / formatting with v6.2.
Comment 5 Xavier Van Wijmeersch 2018-06-10 10:27:44 UTC
Did found out why i could not open the file.
Its the name of the file who caused the problem => Test_Zeilenh􏹶he_1.ods.
Its the Ö in the name wish is not recognized by LO.
After renaming i can open the file.

can reproduce the problem with

Version: 6.2.0.0.alpha0+
Build ID: 7d521a85858bacdb7b5db359036ccf6f01b709c3
CPU threads: 8; OS: Linux 4.14; UI render: default; VCL: kde4; 
Locale: nl-BE (en_US.UTF-8); Calc: group threaded
Comment 6 Stefan_Lange_KA@T-Online.de 2018-06-10 12:12:49 UTC
(In reply to MM from comment #4)
> Confirmed on ubuntu 16.04 x64 with Version: 6.2.0.0.alpha0+
> Build ID: c4c56de1b0e62ec866b519b2b24c5e805f0a86d3
> CPU threads: 2; OS: Linux 4.4; UI render: default; VCL: gtk2; 
> TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time:
> 2018-06-09_00:23:35
> Locale: en-US (en_US.UTF-8); Calc: threaded
> 
> but not with Version: 6.1.0.0.alpha1+
> Build ID: 47dc3115f12ff16dc326b6edd12c46e6a6ef1843
> CPU threads: 2; OS: Linux 4.4; UI render: default; VCL: gtk2; 
> TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time:
> 2018-05-17_00:32:17
> Locale: en-US (en_US.UTF-8); Calc:
> 
> Loading a file with v6.1 saved with v6.2 shows no problems, so the issue
> must be with loading / formatting with v6.2.

I think that the error concerns also files saved wth LO 6.0 or 6.1 because I have seen the problem first with such a file. Because this file is big (about 500 KB) I have created the test file.
Now I have removed some person related date from this file and saved it as test file "Alte Fotoapparate_Test.ods" with
Version: 6.1.0.0.beta1+ (x64)
Build ID: aecab50c291a535bc0ccfd30b86060faf6bea994
CPU threads: 4; OS: Windows 10.0; UI render: GL; 
TinderBox: Win-x86_64@42, Branch:libreoffice-6-1, Time: 2018-06-09_00:00:17
Locale: de-DE (de_DE); Calc: CL

When this file is opened with LO Dev 6.2 in all sheets except the first some rows (one, more or all) are displayed with a wrong height.
I attach a second zip file with this document and 2 screenshots showing differences when the sheet document is opened in LO 6.1. and 6.2.
Comment 7 Stefan_Lange_KA@T-Online.de 2018-06-10 12:13:46 UTC
Created attachment 142636 [details]
zip file #2 with sheet document for demonstration + screenshots
Comment 8 Xavier Van Wijmeersch 2018-06-10 13:02:34 UTC
no problem with

Version: 6.0.4.2
Build ID: 9b0d9b32d5dcda91d2f1a96dc04c645c450872bf
CPU threads: 8; OS: Linux 4.14; UI render: default; VCL: kde4; 
Locale: nl-BE (en_US.UTF-8); Calc: group

Version: 6.1.0.0.beta1
Build ID: 8c76dfe1284e211954c30f219b3a38dcdd82f8a0
CPU threads: 8; OS: Linux 4.14; UI render: default; VCL: kde4; 
Locale: en-US (en_US.UTF-8); Calc: group
Comment 9 Xisco Faulí 2018-06-11 11:36:28 UTC
Regression introduced by:

author	Vasily Melenchuk <Vasily.Melenchuk@cib.de>	2018-04-06 20:19:10 +0300
committer	Thorsten Behrens <Thorsten.Behrens@CIB.de>	2018-06-08 00:47:06 +0200
commit	1e55a47e89a9d9d6cf9cb3993484022aaf2c097b (patch)
tree	3a3372525645775c32721e59ce8c205c8f474ffd
parent	2a7f74900fb646235b74d4c9bd4690e44edc3ed4 (diff)
tdf#62268: allow row height recalculation on document load
During document load rows with style:use-optimal-row-height="true"
should recalculate it's height.

Bisected with: bibisect-linux64-6.2

Adding Cc: to Vasily Melenchuk
Comment 10 Xisco Faulí 2018-06-12 08:32:20 UTC
attachment 142385 [details] from bug 117882 is also affected by this issue.
Comment 11 Commit Notification 2018-06-29 08:54:11 UTC
Vasily Melenchuk committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=e2fce4f05084061efb64e53444ab5d2d0d05b612

tdf#118086: calc: invalid row autoheight fixed

It will be available in 6.2.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 12 Stefan_Lange_KA@T-Online.de 2018-06-30 12:55:20 UTC
I have tested with

Version: 6.2.0.0.alpha0+ (x64)
Build ID: 7696d1d217b6cff63490e7f98403d0e499c33d17
CPU threads: 4; OS: Windows 10.0; UI render: GL; 
TinderBox: Win-x86_64@42, Branch:master, Time: 2018-06-30_01:51:45
Locale: de-DE (de_DE); Calc: CL

and the problem didn't occur: All rows were displayed with the correct height.
Comment 13 Xisco Faulí 2018-07-02 23:29:31 UTC
Setting to VERIFIED as per comment 12.

@Vasily, Thanks for fixing this!

Should it be backported to 6.1 along with 1e55a47e89a9d9d6cf9cb3993484022aaf2c097b ?
Comment 14 Commit Notification 2018-07-03 15:47:53 UTC
Vasily Melenchuk committed a patch related to this issue.
It has been pushed to "libreoffice-6-1":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=dd645e70108f31aab611634e77c120e5efe52d05&h=libreoffice-6-1

tdf#118086: calc: invalid row autoheight fixed

It will be available in 6.1.0.1.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 15 Commit Notification 2021-03-01 20:59:45 UTC
Xisco Fauli committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/8e3548af67218034c9fc816c011ae4b16e081e16

tdf#118086: sc_subsequent_filters: Add unittest

It will be available in 7.2.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 16 Stefan_Lange_KA@T-Online.de 2021-03-04 20:21:02 UTC
I was a little bit confused about the annonced patch because the bug was resolved by the fix from 2018 - at least for me.

But because of Comment 10 I have now tested also with the document from bug 117882 - with LO 7.0.5.1 and recent LOdev 7.0.6 and also with recent LOdev 7.2.0:
Version: 7.2.0.0.alpha0+ (x64) / LibreOffice Community
Build ID: 722ec600e85cca2e94e82e69f8d13773061172b9
CPU threads: 4; OS: Windows 10.0 Build 21327; UI render: Skia/Raster; VCL: win
Locale: de-DE (de_DE); UI: de-DE
Calc: threaded
from /daily/master/Win-x86_64@tb77-TDF/2021-03-04_04.10.52 (should contain the patch announced in Comment 15) 

In the tests I see no differences between the versions. In all three versions the document is processed in the same unproper manner:
- After the document is opened it looks nearly like in "Screen after removing a row" from bug 117882.
- After insert a row before one of the rows 2 ... 16 + Undo the document is formatted properly nearly like in "Screen before removing a row" from bug 117882.
- After the changed document was saved and reopened it looks wrongly again as before.
Comment 17 Stefan_Lange_KA@T-Online.de 2021-03-04 21:18:16 UTC
Addition to Comment 16 - test with document from bug 117882:
When before save all rows are selected and the "Optimal row height" is set with additional value 0,05 or more, after close and reopen the document is formatted correctly as before save.