Bug 108598 - FORMATTING Row height is changed or not changed wrongly
Summary: FORMATTING Row height is changed or not changed wrongly
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
5.3.3.2 release
Hardware: x86-64 (AMD64) All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, filter:ods, regression
Depends on:
Blocks: HarfBuzz-regressions
  Show dependency treegraph
 
Reported: 2017-06-17 19:50 UTC by Stefan_Lange_KA@T-Online.de
Modified: 2019-11-01 20:02 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
zip-file with two documents to reproduce the error (72.22 KB, application/x-zip-compressed)
2017-06-17 19:50 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 2017-06-17 19:50:45 UTC
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
Comment 1 Buovjaga 2017-06-24 08:35:40 UTC
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)
Comment 2 raal 2017-10-06 22:27:13 UTC
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 sha: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""
Comment 3 QA Administrators 2018-10-19 02:50:57 UTC Comment hidden (obsolete)
Comment 4 Stefan_Lange_KA@T-Online.de 2018-10-20 18:34:03 UTC
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!
Comment 5 Stefan_Lange_KA@T-Online.de 2018-10-20 18:38:45 UTC
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.
Comment 6 QA Administrators 2019-10-21 02:29:49 UTC Comment hidden (obsolete)
Comment 7 Stefan_Lange_KA@T-Online.de 2019-11-01 20:01:54 UTC
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.