Bug 85942 - High-order digits truncated when display value approaches default column-width
Summary: High-order digits truncated when display value approaches default column-width
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
4.3.2.2 release
Hardware: IA64 (Itanium) All
: high critical
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-11-05 21:40 UTC by G.King
Modified: 2015-04-16 15:32 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:


Attachments
Example spreadsheet (19.07 KB, application/vnd.oasis.opendocument.spreadsheet)
2014-11-05 21:40 UTC, G.King
Details
screenshot illustrating problem (69.14 KB, image/png)
2014-11-05 21:42 UTC, G.King
Details

Note You need to log in before you can comment on or make changes to this bug.
Description G.King 2014-11-05 21:40:30 UTC
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.
Comment 1 G.King 2014-11-05 21:42:38 UTC
Created attachment 108994 [details]
screenshot illustrating problem

Note truncation of high-order digits in cells E1, E3, E4, E5
Comment 2 m.a.riosv 2014-11-05 22:08:17 UTC
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.
Comment 3 G.King 2014-11-06 01:57:30 UTC
(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.
Comment 4 michaelp 2015-03-02 23:43:53 UTC
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.
Comment 5 Steve Holt 2015-04-08 23:36:40 UTC
(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.
Comment 6 m.a.riosv 2015-04-08 23:58:27 UTC
Please could you try, changing the option:
Menu/Tools/Options/LibreOffice calc/General - Use printer metrics for text formatting.
Comment 7 G.King 2015-04-09 12:56:13 UTC
(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.
Comment 8 m.a.riosv 2015-04-09 13:44:25 UTC
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 ***
Comment 9 G.King 2015-04-09 17:13:49 UTC
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.