Bug 34552 - EDITING: Calc loses row height value when modifying a cell
Summary: EDITING: Calc loses row height value when modifying a cell
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
3.3.1 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL: https://bugs.launchpad.net/ubuntu/+so...
Whiteboard:
Keywords:
: 65837 115324 (view as bug list)
Depends on:
Blocks: Calc-UX
  Show dependency treegraph
 
Reported: 2011-02-21 20:46 UTC by Christopher M. Penalver
Modified: 2019-02-18 03:58 UTC (History)
10 users (show)

See Also:
Crash report or crash signature:


Attachments
row-height.xls (14.00 KB, application/vnd.ms-excel)
2011-02-21 20:46 UTC, Christopher M. Penalver
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Christopher M. Penalver 2011-02-21 20:46:55 UTC
Created attachment 43637 [details]
row-height.xls

Downstream bug may be found at:
https://bugs.launchpad.net/ubuntu/+source/openoffice.org/+bug/646157

In Ubuntu 11.04, libreoffice-calc perform at the Terminal:

cd ~/Desktop && wget https://bugs.launchpad.net/ubuntu/+source/openoffice.org/+bug/646157/+attachment/1655284/+files/row-height.xls && localc -nologo row-height.xls

Row 8 height is 0.17". Highlighted row 8, changed background color to black, the height changed to 0.40". Pressed Ctrl+Z to undo, the color changed back, but the row height did not.

lsb_release -rd
Description: Ubuntu natty (development branch)
Release: 11.04

apt-cache policy libreoffice-calc
libreoffice-calc:
  Installed: 1:3.3.0-1ubuntu1
  Candidate: 1:3.3.0-1ubuntu1
  Version table:
 *** 1:3.3.0-1ubuntu1 0
        500 http://us.archive.ubuntu.com/ubuntu/ natty/main i386 Packages
        100 /var/lib/dpkg/status
Comment 1 Rainer Bielefeld Retired 2011-02-21 21:32:58 UTC
The effect is [Reproducible] with "LibreOffice 3.3.1 RC2 – WIN7  Home Premium  (64bit) German UI [OOO330m19 (build 8 / tag 3.3.1.2)]", but only in the sample document. I did lots of tests with own documents without success, I was not able to reproduce the problem.
Problem is not visible with OOo 3.4-dev
Comment 2 Christopher M. Penalver 2011-02-26 00:52:43 UTC
Reproducible in Ubuntu 10.10 LibreOffice 3.3.1

lsb_release -rd
Description: Ubuntu 10.10
Release: 10.10

apt-cache policy libreoffice-calc
libreoffice-calc:
  Installed: 1:3.3.1-1ubuntu3~maverick1
  Candidate: 1:3.3.1-1ubuntu3~maverick1
  Version table:
 *** 1:3.3.1-1ubuntu3~maverick1 0
        500 http://ppa.launchpad.net/libreoffice/ppa/ubuntu/ maverick/main i386 Packages
        100 /var/lib/dpkg/status
Comment 3 Björn Michaelsen 2011-12-23 11:51:13 UTC Comment hidden (obsolete)
Comment 4 Ilja Sekler 2011-12-24 07:42:59 UTC
> To move this bug from NEEDINFO back to NEW please check
> if the bug still persists with the 3.5.0 beta1 or beta2
> prereleases.

Reproduced with

LOdev 3.5.0beta2 
Build ID: 4ca392c-760cc4d-f39cf3d-1b2857e-60db978

No magic self-fixing for this bug so far.
Comment 5 Christopher M. Penalver 2012-01-03 13:58:29 UTC
Reproducible in:
LOdev 3.5.0beta2
Build ID: 8589e48-760cc4d-f39cf3d-1b2857e-60db978
Microsoft Windows Vista Business 6.0.6002 Service Pack 2 Build 6002

This does not occur using Microsoft Office Excel 2003 (11.5612.6505).
Comment 6 Rainer Bielefeld Retired 2012-08-28 04:40:23 UTC
This one might be related to "Bug 34717 - FILEOPEN FORMATTING: automatic row height is too small in particular .xls".

Already a problem with 3.3.0, but oK with AOOo.


Bug description here is wrong, the problem is not that the row height changes when editing a cell, but that the row height is too small when you open the document with LibO. The edit heals the problem.

I am nearby 100% sure that this one is concerning the same problem as "Bug 34717 - FILEOPEN FORMATTING: automatic row height is too small in particular .xls".

So I mark this one as a DUP, because in Bug 34717 we have most advanced examinations. 

@reporter:
Please feel free to reopen this Bug if you find evidence that we have an independent issue here.

*** This bug has been marked as a duplicate of bug 34717 ***
Comment 7 Christopher M. Penalver 2012-08-28 11:55:52 UTC
Rainer Bielefeld,thank you for working on this report. Regarding your comments https://bugs.freedesktop.org/show_bug.cgi?id=34552#c6 :

>"This one might be related to "Bug 34717 - FILEOPEN FORMATTING: automatic row
height is too small in particular .xls"."

Agreed in that this is similar in the problem to bugs 34717, 50044, and 39486 due to .xls correlation, and seemingly, the code requiring a fix. However, this bug is about how when one modifies the document while already open and then undoes, the row height is no longer honored. The other bugs are all about the problem already occurring when one only opens the file.

>"Already a problem with 3.3.0, but oK with AOOo."

So, this problem exists as early as LO 3.3.0, but does not in current AOOo? If so, which AOOo version specifically?

>"Bug description here is wrong, the problem is not that the row height changes
when editing a cell, but that the row height is too small when you open the
document with LibO. The edit heals the problem.

I am nearby 100% sure that this one is concerning the same problem as "Bug
34717 - FILEOPEN FORMATTING: automatic row height is too small in particular
.xls".

So I mark this one as a DUP, because in Bug 34717 we have most advanced
examinations. 

@reporter:
Please feel free to reopen this Bug if you find evidence that we have an
independent issue here.

*** This bug has been marked as a duplicate of bug 34717 ***"

Regarding this bug, the Bug Description is not wrong. It describes verbatim the bug phenomenon the downstream bug reporter wants a developer to address. This may end up being addressed by commit(s) issued for the 3 other reports previously mentioned, or vice versa. But, until this is so, let us please leave this unduped.

Thank you for your understanding.
Comment 8 Julien Nabet 2013-01-01 21:01:58 UTC
I tried to reproduce this on:
- Debian x86-64 with 3.6 sources updated today.
- Win7 64, with 3.6.4.3
In both cases, I haven't reproduced the behaviour described in comment1.
Of course, I had to undo twice, since there were 2 actions to undo.
Perhaps I missed something but could someone give a try with 3.6.4.3?
Comment 9 Christopher M. Penalver 2013-01-03 02:54:39 UTC
Problem reproducible in:
Microsoft Windows Vista Business x86
6.0.6002 Service Pack 2 Build 6002
Version 4.0.0.0.beta2 (Build ID: 4104d660979c57e1160b5135634f732918460a0)

However, the row height changes to 0.21", instead of that reported in the Description (0.40").
Comment 10 ign_christian 2013-07-11 06:39:01 UTC
*** Bug 65837 has been marked as a duplicate of this bug. ***
Comment 11 ign_christian 2013-07-11 06:41:15 UTC
Valuable information by Nick on Bug 65837:
https://bugs.freedesktop.org/show_bug.cgi?id=65837#c11
Comment 12 QA Administrators 2015-04-01 14:41:31 UTC Comment hidden (obsolete)
Comment 13 csongor 2015-04-01 15:44:11 UTC
This bug is indicated as a duplicate of #65837 reported by me. That bug is closed due to the duplication so I write here.

I checked my bug in _my_ latest LO which is:

Verzió: 4.3.1.2
Build az.: 958349dc3b25111dbca392fbc281a05559ef6848

Unfortunately I have no time at the moment to upgrade but I will test it in a newer version LO next week. Meanwhile I wanted to give some feedback. See you next week.
Comment 14 csongor 2015-04-03 07:22:25 UTC
I managed to check it on the following version:

Version: 4.4.1.2
Build ID: 45e2de17089c24a1fa810c8f975a7171ba4cd432
Locale: en_AU
 
The symptom is still the same, the line height is growing unexpectedly. So yes, this is an existing bug.
Comment 15 csongor 2015-04-08 00:20:08 UTC
I checked it on the newest LO version:

Version: 4.4.2.2
Build ID: c4c7d32d0d49397cad38d62472b0bc8acff48dd6
Locale: en_AU

The symptom is the same as I wrote in my original ticket (bug #65837). So yes, this is still an existing bug.
Comment 16 tommy27 2016-04-16 07:27:48 UTC Comment hidden (obsolete)
Comment 17 csongor 2016-04-16 09:54:36 UTC
I can confirm that the bug is present in the newest version:

Version: 5.1.2.2
Build ID: d3bf12ecb743fc0d20e0be0c58ca359301eb705f
CPU Threads: 8; OS Version: Linux 4.2; UI Render: default; 
Locale: en-AU (en_AU.UTF-8)

Compared to my original bug report, a couple of things have been changed.
- 64 bit LO vs 32 bit
- I use Linux instead of Windows
- English OS vs Hungarian OS
- English LO vs Hungarian

So, it seems to be a pretty general bug. And, a pretty old one, it has been present at least since 2013-06-16 when I reported the original bug (https://bugs.documentfoundation.org/show_bug.cgi?id=65837).
Comment 18 Julien Nabet 2016-04-16 22:21:47 UTC
On pc Debian x86-64 with master sources updated today, I could reproduce tdf#65837 (which is very quick to try)

Reverting https://cgit.freedesktop.org/libreoffice/core/commit/?id=1363fe2fa6849aa1ac678ea444c58a82d417eb47 allows to call AdjustRowHeight functions at the Excel import and tdf#65837 was ok (I must admit I haven't retested tdf#34552 before or after reverting this commit)

Here are the lines:
+#if 0
+        // Excel documents look much better without this call; better in the
+        // sense that the row heights are identical to the original heights in
+        // Excel.
         if (pD->IsAdjustHeightEnabled())
             AdjustRowHeight();
-
+#endif
(see http://opengrok.libreoffice.org/xref/core/sc/source/filter/excel/read.cxx#1298)

Eike/Katarina/Markus: any thought?
1) Should we let this as it is for perf (and so wontfix) ?
2) Should we let this block (or remove it since it's "#if 0") and call AdjustRowHeight at a specific location in order to not decrease too much perf?
3) Should we remove the if/endif (+associated comment) and let the 2 instructions? (because we know that perf should be ok now) 
4) other?

(since Kohei removed himself from https://wiki.documentfoundation.org/FindTheExpert, I didn't want to annoy him with this).
Comment 19 csongor 2016-04-17 11:39:56 UTC
I think leaving it as it is, this is the worst possible solution. Just imagine what happens to the user. 

- they are working on a large workbook
- forgets saving because they are concentrating on the formulas, numbers, formatting, etc. 
- changes the colour of the row
- oops, there is a bug, it makes the line height wrong. Never mind, let's undo it
- the colour changes back but the row height does not. Oops, this is another LO bug. Damned.
- Bloody LO, let's forget it once and forever. 

To avoid this annoying situation, I think this bug should be fixed.
Comment 20 Buovjaga 2018-02-17 19:05:22 UTC
*** Bug 115324 has been marked as a duplicate of this bug. ***
Comment 21 QA Administrators 2019-02-18 03:44:32 UTC Comment hidden (obsolete)
Comment 22 csongor 2019-02-18 03:58:12 UTC
I can confirm that the bug is still present in a quite recent (but not the newest) LO:

Version: 6.1.0.3
Build ID: efb621ed25068d70781dc026f7e9c5187a4decd1