Often when I open a spreadsheet, LibreOffice Calc changes row heights arbitrarily. For example, I'll create a new sheet, ensure that all rows are at the optimal/default height, then save and close the spreadsheet. When I open it again, the new sheet will often have some rows that are still the default/optimal height, but others will be two or three times as high. I haven't noticed any particular pattern as to which rows have the wrong height. The cells are all empty, so wrapping is (or ought to be!) irrelevant. Same thing can happen if I switch sheets and then later return to the new, blank sheet. I do have lots of sheets in my spreadsheets, some with a mixture of cells that have wrapping on, and cells that don't. Recalculate on File Load "Optimal row height" option is set to "always recalculate"
I'm currently using version 24.8.7.2 on Windows 11 64-bit, but the problem was occurring in a number of previous versions, too.
Please test in safe mode, Menu/Help/Restart in Safe Mode Please attach a sample file, reduce the size as much as possible without private information, and paste the information in Menu/Help/About LibreOffice, there is a copy icon.
Created attachment 201133 [details] A sample file - all blank rows should be the default height, but aren't I didn't try to make the file smaller in case the size contributes to the problem. I expect the blank rows on the GrdHon-ddMMMyyyy and Blank_GrdHon-ddMMMyyyy_100rows sheets to be the default height, but they're not. I haven't been able to identify a pattern as to when or where the problem will occur.
Comment on attachment 201133 [details] A sample file - all blank rows should be the default height, but aren't FYI, I do have a macro that I wrote for use on the ListOfSheets sheet in the sample file. It's not essential, so feel free to keep macros disabled. I don't think that will have any impact on the bug, though I haven't tried it.
Just tried safe mode and macros disabled. I still see wrong row heights when I open the file.
After applying the Optimal Height to those rows, saving and reopening works fine. Maybe that height was established for those rows inadvertently. Version: 25.2.4.2 (X86_64) / LibreOffice Community Build ID: 508ff62361999404a9d3590fe47df713b5888744 CPU threads: 16; OS: Windows 11 X86_64 (10.0 build 26100); UI render: Skia/Raster; VCL: win Locale: en-US (es_ES); UI: en-US Calc: CL threaded
jmling+bugzilla@pm.me, I remember something recent about this in a bug that have been solved. Can you check this bug on a 25.2.4 version?
If you select one row and apply a different font size, the optimal height will action different. Will consider the font height. Row 1: apply a 30 font size. Row 2: apply a 10 font size. Apply to both Optimal size. See differences. Also if you select row 10 from your sheet, you can see the font size is not there, meaning you have different font size in different cells on that row.
Hi all, I've updated to the version indicated below and still see the problem, although it seems to be less frequent. Still very unpredictable. I just now made a copy of one of my template files, pasted some info from a website into it, did some cell merges and word-wrapping/unwrapping, and noticed a row 10 rows or so below what I pasted in and another row a few rows further down from there were the wrong height. I checked my template file--the rows were fine. I made a second copy of the template and pasted in the same data, repeating the merges and wrapping/unwrapping steps, and saw no problem. I didn't jump around from sheet to sheet in my second copy though, as I'd done in the first one. As a software developer, I hated intermittent and unpredictable bugs, so if you decide to reduce the the severity and just keep an eye out for things that might cause such problems, I won't quibble. Regarding font sizes, yes, I would expect optimal height to adjust for that. Word-wrapping affects optimal height too, also as I would expect. Version: 25.2.4.3 (X86_64) / LibreOffice Community Build ID: 33e196637044ead23f5c3226cde09b47731f7e27 CPU threads: 8; OS: Windows 11 X86_64 (10.0 build 22631); UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded
Another factor to consider is that I'm often working with at least 90% memory usage. I'm thinking uninitialized or stale data being used to set row heights or a timing issue, maybe related to Windows swap file (or whatever it's called) being used for memory management.
In bug 108601 comment 20 I posted analysis for a file that shows this issue reliably.