Bug 52393 - FILEOPEN 3.5.x spreadsheet with wrong row height
Summary: FILEOPEN 3.5.x spreadsheet with wrong row height
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
3.6.0.2 rc
Hardware: Other All
: medium critical
Assignee: Markus Mohrhard
URL:
Whiteboard: target:3.7.0 target:3.6.0
Keywords: regression
: 52329 52434 56779 (view as bug list)
Depends on:
Blocks: mab3.6
  Show dependency treegraph
 
Reported: 2012-07-23 12:25 UTC by Rainer Bielefeld Retired
Modified: 2013-12-09 15:11 UTC (History)
8 users (show)

See Also:
Crash report or crash signature:


Attachments
Test Kit (74.76 KB, application/x-7z-compressed)
2012-07-23 12:25 UTC, Rainer Bielefeld Retired
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Rainer Bielefeld Retired 2012-07-23 12:25:31 UTC
Created attachment 64539 [details]
Test Kit

Steps how to reproduce with Server Installation of  "LibreOffice 3.6.0.2 rc  German UI/Locale [Build-ID:  815c576] on German WIN7 Home Premium (64bit):

1. open sample spreadsheet from attached test kit
   Expected: Black border below cell with "description" at height 90mm 
             (Ruler picture)
   Actual: Black border below cell with "description" at app 75mm 
             (Ruler picture)

Yo can see my results in the 2 PDF in test kit

Was ok until Beta3 (rc1 not tested), so rather new problem. 
Or result of a bug fix?
Comment 1 billhook 2012-07-24 07:13:30 UTC
Is this a duplicate of 
https://bugs.freedesktop.org/show_bug.cgi?id=52329 ?
Comment 2 Rainer Bielefeld Retired 2012-07-24 07:30:07 UTC
> Is this a duplicate of Bug 52329 

Currently I do not think so, this is a FILEOPEN bug, Bug 52329 is a FILESAVE bug
Comment 3 Rainer Bielefeld Retired 2012-07-24 07:55:20 UTC
*** Bug 52329 has been marked as a duplicate of this bug. ***
Comment 4 Rainer Bielefeld Retired 2012-07-24 08:03:27 UTC
Confirmed by DUP.

Indeed row height when opened with 3.6.0.2 is at least very close nearby optimum.

Although several details are different (Version where appeared, ...) this one might have similar roots like "Bug 51446 - FILEOPEN: All columns have the same default width 22,58mm"

@Daniel:
What do you think?
Comment 5 Rainer Bielefeld Retired 2012-07-24 09:20:24 UTC
The more I think about this issue the more I think that my suspect concerining relation to Bug 51446 is wrong.
Comment 6 vitriol 2012-07-24 10:00:58 UTC
@Rainer
Please, evaluate potential dup Bug 52434
Comment 7 Rainer Bielefeld Retired 2012-07-24 11:31:30 UTC
This one seems fixed with parallel installation of Master "LOdev " 3.7.0.0.alpha0+   - WIN7 Home Premium (64bit) ENGLISH UI [Build ID: b0a7277]" (tinderbox:Win-x86@6, pull time 2012-07-24 06:37:14)

Has someone a latest 3.6.0 build available to check whether it's ok for 3.6, too?
Comment 8 Claude 2012-07-25 05:29:03 UTC
Indeed, the problem seems opening a file.  I´ve discovered it opening (LO3602) a file created in LO355.  Sorry I mislead you, because the attachments in bug 52329 where created and saved with LO3602.  In fact the row height change  occurs on opening a correct formatted file, which still opens rightly in LO355.
Comment 9 Akira Matsumiya 2012-07-25 13:46:44 UTC
I also confirmed this bug.

3.6.0rc1 is no problem.
But 3.6.0rc2 is reproduced on Ubuntu11.10 and Windows7.

Does this behavior have to do with this fix?
https://bugs.freedesktop.org/show_bug.cgi?id=50304
Comment 10 Daniel Bankston 2012-07-25 16:14:29 UTC
I've looked a bit at the issue reported, and I don't think it has anything to do with 51446.

I'm going to discuss it more with Markus and/or Kohei.
Comment 11 Rainer Bielefeld Retired 2012-07-25 17:22:19 UTC
Makes Calc more or less unusable
Comment 12 Markus Mohrhard 2012-07-25 17:36:54 UTC
Will look into it.
Comment 13 Markus Mohrhard 2012-07-25 18:02:33 UTC
It looks like 3.5 is the one that is totally wrong in this case. I checked with a 3.4 build and that looks much more like 3.6 than 3.5.

Also the exported values look correct after import to 3.6 and export. I'll need to look closer at it.
Comment 14 vitriol 2012-07-25 18:10:11 UTC
(In reply to comment #13)

> It looks like 3.5 is the one that is totally wrong in this case. I checked with
> a 3.4 build and that looks much more like 3.6 than 3.5.

But version 3.6 cannot display its own changes after saving...
Comment 15 vitriol 2012-07-25 18:13:56 UTC
(In reply to comment #14)
> (In reply to comment #13)
> 
> > It looks like 3.5 is the one that is totally wrong in this case. I checked with
> > a 3.4 build and that looks much more like 3.6 than 3.5.
> 
> But version 3.6 cannot display its own changes after saving...

Minimal steps to reproduce:

https://bugs.freedesktop.org/show_bug.cgi?id=52434#c4
Comment 16 Markus Mohrhard 2012-07-25 23:01:33 UTC
(In reply to comment #15)
> (In reply to comment #14)
> > (In reply to comment #13)
> > 
> > > It looks like 3.5 is the one that is totally wrong in this case. I checked with
> > > a 3.4 build and that looks much more like 3.6 than 3.5.
> > 
> > But version 3.6 cannot display its own changes after saving...
> 

Ok, master is not affected by this problem. I have currently no more ideas what is going wrong. Debugging shows that the value is set correctly and I did not see that it is overriden. Additionally all sc commits for 3-6 seem to be correct.
Comment 17 Markus Mohrhard 2012-07-25 23:26:11 UTC
Can you please test if that is really a pure 3.6.0.2 problem? After looking at the code and the fix used in master I suspect it should be a 3-6 problem introduced before beta1.
Comment 18 Rainer Bielefeld Retired 2012-07-26 07:11:01 UTC
*** Bug 52434 has been marked as a duplicate of this bug. ***
Comment 19 Rainer Bielefeld Retired 2012-07-26 07:27:30 UTC
(In reply to comment #17)
> Can you please test if that is really a pure 3.6.0.2 problem? 

At least due to my observations confirmed by comments in DUPS 3.6.0.1 was not affected.

The most simple sample document is Attachment 64603 [details] in Bug 52434
In older versions row height is much bigger than character height, 3.6.0.2 opens with optimum row height (more or less character height + some little distance to borders).
Comment 20 Markus Mohrhard 2012-07-26 21:02:18 UTC
Finally fixed this bug.
Comment 21 Not Assigned 2012-07-26 21:12:19 UTC
Markus Mohrhard committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=c55cfd273cf1d4666b91fc9a00c71b049c34adec

mark manual row heights correctly during import, fdo#52393
Comment 22 Not Assigned 2012-07-27 01:09:37 UTC
Markus Mohrhard committed a patch related to this issue.
It has been pushed to "libreoffice-3-6":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=a7f82f201e1b2653ac03e1833e273c6752868641&g=libreoffice-3-6

mark manual row heights correctly during import, fdo#52393


It will be available in LibreOffice 3.6.1.
Comment 23 billhook 2012-07-27 05:30:26 UTC
So 3.6.0 will ship with this bug?
Comment 24 Rainer Bielefeld Retired 2012-07-27 05:58:00 UTC
> So 3.6.0 will ship with this bug?

@billhook:
As you can see, this Bug still is in Status ASSIGNED. For integration into 3.6.0 the fix needs reviews, what takes some time. So I currently do not see any indications that this fix will not be available for 3.6.0
Comment 25 Not Assigned 2012-07-27 09:21:24 UTC
Markus Mohrhard committed a patch related to this issue.
It has been pushed to "libreoffice-3-6-0":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=eb84b4678a16cc48f1fdb21098b1fc978800a83e&g=libreoffice-3-6-0

mark manual row heights correctly during import, fdo#52393


It will be available already in LibreOffice 3.6.0.
Comment 26 Maciej Rumianowski 2012-11-29 15:26:14 UTC
*** Bug 56779 has been marked as a duplicate of this bug. ***