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
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
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
(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).
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).
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).
This looks very similar to bug 77592.
Seems to resolved as of version 4.3.2.2; see bug #77592 (comment #13).
(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.
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.
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.
** 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
Bug is still there and still annoying in 5.1.2.
Bug still present exactly as originally described in v5.0.5.2 on OSX 10.11.4. (I'm the OP)
** 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.2.7 or 5.3.3 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 helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20170522
Still reproduces with LibreOffice 5.3.3.2 (Linux 64-bit, openSUSE 42.2 RPMs). No change in behavior from described.
Still present as originally described in LO 5.2.6.2 on macOS 10.12.5.
** 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
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)
Dear sareneathenodny, 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
*** Bug 82058 has been marked as a duplicate of this bug. ***
Repro 6.3.
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
*** Bug 138163 has been marked as a duplicate of this bug. ***
*** Bug 88750 has been marked as a duplicate of this bug. ***
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.
*** Bug 95420 has been marked as a duplicate of this bug. ***
*** Bug 126490 has been marked as a duplicate of this bug. ***
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?
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..
(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.