[Upstream] Calc loses row height value when modifying a cell

Bug #646157 reported by Ilja Sekler on 2010-09-23
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
LibreOffice
Confirmed
Medium
gnumeric (Ubuntu)
Undecided
Unassigned
libreoffice (Ubuntu)
Medium
Unassigned
openoffice.org (Ubuntu)
Undecided
Unassigned

Bug Description

Binary package hint: openoffice.org
Binary package hint: libreoffice

1)
Maverick:
lsb_release -rd
Description: Ubuntu 10.10
Release: 10.10

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

2)
Maverick:
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

Natty:
apt-cache policy libreoffice-impress
libreoffice-impress:
  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

3) What is expected to happen via 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 row height does not change.

4) What happened instead is the the height changed to 0.40". Pressed Ctrl+Z to undo, the color changed back, but the row height did not.

WORKAROUND: Use Gnumeric as this problem does not occur with it.

lsb_release -rd
Description: Ubuntu 10.10
Release: 10.10

apt-cache policy gnumeric
gnumeric:
  Installed: 1.10.8-1ubuntu1
  Candidate: 1.10.8-1ubuntu1
  Version table:
 *** 1.10.8-1ubuntu1 0
        500 http://us.archive.ubuntu.com/ubuntu/ maverick/universe i386 Packages
        100 /var/lib/dpkg/status

Original Report Comments: This is a regression, didn't see this happen on Lucid with ubuntu-proposed at least before 2010-06-03. The bug doesn't exist in the vanilla OpenOffice.org 3.2.1 or 3.3.0beta1 by Sun/Oracle.

openoffice.org-calc 1:3.2.1-6ubuntu2
---
Architecture: i386
DistroRelease: Ubuntu 11.04
InstallationMedia: Ubuntu 11.04 "Natty Narwhal" - Alpha i386 (20101214)
Package: openoffice.org
PackageArchitecture: i386
ProcEnviron:
 LANGUAGE=de_DE:de:en_GB:en
 LANG=de_DE.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.38-5.32-generic 2.6.38-rc6
Tags: natty
Uname: Linux 2.6.38-5-generic i686
UserGroups: adm admin cdrom dialout lpadmin plugdev sambashare

description: updated
Ilja Sekler (ilja-sekler-) wrote :

This excel spreadsheet shows the issue much clearer.

STR:

1. Select the cell A8

2. Check the row height - it is 0,42cm.

3. Change background color.

Actual results: the row height has become 0,96cm, undoing the change in Step 3 doesn't restore the original row height.

Paul Webster (pwebster) wrote :

Is there a ppa to update to to OOo 3.3 in Lucid?

Ilja Sekler (ilja-sekler-) wrote :

> Is there a ppa to update to to OOo 3.3 in Lucid?

Not to my knowledge. None is needed to run any version of the Oracle-OOo in parallel to the Ubuntu's Go-OO. Extracting the content of OOo debs and eventually modifying the value for UserInstallation in openoffice.org3/program/bootstraprc is enough.

In Ubuntu 10.10, libreoffice-calc could not reproduce. Opened attachment via the Terminal:

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

+ Row 8 height is 0.17"

Highlighted row 8, changed background color to black, did not change the row height. Undid this, then highlighted cell A8, changed background color to black, did not change the row height.

Does this work for you?

lsb_release -rd
Description: Ubuntu 10.10
Release: 10.10

sudo add-apt-repository ppa:libreoffice/ppa && sudo apt-get update && sudo apt-get -y upgrade && sudo apt-get -y install libreoffice-calc

apt-cache policy libreoffice-calc
libreoffice-calc:
  Installed: 1:3.3.0-1maverick1
  Candidate: 1:3.3.0-1maverick1
  Version table:
 *** 1:3.3.0-1maverick1 0
        500 http://ppa.launchpad.net/libreoffice/ppa/ubuntu/ maverick/main i386 Packages
        100 /var/lib/dpkg/status

Changed in openoffice.org (Ubuntu):
status: New → Incomplete
Ilja Sekler (ilja-sekler-) wrote :

Retested and reproduced with LibreOffice 3.3.0 on Natty. The only minor difference is the resulting row height after the first change of background color: 1,01cm instead of 0,96cm.

libreoffice-calc:
  Installiert: 1:3.3.0-1ubuntu1
  Kandidat: 1:3.3.0-1ubuntu1
  Versionstabelle:
 *** 1:3.3.0-1ubuntu1 0
        500 http://de.archive.ubuntu.com/ubuntu/ natty/main i386 Packages
        100 /var/lib/dpkg/status

> Does this work for you?

No, the bug is still valid for me.

Changed in openoffice.org (Ubuntu):
status: Incomplete → New

In Ubuntu 11.04, libreoffice-impress confirmed via at the Terminal:

cd ~/Desktop && wget https://bugs.launchpad.net/ubuntu/+source/openoffice.org/+bug/646157/+attachment/1655284/+files/row-height.xls && soffice -calc 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-impress
libreoffice-impress:
  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

Redid the test in Ubuntu 10.10 with libreoffice-impress:

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. It is not known why the prior test in Ubuntu 10.10 libreoffice-impress did not change the height before but does now...

lsb_release -rd
Description: Ubuntu 10.10
Release: 10.10

sudo add-apt-repository ppa:libreoffice/ppa && sudo apt-get update && sudo apt-get -y upgrade && sudo apt-get -y install libreoffice-calc

apt-cache policy libreoffice-calc
libreoffice-calc:
  Installed: 1:3.3.0-1maverick1
  Candidate: 1:3.3.0-1maverick1
  Version table:
 *** 1:3.3.0-1maverick1 0
        500 http://ppa.launchpad.net/libreoffice/ppa/ubuntu/ maverick/main i386 Packages
        100 /var/lib/dpkg/status

Changed in libreoffice (Ubuntu):
status: New → Confirmed
tags: added: lo33

Created attachment 43637
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

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

Created attachment 43637
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

Micah Gersten (micahg) wrote :

Thank you for your bug report. This bug has been reported to the developers of the software. You can track it and make comments at: http://bugs.freedesktop.org/show_bug.cgi?id=34552
Please report any other issues you may find.

Setting to Medium -> Triaged per Christopher M. Penalver

Changed in libreoffice (Ubuntu):
importance: Undecided → Medium
status: Confirmed → Triaged

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

Changed in df-libreoffice:
importance: Unknown → Low
status: Unknown → Confirmed

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

Ilja Sekler, please execute the following command, as it will automatically gather debugging information, in a terminal:
apport-collect 646157
When reporting bugs in the future please use apport by using 'ubuntu-bug' and the name of the package affected. You can learn more about this functionality at https://wiki.ubuntu.com/ReportingBugs.

description: updated
Changed in openoffice.org (Ubuntu):
status: New → Incomplete

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

apport information

tags: added: apport-collected natty
description: updated
description: updated
summary: - Calc loses row height value when modifying a cell
+ [Upstream] Calc loses row height value when modifying a cell
description: updated
Changed in gnumeric (Ubuntu):
status: New → Invalid
Changed in openoffice.org (Ubuntu):
status: Incomplete → Won't Fix

[This is an automated message.]
There are no new official OpenOffice.org releases in Ubuntu packaging anymore => Won't Fix

If the problem persists, please mark this bug as "also affects project Libreoffice" or "also affects distribution Libreoffice (Ubuntu)" if that has not happened already.

Please leave references to upstream OpenOffice.org bugs in place to allow cross pollination.

[This is an automated message.]
This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it
started right out as NEW without ever being explicitly confirmed. The bug is
changed to state NEEDINFO for this reason. 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.
Details on how to test the 3.5.0 beta1 can be found at:
http://wiki.documentfoundation.org/QA/BugHunting_Session_3.5.0.-1

more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html

[This is an automated message.]
This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it
started right out as NEW without ever being explicitly confirmed. The bug is
changed to state NEEDINFO for this reason. 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.
Details on how to test the 3.5.0 beta1 can be found at:
http://wiki.documentfoundation.org/QA/BugHunting_Session_3.5.0.-1

more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html

> 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.

Changed in df-libreoffice:
status: Confirmed → Incomplete

> 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.

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).

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).

Changed in df-libreoffice:
importance: Low → Medium
status: Incomplete → Confirmed

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 ***

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 ***

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.

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.

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?

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?

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").

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").

*** Bug 65837 has been marked as a duplicate of this bug. ***

*** Bug 65837 has been marked as a duplicate of this bug. ***

** 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 on a currently supported version of LibreOffice (4.4.1 or later)
   https://www.libreoffice.org/download/

   *If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior

   *If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System

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)

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: http://webchat.freenode.net/?channels=libreoffice-qa

Thank you for your help!

-- The LibreOffice QA Team This NEW Message was generated on: 2015-04-01

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.

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.

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.

** 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 on a currently supported version of LibreOffice (5.0.5 or 5.1.2 https://www.libreoffice.org/download/

If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior

If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System

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)

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: http://webchat.freenode.net/?channels=libreoffice-qa

Thank you for your help!

-- The LibreOffice QA Team This NEW Message was generated on: 2016-04-16

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).

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).

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.

*** Bug 115324 has been marked as a duplicate of this bug. ***

** 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

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

This release of Ubuntu is no longer receiving maintenance updates. If this is still an issue on a maintained version of Ubuntu please let us know.

Changed in libreoffice (Ubuntu):
status: Triaged → Incomplete
Changed in df-libreoffice:
importance: Medium → Unknown
status: Confirmed → Unknown
Changed in df-libreoffice:
importance: Unknown → Medium
status: Unknown → Confirmed

Synchronising bug status with upstream.

Changed in libreoffice (Ubuntu):
status: Incomplete → Confirmed
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.