Created attachment 97531 [details]
Spreadsheet demonstrating problem of row expanding in height.
Problem description: Opening the attached spreadsheet, I find that some rows on sheet1 expand from 0.10" to 0.18" height. This does not occur with LibreOffice 22.214.171.124 (and earlier); I have observed it with all 4.2 releases I have been able to try (126.96.36.199 and 4.2.3). This is using either the OpenSUSE RPMs or the LibreOffice ones (for 4.2; for 188.8.131.52, I've only used the openSUSE ones).
Steps to reproduce:
1. Open the attached spreadsheet
Current behavior: Row 1627 grows from 0.1" to 0.18" height, and the row indices below 1627 are incorrect until the cursor is moved into a cell on that row.
Expected behavior: All rows (other than row 1) in sheet1 are 0.1" in height.
Operating System: openSUSE
Version: 184.108.40.206 release
Last worked in: 220.127.116.11 release
I confirm regression under Win7x64 using 18.104.22.168
Row 1627 grows looks larger in that release whilst it looks normal in 22.214.171.124
I believe I've seen it in cases other than just opening a file using the openSUSE RPM's, although I wasn't able to find another case using the OEM ones.
Still present in 4.2.4.
There are only 'skip'ped commits left to test.
The first bad commit could be any of: c9046ea7e069426d10e071d0bcb01c64685844c6 2d8ee8e5bf8901874460df1b36b3faceae1cb931
We cannot bisect more!
# bad: [423a84c4f7068853974887d98442bc2a2d0cc91b] source-hash-c15927f20d4727c3b8de68497b6949e72f9e6e9e
# good: [65fd30f5cb4cdd37995a33420ed8273c0a29bf00] source-hash-d6cde02dbce8c28c6af836e2dc1120f8a6ef9932
git bisect start 'latest' 'oldest'
# good: [e02439a3d6297a1f5334fa558ddec5ef4212c574] source-hash-6b8393474974d2af7a2cb3c47b3d5c081b550bdb
git bisect good e02439a3d6297a1f5334fa558ddec5ef4212c574
# good: [4850941efe43ae800be5c76e1102ab80ac2c085d] source-hash-980a6e552502f02f12c15bfb1c9f8e6269499f4b
git bisect good 4850941efe43ae800be5c76e1102ab80ac2c085d
# bad: [a900e72b6357882284c5955bdf939bf14269f5fb] source-hash-dd1050b182260a26a1d0ba6d0ef3a6fecc3f4e07
git bisect bad a900e72b6357882284c5955bdf939bf14269f5fb
# bad: [e1d0365cd2b073a859f59ad0a4584385a66dc611] source-hash-2eea96c702a44ab009743b0d22ef639127f0b57b
git bisect bad e1d0365cd2b073a859f59ad0a4584385a66dc611
# good: [98a55bf95f3ec29298751fd8fba76dd2236dce43] source-hash-58dfc97ca697875c36b7ddf14f5505a93d7b9cf8
git bisect good 98a55bf95f3ec29298751fd8fba76dd2236dce43
# bad: [1f32fb58159d7f43a4bcb838765261d5274cbf38] source-hash-4a169e4203c10ec8f76b9bcb33882c82b65c7bab
git bisect bad 1f32fb58159d7f43a4bcb838765261d5274cbf38
# good: [2a073e18fe4a9176dd35e962655ebf05a1e8d1b9] source-hash-4e938c468a1d1b6e93a4e468bbfe2f4270e37c4b
git bisect good 2a073e18fe4a9176dd35e962655ebf05a1e8d1b9
# good: [e2ef0c10eb06304986b8503584b44f02561ce4b5] source-hash-1b4aadebeb1898686313ff30ef47ddc4336a7444
git bisect good e2ef0c10eb06304986b8503584b44f02561ce4b5
# bad: [2d8ee8e5bf8901874460df1b36b3faceae1cb931] source-hash-777e3930a1e85b9bc97c1852b09802fc389c5e2d
git bisect bad 2d8ee8e5bf8901874460df1b36b3faceae1cb931
# skip: [c9046ea7e069426d10e071d0bcb01c64685844c6] source-hash-f5115e33e4c5e49e9b79ed32fccc193a99c3dc30
git bisect skip c9046ea7e069426d10e071d0bcb01c64685844c6
# only skipped commits left to test
# possible first bad commit: [2d8ee8e5bf8901874460df1b36b3faceae1cb931] source-hash-777e3930a1e85b9bc97c1852b09802fc389c5e2d
# possible first bad commit: [c9046ea7e069426d10e071d0bcb01c64685844c6] source-hash-f5115e33e4c5e49e9b79ed32fccc193a99c3dc30
Still in 126.96.36.199
Still present in 188.8.131.52.
Still present in 184.108.40.206.
A bit more information: if I do Optimal Row Height, the rows all show up with a height of 0.18" (should be 0.10"). I can manually set the row height to 0.10", but if I rerun optimal row height, it goes back to 0.18".
Trying this with other font sizes, it appears that Optimal Row Height never sets a height less than 0.18". I don't believe it's related to file/open per se; this looks like a change in behavior of optimal row height.
This looks very similar to bug 83568.
I've searched the bug lists for other problems related to row height that start in the 4.2 release and added the See Alsos.
*** Bug 80059 has been marked as a duplicate of this bug. ***
Set to 220.127.116.11 - the first version that I could reproduce the duplicate bug 80059 in.
Also to Hardware All - I'm on 32 bits.
In the description of 80059 there is a simple sheet + 'editing' instructions to reproduce.
still reproducible with LibO 4.3.3 and 4.4.0 beta1
since 4.2.x reached the END of LIFE I move this bug from mab4.2 to mab4.3 list.
Here's a much simpler way to reproduce what appears to be this issue.
Start with a completely empty spreadsheet (File->New->Spreadsheet -- yes, that simple!)
into cell A1
Note how rows 1 and 2 get messed up, and how the row indices to the left of the spreadsheet are out of sync with the actual spreadsheet rows.
The behaviour with respect to the originally reported bug (comment 0) changed as of the below commit. The issue reported in comment 12 is a separate issue, and has been raised as bug 88291.
Author: Kohei Yoshida <firstname.lastname@example.org>
Date: Thu Jan 30 22:43:05 2014 -0500
Keep the standard row height situation under control.
With this change, applying cell attributes to default cells will
no longer change the row heights inadvertently.
This seems to have fixed the issue for me, at least as of version 18.104.22.168. Anyone else care to chime in? :-)
I still see that row 1627 looks larger than the others.
LibO 22.214.171.124 Win7x64
Created attachment 112345 [details]
Screenshot showing incorrect row indices
I guess the spreadsheet I attached shows two bugs. Note that the row indices below row 2 are incorrect and not aligned with the actual spreadsheet grid.
(In reply to James L. Hammons from comment #14)
> This seems to have fixed the issue for me, at least as of version 126.96.36.199.
> Anyone else care to chime in? :-)
This bug still exists in 188.8.131.52
There are many other bug reports which would be resolved by reverting the minimal-row-height "feature". This bug only partially describes the symptoms.
Any rows using only using text less than 10pt will have too large a height.
(My usual is 7 or 8pt.)
For those not in the US, for 8pt the default height was 3,6mm, and even smaller for smaller fonts.
It has now jumped to 4,5mm, an increase of 20%. Which leaves 20% fewer lines displayed on a large spreadsheet.
retested attachment 97531 [details]
issue persists in LibO 184.108.40.206 but is gone in LibO 220.127.116.11.alpha1+
Build ID: 6c1cabe677f5eb24b465dd6e316c8c66df64bb29
TinderBox: Win-x86@39, Branch:master, Time: 2015-05-29_06:48:08
Locale: en-US (it_IT)
Row 1627 has the same size as the others in LibO 5.1
so I set status to RESOLVED WORKSFORME
feel free to reopen if you don't agree.
Migrating Whiteboard tags to Keywords: (bibisected)