https://bugs.documentfoundation.org/show_bug.cgi?id=174013
Justin L <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.documentfounda | |tion.org/show_bug.cgi?id=12 | |3026 Summary|XLSX: Optimal row height |FILEOPEN XLSX: Optimal row |incorrectly calculated with |height incorrectly |large defaultRowHeight |calculated using large | |defaultRowHeight (comment | |5) Resolution|NOTABUG |--- Keywords| |filter:xlsx OS|Linux (All) |All Version|26.2.6.3 release |Inherited From OOo Status|RESOLVED |NEW Blocks| |108897 Hardware|x86-64 (AMD64) |All Ever confirmed|0 |1 --- Comment #5 from Justin L <[email protected]> --- I noted that: -NASTY_ROW_HEIGHT.xlsx has always opened up with these excessively large row heights (because the provided 'ht' attribute had a large value). (I tested LO 5.3 and 4.1.6.2. Prior to that this document crashed on loading.) -the first row says its height (ht) is 99.75 (but customHeight = false, so the height should be ignored and an optimal height should be used). -MS Excel does open up the file with row 1 using an optimized row height. It is NOT large like LO does it. Apparently LO does not allow an optimal row height smaller than the default height? Well, that makes sense since my patch calls the variable mnOptimalMinRowHeight. But apparently MS Excel doesn't operate in the same way. Likely the row height issues are typically dealing with undefined rows. In that case it makes sense that 'optimal height' is set to a minimum defaultRowHeight. But as soon as a row has a definition, it can be analyzed to determine an optimal height (based on either the content or the cell style font size). It does seem strange that this hasn't been noticed before. But I guess that it is very uncommon to have a defaultRowHeight value that is larger than a single line of text. My guess is that LO does not attempt to use empty cells to calculate the optimal size. And it is also uncommon to have an 'ht' value that is incorrect (or that it is missing). By default, if customHeight is not specified, it means false. So an 'ht' without a customHeight=true/1 is just useful historical info, not a specification. That means that only a row that has no definition at all should be affected by sheetFormatPr? IIUC that must be true. Anything that has a <row> definition is optimally sized based on actual content or cell style font size. Optimization is not done only if customHeight=true. So then, it is entirely possible that my patch was simply wrong. Let's set this bug report to NEW and make it about simply opening the provided file and noticing that row 1 is excessively large. As noted, this has been true as far back as can be tested. Steps to reproduce: -open comment 1's attachment 209122 -notice that row 1 is very tall - much taller than it needs to be/than in Excel. This appears to be a fundamental difference between how LO is designed and how Excel operates. LO treats the defaultRowHeight as an 'at least' value for optimal height, while Excel doesn't do that at all. Referenced Bugs: https://bugs.documentfoundation.org/show_bug.cgi?id=108897 [Bug 108897] [META] XLSX (OOXML) bug tracker -- You are receiving this mail because: You are the assignee for the bug.
