Description: For certain combinations of font, column width, zoom factor and number value and without specifying decimal places in the format, ### is displayed instead of a rounded value that would fit in the cell. With the number value =247/210 occurred with: Liberation Sans 10pt, 2.28cm, 90% Times New Roman 10pt, 1.85cm, 100% Steps to Reproduce: 1. Font, column width and zoom as in description 2. enter calculated value =247/210 3. change zoom factor to see what should happen Actual Results: ### Expected Results: 1.17619048 resp. 1.1761904762 Reproducible: Always User Profile Reset: Yes Additional Info: Maybe round to one less place so that the result fits into the cell. Workaround: different font, zoom factor or column width Version: 24.2.4.2 (X86_64) / LibreOffice Community Build ID: 51a6219feb6075d9a4c46691dcfe0cd9c4fff3c2 CPU threads: 8; OS: Windows 10.0 Build 22631; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: de-DE Calc: threaded
Created attachment 195192 [details] Screenshot of the issue
Instead: 1. Select the relevant cell(s) 2. Format cell ([CTRL]+[1]) 3. Alignment 4. Shrink to fit cell size. IMO, -1 for this request.
Displays too many digits and makes the font unreadably small.
If it always happened, it wouldn't be a bug. But as it is, it's a calculation error when calculating the font width.
Typical would be: a mix of float and double.
What's the original cell number format? For example, let's say you have a fixed amount of decimals: 0.0000 ...or some other number format ("0.????", or scientific, or currency, or fractions, or...). Are you suggesting that the displayed format should change according to zoom factor, or font size, or font type, or...? There are several ways to avoid the "###". The alignment (as in comment 2) is one of them – just set an adequate column width. You could also add a padding (in the borders tab of cell format). What about setting an "Optimal width" for the cell/column (which is not perfect and still has issues under certain circumstances) using an adequate zoom level? The behavior varies, depending on the starting column width and other settings.
The cell format is "Decimal Standard". The displayed format should be independent of font, zoom factor and cell size. The behavior should be consistent. Either always display ### if the unrounded value does not fit in the cell - bad solution. Or round so that the value fits in the cell, in the specified font, zoom factor and cell width. At the moment it is like this: with one font, at a zoom factor of 90% and a cell width of 1.85 cm, it is rounded, and at a zoom factor of 100%, ### is displayed. With the other font and cell width of 2.28, it is rounded at 100%, and at 90%, ### is displayed. That seems wrong to me.
All has nothing to do with tehe format. Type =247/210 in A1 Will show a rounded value. You could set column width without any problem. Will show rounded values. Now zoom step by step. 90% and 60% gives ### Other zoom levels won't be attached. This bug appears in Version: 24.2.4.2 (X86_64) / LibreOffice Community Build ID: 51a6219feb6075d9a4c46691dcfe0cd9c4fff3c2 CPU threads: 6; OS: Linux 6.4; UI render: default; VCL: kf5 (cairo+xcb) Locale: de-DE (de_DE.UTF-8); UI: de-DE Calc: threaded This bug won't appear in LO 7.4.7.2 on the same system. Never will be shown ### in LO 7.4.7.2. So a regression.
Bug appears on different zoom levels. With LO 24801 it won't appear on 90%, but will appear on 60%. Wont appear on Version: 7.6.4.1 (X86_64) / LibreOffice Community Build ID: e19e193f88cd6c0525a17fb7a176ed8e6a3e2aa1 CPU threads: 6; OS: Linux 6.4; UI render: default; VCL: kf5 (cairo+xcb) Locale: de-DE (de_DE.UTF-8); UI: de-DE Calc: threaded Will appear first here with LO 24.2.0.3. I will set this version to the earliest version.
JIC, let's clarify the report. "Real" rounding values (by cell format, round() function or similar) is unrelated. There are several reports about some kind of "inconsistency" in displaying either "###" or a value, with some modified format (e.g. cell alignment) when changing zoom levels. Some reports are related to some patch that modified the behavior in some way. Some reports are related to the font's characteristics (e.g. fixed-width/mono-spaced vs proportional). This report might or might not be a dupe of any of those. I have to point out one relevant item... While changing zoom levels, if a numeric value is displayed at some zoom level, and then "###" is displayed at a higher zoom level (i.e. zooming-in), and finally a numeric value is displayed again at an even higher zoom level, then that's something that might be worth improving. But... If the "###" is displayed (instead of the expected value) when zooming-out, and then with lower zoom levels the value is never seen again (so, always the "###" is seen starting from some zoom level, and zooming out from that point), then there is no bug but a simple natural consequence of zooming out. Anyway, the reported behavior might be a consequence of how many decimals are used while displaying the cell value, the width of the column, the amount of pixels for the column's width at a certain screen resolution and zoom level, and the horizontal size of the specific characters (e.g. numbers) of the specific font/size combination. Not being a developer myself, IDK whether it is possible to adjust the algorithm for "any-and-every" font simultaneously.