Created attachment 108993 [details] Example spreadsheet In the attached simple spreadsheet, the values in cells E1, E3, E4 and E5 display with the two high-order (most significant) digits truncated. The cells affected show approximately two digits width of white space to the left of the number, so it is even less clear to the user that truncation is taking place. (See screenshot). As soon as the width of column E is changed from the default, the problem disappears. Expected behaviour: display most-significant digits of a number at all times.
Created attachment 108994 [details] screenshot illustrating problem Note truncation of high-order digits in cells E1, E3, E4, E5
Hi @G.King, thanks for reporting. Reproducible. Win7x64Ultimate Version: 4.3.3.2 Build ID: 9bb7eadab57b6755b1265afa86e04bf45fbfc644 Seems as if default limit of decimal places to visualization for General format it's set up to ten, even the number has all decimal, e.g. put the formula =TEXT(E3;"0,00000000000000") in F3 to verify the number is not truncated. Changing the limit in Menu/Tools/Options/LibreOffice Calc/Calculate - Limit decimals for general number format, for a higher change the visualization limit. (In any case there is a limit to 15 digits plus sign). I'm not sure if it is a bug or it's by design. Changed status to NEW.
(In reply to m.a.riosv from comment #2) > I'm not sure if it is a bug or it's by design. It would be pretty shocking if this were by design. There is nothing to indicate to the user that the values displayed are anything other than the results of the calculation. In fact, it was only by chance that I avoided reporting this as a miscalculation bug.
I also found this bug with LO 4.4 on a Mac. It nearly caused some major embarrassment in sending the results of the spreadsheet calculation to a client, but we fortunately did a sanity check on the numbers and realised they were off by a factor of 100. A basic test case is pretty simple - start a new spreadsheet and type =10000/24 in a cell. The result we see is 6.66666667, which is clearly not correct.
(In reply to michaelp from comment #4) > I also found this bug with LO 4.4 on a Mac. It nearly caused some major > embarrassment in sending the results of the spreadsheet calculation to a > client, but we fortunately did a sanity check on the numbers and realised > they were off by a factor of 100. > > A basic test case is pretty simple - start a new spreadsheet and type > =10000/24 in a cell. The result we see is 6.66666667, which is clearly not > correct. This bug is still present in 4.4.2.2 on Mac OS X 10.9.5. I don't see it on Linux for the same version. This bug should be an immediate blocker on any future release. If a user takes a new spreadsheet and types "=10000/6" into a cell the answer displayed should not be incorrect by three orders of magnitude (" 6.6666667" is displayed instead of "1666.666667"). I've changed the importance to (high, critical) to match other bugs in the bug tracker which are arguably less important.
Please could you try, changing the option: Menu/Tools/Options/LibreOffice calc/General - Use printer metrics for text formatting.
(In reply to m.a.riosv from comment #6) > Please could you try, changing the option: > Menu/Tools/Options/LibreOffice calc/General - Use printer metrics for text > formatting. This does appear to cause the results to display correctly. BUT, it is not a satisfactory solution to this bug. Unaware users will still get incorrect results, and reputational damage will ensue.
Then this is a duplicate of https://bugs.documentfoundation.org/show_bug.cgi?id=78503, issues with that option. *** This bug has been marked as a duplicate of bug 78503 ***
For clarity: the problem discussed here occurs when "Use printer metrics for text formatting" is _disabled_ (the default), which is the opposite of what is described in bug 78503 comment 5. It does sound as though it might be related however.