Bug 83568 - FORMATTING: Row Height not changing below 10pt since LO 4.2 (see also comment 9)
Summary: FORMATTING: Row Height not changing below 10pt since LO 4.2 (see also comment 9)
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: BSA
Keywords:
: 82058 88750 95420 126490 138163 (view as bug list)
Depends on:
Blocks: Cell-Management
  Show dependency treegraph
 
Reported: 2014-09-06 19:38 UTC by sareneathenodny
Modified: 2024-04-03 15:14 UTC (History)
12 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description sareneathenodny 2014-09-06 19:38:56 UTC
Problem description: 

I have several spreadsheets with font size at 8pt.

Until v. 4.1.6.2 for certain (maybe later), the row height of my cells will automatically adjust to all font sizes down to as small as 6pt (at least).

As of 4.2.5.2 for certain (maybe earlier) and up to 4.3.1.2, the row height of my cells will not automatically resize below 10pt. For any font size below 10pt the row height appears to remain scaled to 10pt. It will resize automatically to fit any font height 10pt and above.

Changing the font does not impact the behavior.

This bug refers to onscreen display. I have not tested it with printing, as I seldom print these docs.

Steps to reproduce:
1. Open a new spreadsheet file.
2. Type something into several consecutive cells in the same column.
3. Select all.
4. Change the font size to 14. 
5. Change the font size to 12. 
6. Change the font size to 10. 
7. Change the font size to 8. 
8. Change the font size to 6. 

Current behavior: 
Row height scales up and down when changing font size to anything 10pt or greater, but remains at 10pt for any font size smaller than 10pt.

Expected behavior: 
Row height should scale down further for font sizes below 10pt.

              
Operating System: Mac OS X
Version: 4.2.5.2 release
Comment 1 Jacques Guilleron 2014-09-07 11:31:59 UTC
Hi,

I just verified this in LO 3.5.3.2, 4.1.6.2, 4.3.1.2 and master, and for me on Windows 7 Home Premium, this was allways so. Under 10pts, row height was never ajust automatically.

regards,

Jacques
Comment 2 sareneathenodny 2014-09-10 21:12:58 UTC
Hi Jacques.

Thanks for the reply.

I'm on Mac OS X (currently 10.9), and the row height still adjusts automatically for me under 10pts with LO 4.1.6.2.

Is it possible that's a feature that was only incorporated in the Mac version?
If so, is it possible to get it back?

Best,
Sean
Comment 3 ign_christian 2014-09-11 09:51:12 UTC
(In reply to comment #1)
> I just verified this in LO 3.5.3.2, 4.1.6.2, 4.3.1.2 and master, and for me
> on Windows 7 Home Premium, this was allways so. Under 10pts, row height was
> never ajust automatically.
Same behavior in Linux (tested with various versions under Ubuntu 12.04 x86).
Comment 4 James L. Hammons 2014-09-19 18:21:55 UTC
Can confirm this on 4.3.0.4, behavior is the same as described in the bug description. This is on a Linux system, 64-bit.

Also, it seems that Calc will at times randomly resize cells or even entire rows to the 10pt height; I can't recall when this started happening but it's fairly recent (I have been using LO and Calc for years now).
Comment 5 A (Andy) 2014-09-20 10:23:31 UTC
reproducible with LO 4.3.1.2 (Win 8.1)

For me it should also scale down the rows below 10pt (even if this was maybe never the case before, what I can unfortunately not test and therefore can't assess).
Comment 6 rlk 2014-10-04 20:53:21 UTC Comment hidden (obsolete)
Comment 7 James L. Hammons 2015-01-12 16:45:31 UTC Comment hidden (obsolete)
Comment 8 sareneathenodny 2015-01-12 22:06:19 UTC
(In reply to James L. Hammons from comment #7)
> Seems to resolved as of version 4.3.2.2; see bug #77592 (comment #13).

Problem is still there exactly as reported for me.
I'm running LO version 4.3.5.2 on OSX 10.9.5.
Comment 9 andréb 2015-02-26 18:34:57 UTC
This is a bug deliberately introducted in libo 4.2
Before this did not occur on Microsoft or Linux versions of libo.

A minimal-row-height of 4,5mm was added.
I also use mostly 8pt text.
Before, a 8pt text (on a single line) gave an automatic row height of 3.6mm.
Any change to a row (in libo 4.3) now automatically gives a row height of at least 4,5mm.  Pre-existing lines that aren't changed will keep their former height.
Comment 10 rlk 2015-02-26 19:20:19 UTC
It appears that there was a bit more to this than simply forcing the row height to be too big -- other operations could inadvertently change the row height.  But it really is broken for the standard row height to be defaulted to a particular value regardless of how small the font is.  With the hideous spreadsheets I use, there's a lot of value to getting as much data as possible on the display; if I had a higher resolution display, I'd set the font even smaller.

I know about the workaround of using fixed line height, but that's not a proper solution.
Comment 11 tommy27 2016-04-16 07:26:32 UTC Comment hidden (obsolete)
Comment 12 Norbert Scheibner 2016-04-16 10:42:08 UTC
Bug is still there and still annoying in 5.1.2.
Comment 13 sareneathenodny 2016-04-16 15:01:10 UTC Comment hidden (obsolete)
Comment 14 QA Administrators 2017-05-22 13:22:31 UTC Comment hidden (obsolete)
Comment 15 rlk 2017-05-22 13:57:38 UTC Comment hidden (obsolete)
Comment 16 sareneathenodny 2017-05-22 14:18:38 UTC
Still present as originally described in LO 5.2.6.2 on macOS 10.12.5.
Comment 17 QA Administrators 2018-05-23 02:36:02 UTC Comment hidden (obsolete)
Comment 18 rlk 2018-05-23 03:00:05 UTC
Still present in LibreOffice 6.0.4.2.

Version: 6.0.4.2
Build ID: 00m0(Build:2)
CPU threads: 8; OS: Linux 4.4; UI render: default; VCL: gtk3; 
Locale: en-US (en_US.utf8); Calc: CL

(openSUSE 42.3 RPMs)
Comment 19 QA Administrators 2019-05-24 02:58:07 UTC Comment hidden (obsolete)
Comment 20 Timur 2019-05-28 13:25:05 UTC
*** Bug 82058 has been marked as a duplicate of this bug. ***
Comment 21 Timur 2019-05-28 13:31:32 UTC Comment hidden (obsolete)
Comment 22 Thomas Lendo 2020-10-10 19:08:48 UTC
Repro with Version: 7.1.0.0.alpha0+
Build ID: 7aaa9ef2e5edaf468f116449776433e98fb1a2f3
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3
Locale: de-DE (de_DE.UTF-8); UI: en-US
TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2020-10-09_22:58:32
Calc: threaded

Also repro with
LibreOffice 3.3.0 
OOO330m19 (Build:6)
tag libreoffice-3.3.0.4
Comment 23 Timur 2021-05-17 10:02:23 UTC
*** Bug 138163 has been marked as a duplicate of this bug. ***
Comment 24 Timur 2021-09-01 12:26:31 UTC
*** Bug 88750 has been marked as a duplicate of this bug. ***
Comment 25 Timur 2021-09-01 12:27:55 UTC
From bug 88750:
The origin of the change:
http://cgit.freedesktop.org/libreoffice/core/commit/?id=29b322ea0c40423a39efe2f6c2c85a7d2108c512

author	Kohei Yoshida <kohei.yoshida@collabora.com>	2014-01-30
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.
Comment 26 Timur 2021-09-01 12:29:38 UTC
*** Bug 95420 has been marked as a duplicate of this bug. ***
Comment 27 Timur 2021-09-01 12:30:09 UTC
*** Bug 126490 has been marked as a duplicate of this bug. ***
Comment 28 Julien Nabet 2022-09-20 19:57:18 UTC
On pc Debian x86-64 with master sources updated today, I could reproduce this.

With this patch:
diff --git a/sc/source/core/data/column2.cxx b/sc/source/core/data/column2.cxx
index 08391bd24150..e1e3c6d468d9 100644
--- a/sc/source/core/data/column2.cxx
+++ b/sc/source/core/data/column2.cxx
@@ -855,9 +855,6 @@ static sal_uInt16 lcl_GetAttribHeight( const ScPatternAttr& rPattern, sal_uInt16
     if (nHeight > STD_ROWHEIGHT_DIFF)
         nHeight -= STD_ROWHEIGHT_DIFF;
 
-    if (nHeight < ScGlobal::nStdRowHeight)
-        nHeight = ScGlobal::nStdRowHeight;
-
     return nHeight;
 }

the scaling process works even with font size < 10.

Eike: any thoughts here? I mean perhaps there would be wrong side effects Kohei wanted to avoid?
Comment 29 Eike Rathke 2024-04-03 12:36:50 UTC
Coming across again, I think this isn't relevant anymore, as commit b0f55a04f081ff7f566c3ba5b6d6d6be3675e0f7 changed that for tdf#123026

@@ -877,8 +878,8 @@ static sal_uInt16 lcl_GetAttribHeight( const ScPatternAttr& rPattern, sal_uInt16
     if (nHeight > STD_ROWHEIGHT_DIFF)
         nHeight -= STD_ROWHEIGHT_DIFF;
 
-    if (nHeight < ScGlobal::nStdRowHeight)
-        nHeight = ScGlobal::nStdRowHeight;
+    if (nHeight < nMinHeight)
+        nHeight = nMinHeight;
 
     return nHeight;
 }

If someone would like to verify please..
Comment 30 Julien Nabet 2024-04-03 15:14:30 UTC
(In reply to Eike Rathke from comment #29)
> Coming across again, I think this isn't relevant anymore, as commit
> b0f55a04f081ff7f566c3ba5b6d6d6be3675e0f7 changed that for tdf#123026
> ...
> If someone would like to verify please..

On pc Debian x86-64 with master sources updated today + gtk3 rendering, I still reproduce this.

With this:
diff --git a/sc/source/core/data/column2.cxx b/sc/source/core/data/column2.cxx
index c4ac17ffe358..f38fe2ab1ccf 100644
--- a/sc/source/core/data/column2.cxx
+++ b/sc/source/core/data/column2.cxx
@@ -860,8 +860,10 @@ static sal_uInt16 lcl_GetAttribHeight(const ScPatternAttr& rPattern, sal_uInt16
     if (nHeight > STD_ROWHEIGHT_DIFF)
         nHeight -= STD_ROWHEIGHT_DIFF;
 
+/*
     if (nHeight < nMinHeight)
         nHeight = nMinHeight;
+*/
 
     return nHeight;
 }

it's ok.

Some debug show nMinHeight = 256, when I select fontsize 10, nHeight = 253.