Created attachment 134086 [details] zip-file with two documents to reproduce the error In some of my spreadsheet documents the height of rows containing cells with wrapped text is changed wrongly when any cell contents in this rows is edited. To find out or at least delimit the reason and to exclude other reasons like named areas, formulas etc. I have reduced the document. When cells are not edited, but copied from other cells, the row height is treated correctly (decreased or enlarged or not changed). One reason seems to be the Add-value in Format - Rows - Optimal Height: With the default value 0.00 the height of the rows is decreased when any cell contents in the row is edited. With a value 0.1 or greater the height is not decreased. On the other hand the height is not enlarged when the change of cell contents causes that text is wrapped. This effect seems not to be influenced by the value of Format - Rows - Optimal Height - Add. Reproducing the error - different cases: 1. - open "Test_Zeilenhöhe_orh_0.ods" (in the attached zip-file) - go to sheet "Altix IV und V", row 73 - edit the value in one of the cells B73, C73, D73, E73, J73, K73, ... and then undo the change -> Result: The row heigth is decreased after change. With undo the cell contents is reset, but the row heigt is not reset (as in bug 34552) 2. - open "Test_Zeilenhöhe_orh_0.ods" (in the attached zip-file) - go to sheet "Altix IV und V", row 73 - edit the value in one of the cells F73, G73, H73, I73, L73, ... and then undo the change -> Result: The row heigth remains after change. With undo the cell contents is reset, but the row heigt is decreased. 1a and 2a. When the same is done with file "Test_Zeilenhöhe_orh_+0.1.ods" the problems do not occur. 3. - open "Test_Zeilenhöhe_orh_0.ods" (in the attached zip-file) - go to sheet "Altix IV und V", row 62 - edit the value "Tempor" in cell O62 to "Prontor-SVS" -> Result: The text is wrapped, but the row heigth is not emlarged and on the right edge of the cell appears a red arrow. 3a. same with file "Test_Zeilenhöhe_orh_+0.1.ods" -> same behavior
Repro, but not with 3.6. I tested only the first case. Arch Linux 64-bit, KDE Plasma 5 Version: 6.0.0.0.alpha0+ Build ID: 5ff95b16cf9fb2ac7b2b970614e3b98f55978dc0 CPU threads: 8; OS: Linux 4.11; UI render: default; VCL: kde4; Locale: fi-FI (fi_FI.UTF-8); Calc: group Built on June 23rd 2017 Arch Linux 64-bit Version 3.6.7.2 (Build ID: e183d5b)
This seems to have begun at the below commit. Adding Cc: to Khaled Hosny; Could you possibly take a look at this one? Thanks 5e01bd2a91a717cdaccff18de7c44de37b270914 is the first bad commit commit 5e01bd2a91a717cdaccff18de7c44de37b270914 Author: Norbert Thiebaud <nthiebaud@gmail.com> Date: Wed Nov 2 17:34:31 2016 -0700 source 8f2dd1df1d6cc94ebbc1149de72bc6d6dffa6533 author Khaled Hosny <khaledhosny@eglug.org> 2016-11-02 21:52:06 (GMT) committer Khaled Hosny <khaledhosny@eglug.org> 2016-11-03 00:17:06 (GMT) commit 8f2dd1df1d6cc94ebbc1149de72bc6d6dffa6533 (patch) tree db496889434c484a87b13ffcc4650d65e6672129 parent c8be45889217c555e4bec92af838d0524ceba4e0 (diff) Revert "Revert "Enable the new text layout engine by default""
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
The bug is still present, tested with Version: 6.1.3.1 (x64) Build-ID: a9670562c26181ec3afbe381c9ff499ae88c98b7 CPU-Threads: 4; BS: Windows 10.0; UI-Render: GL; Gebietsschema: de-DE (de_DE); Calc: CL and with Version: 6.1.4.0.0+ (x64) Build-ID: 67c65aa21335cf28aca2e92a9fa2f180aa800ea6 CPU-Threads: 4; BS: Windows 10.0; UI-Render: GL; TinderBox: Win-x86_64@62-TDF, Branch:libreoffice-6-1, Time: 2018-10-19_02:44:05 Gebietsschema: de-DE (de_DE); Calc: CL In Version: 6.2.0.0.alpha0+ (x64) Build ID: 6baca63b44bf7f75a522b1adc4b4bbce502aec3b CPU threads: 4; OS: Windows 10.0; UI render: GL; VCL: win; TinderBox: Win-x86_64@42, Branch:master, Time: 2018-10-20_01:35:41 Locale: de-DE (de_DE); Calc: CL the bug exists in modified version: When test document "Test_Zeilenhöhe_orh_0.ods" is opened the height of rows 73, 75 etc. in sheet "Altix IV und V" is akready. After the height of all rows in the sheet except the header rows is "optimized" by Format - Rows - Optimal height the bug can by reproduced as described. The bug cannot be reproduced with LO 3.3, LO 4.0, LO 5.0 and also not with Version: 5.2.6.2 (x64) Build-ID: a3100ed2409ebf1c212f5048fbe377c281438fdc CPU-Threads: 4; BS-Version: Windows 6.19; UI-Render: GL; Gebietsschema: de-DE (de_DE); Calc: CL I.e. the bug was "introduced" between LO 5.2.6 and 5.3.3, see Comment_2!
Correction: The sentence in Comment_4 related the test with LODev 6.2 must be: When test document "Test_Zeilenhöhe_orh_0.ods" is opened the height of rows 73, 75 etc. in sheet "Altix IV und V" is already decreased.
Dear Stefan_Lange_KA@T-Online.de, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
I have tested with Version: 6.3.3.2 (x64) Build-ID: a64200df03143b798afd1ec74a12ab50359878ed CPU-Threads: 4; BS: Windows 10.0; UI-Render: GL; VCL: win; Gebietsschema: de-DE (de_DE); UI-Sprache: de-DE Calc: CL I cannot reproduce cases 1 + 2, means row is not changed neither when cell contents is changed nor at Undo. The behavior of case 3 still exists but in a modified form. Thererfore I will close the bug as RESOLVED-WORKSFORME and report a new bug for the behavior how row height is handled when cell contents is wrapped.