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?
Is this a duplicate of https://bugs.freedesktop.org/show_bug.cgi?id=52329 ?
> Is this a duplicate of Bug 52329 Currently I do not think so, this is a FILEOPEN bug, Bug 52329 is a FILESAVE bug
*** Bug 52329 has been marked as a duplicate of this bug. ***
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?
The more I think about this issue the more I think that my suspect concerining relation to Bug 51446 is wrong.
@Rainer Please, evaluate potential dup Bug 52434
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?
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.
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
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.
Makes Calc more or less unusable
Will look into it.
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.
(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...
(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
(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.
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.
*** Bug 52434 has been marked as a duplicate of this bug. ***
(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).
Finally fixed this bug.
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
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.
So 3.6.0 will ship with this bug?
> 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
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.
*** Bug 56779 has been marked as a duplicate of this bug. ***