Bug 55433 - EDITING, FORMATTING: Row Height fails to expand automatically after editing cell content in particular .ods
Summary: EDITING, FORMATTING: Row Height fails to expand automatically after editing c...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
4.0.0.0.alpha0+ Master
Hardware: Other All
: low normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
: 139617 (view as bug list)
Depends on:
Blocks: Calc-Cells
  Show dependency treegraph
 
Reported: 2012-09-28 20:15 UTC by Stephan van den Akker
Modified: 2021-03-17 16:01 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments
Spreadsheet that fails to expand row height (8.44 KB, application/vnd.oasis.opendocument.spreadsheet)
2012-09-28 20:15 UTC, Stephan van den Akker
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Stephan van den Akker 2012-09-28 20:15:51 UTC
Created attachment 67837 [details]
Spreadsheet that fails to expand row height

How to reproduce:
Open sample spreadsheet
Enter text that doesn't fit in a cell
Select from the main menu: Format -> Cells...
Select "Wrap text automatically" on the "Alignment" tab
Press OK

Expected result in
LibreOffice 3.5:build-403 Build ID: 350m1(Build:403) on openSuSE 12.2 (32-bit)
The text wraps on the right cell border. The row height expands automatically to show all lines of the text.

Actual result in debug builds
LO version 3.7.0.0.alpha0+ (Build ID: dccddcc) on openSuSE 11.4 (x86-64);
LO version 3.7.0.0.alpha0+ (Build ID: 39157df) on openSuSE 12.2 (32-bit):

The text wraps on the right cell border. The row height does not expand. Not all lines are shown.
 
This is a regression, because it works in LO 3.5
Comment 1 Stephan van den Akker 2012-09-28 20:25:23 UTC
Also working OK in LO 3.5, but not working in master builds: Selecting "Optimal Row Height..." in the context menu of row labels

Also no automatic height change when adding a subscript or superscript to the cell text.
Comment 2 Joel Madero 2012-12-06 22:24:26 UTC
Confirmed and this one is strange as I started with a fresh sheet and was able to work with it no problem. How did you create this sheet? I can't confirm that it works as expected in 3.5 so not marking as regression yet

Marking:
New (confirmed for this particular sheet)
Minor (Is annoying but there is a workaround in manually resizing row)
Lowest (let us know how you made this document and we'll see how many people would/could run into the same situation, if it's something that a lot of people do then we'll up the priority.)

Thanks for reporting Stephan
Comment 3 Stephan van den Akker 2012-12-06 23:25:18 UTC
Hi Joel,

The sheet was created with an older version of Open Office.

Can't retrace the exact version, but probably 3.1.0 or 3.2.1.
Comment 4 Stephan van den Akker 2012-12-06 23:30:52 UTC
Just tested with Libre Office version 3.6:build-303 (Build ID: 360m1(Build:303))
on openSuSE 12.2 (x86). 

Row height expands OK.
Comment 5 Rainer Bielefeld Retired 2013-01-19 08:56:19 UTC
I can confirm Joel Madero's observations more or less. I terribly suffer from this problem (WIN7 LibO 3.6, LibO 4.0), but I never managed to create a sample document from the scratch.
Comment 6 Rainer Bielefeld Retired 2013-01-19 10:12:35 UTC
This one is [Reproducible] with "LibreOffice 3.6.5.1 rc" German UI/ German Locale [Build-ID: 5b93205] {pull date 2013-01-18} on German WIN7 Home Premium (64bit): 
When I open reporter's sample I see 'A1:A2' with too small row heigt

Editing these cells: 
1. Add "Text wrap" to A3
2. Type some 3 lines nonsense text, <tab>
   Unexpectedly wrap disappears
This effect is the same as in "Bug 59581 - FORMATTING: Text wrap fails in existing document.ods", bot for that document the problem starts with 3.7 Master. Mp Idea whether related to reporter's problem here. 

Reporter's  document is NOT conformant ODF1.2:
* content.xml:27 col:51 - bad value for attribute "text-position" from namespace "urn:oasis:names:tc:opendocument:xmlns:style:1.0"
* styles.xml:144 col:184 bad value for attribute "time-value" from namespace "urn:oasis:names:tc:opendocument:xmlns:text:1.0"
Comment 7 Stephan van den Akker 2013-05-31 19:57:32 UTC
Reproducible in MASTER on Ubuntu 12.04 (32-bit)

Version: 4.2.0.0.alpha0+
Build ID: c2530b02311c46529eed53ee688bf6c83ce4b86
Comment 8 QA Administrators 2015-03-04 02:22:53 UTC Comment hidden (obsolete)
Comment 9 Stephan van den Akker 2015-03-07 22:30:18 UTC
OP reproducible on MASTER.

Version: 4.5.0.0.alpha0+, 
Build ID: ca7f62c8262662c8f58a3fa3b298623f25b55eaa, 
Locale: en_US

on openSuSE 13.2 (x86-64).

Also still no automatic height change when adding a subscript or superscript to the cell.

Selecting "Optimal Row Height..." works correctly again, though.
Comment 10 tommy27 2016-04-16 07:28:50 UTC Comment hidden (obsolete)
Comment 11 a 2017-03-23 06:52:51 UTC
optimal row height does not refresh after text input (not sure after a value input)


when 'optimal row height' (+0,1cm) has been selected (on multimple rows, right click on row-number), when text is entered in an empty cell, the optimal row height is not applied nor refreshed : it has to be selected again (right click on the row-number-line) though it shows already the value selected initally (+0,1cm) clicking  ok applies row height.

it may be simply a refresh to be done after text is entered in a cell (where optimal row height was pre-selected)


(in the 'format cell' tabs, it is not showing the cell has an optimal row value)


Version: 5.3.1.2 / Build ID: 1:5.3.1-0ubuntu1~yakkety0
Comment 12 Timur 2018-06-18 15:45:47 UTC
Repro in master 6.2+
I guess it's more of an interest to know why this happens in old file than of practical use.
Comment 13 M4SK 2020-09-06 09:37:00 UTC
Still here in 7.0.1, after all these years...

I agree this is probably a problem of applying optimal row height after a new entry is made.

And I quite disagree with the importance set for this bug. In certain contexts, this problem is VERY annoying, like in the case of software localization.

Typically, localizations use big spreadsheets containing various technical data, the text to translate and empty columns that need to be filled by the translators. And these spreadsheets are (tens of) thousands of lines long, with cells containing sometimes just one word, sometimes hundreds of words...
So having to constantly manually refresh the row heights is quite a pain. Especially when the files get really big, and refreshing all the spreadsheet (selecting every cell then double clicking on a separation line between two cells) can sometimes take 10s or more...

I've been plagued by this problem for years, in Win 7, Win 10 and now Linux Mint...
Comment 14 Heiko Tietze 2021-01-19 08:45:12 UTC
*** Bug 139617 has been marked as a duplicate of this bug. ***
Comment 15 Telesto 2021-01-19 15:43:11 UTC
Maybe me but this apparently not a regression for Windows environment..
Comment 16 Timur 2021-03-17 16:01:14 UTC
I don't know why I marked regression, I guess because of Comment 0. But it's the same from OO and in 3.5 and in 7.2+
Workaround is to select celks or all and Optimal row height. 
Bug 59581 was marked duplicate of fixed bug 59193,seems similar.