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
Created attachment 142630 [details] zip file with sheet document for demonstration + screenshot
Cannot open your test file, got error file does not exist!!!
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.
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.
Did found out why i could not open the file. Its the name of the file who caused the problem => Test_Zeilenhhe_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
(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.
Created attachment 142636 [details] zip file #2 with sheet document for demonstration + screenshots
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
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
attachment 142385 [details] from bug 117882 is also affected by this issue.
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.
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.
Setting to VERIFIED as per comment 12. @Vasily, Thanks for fixing this! Should it be backported to 6.1 along with 1e55a47e89a9d9d6cf9cb3993484022aaf2c097b ?
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.
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.
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.
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.