Created attachment 172111 [details] Example file from Excel Attached user-made file contains calculated (such as: K9 cell is =B10-B9; while B9=B4-100 and B10=B5-100; and K9 is one data point in the chart) floating point values. While the cells display the calculated values with one decimal digit, the chart data labels display the full floating point values such as 0,4 becomes 0,400(manyzeroes)6. In case of the K9 cell, replacing the B9 and B10 cells formula with static values fixes the chart data labels precision. Steps to reproduce: 1. Open attached file or its ODS-saved version Actual results: Chart data labels display the floating point values with too many digits. Expected results: Data labels show the floating point values with one decimal digit. LibreOffice details: Version: 7.2.0.0.alpha1+ (x64) / LibreOffice Community Build ID: 91330c503b7eb91d777978018b66890af87cf8f5 CPU threads: 4; OS: Windows 10.0 Build 18363; UI render: default; VCL: win Locale: hu-HU (hu_HU); UI: en-US Calc: CL Also in 6.0, 5.2. But not yet in 5.1. Additional Information: Bibisected using bibisect-win32-5.2 to: URL: https://cgit.freedesktop.org/libreoffice/core/commit/?id=54862a932fc9ccc1788e91629818ec6666ec1c09 author Eike Rathke <erack@redhat.com> 2016-01-14 17:42:54 +0100 committer Eike Rathke <erack@redhat.com> 2016-01-14 17:52:59 +0100 do it right and remove then superfluous mumbo-jumbo Adding CC to: Eike Rathke
Created attachment 172112 [details] The original file saved by Calc as ods - same problem
Created attachment 172113 [details] Screenshot of the original document side by side in Excel and Calc
Reproduced in Version: 7.2.0.0.alpha1+ / LibreOffice Community Build ID: c781776f3c79bbe3175b1452d26c79ebb931a500 CPU threads: 4; OS: Linux 5.7; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
If you widen the columns K, L and M you'll see that the actual values are what is displayed in the chart (and columns B,C,D,G,H,I already contain such intermediary values). The General format rounds values to the available column width. The unexpected values are due to not all decimal numbers being representable as binary floating-point numbers, as usual. Chart does not know about the current column width or the resulting rounded display values. Use ROUND(...;1) or some such on intermediary or final results, or use a 0.0 number format on the final results which then is also used by the chart. However, this will be tackled by ongoing work regarding double to string conversion. Anyway, there'll always be values that are not exactly representable in all arbitrary precisions. Not sure if we could do anything about passing the current display value to chart instead of the actual cell value if the cell has a General format. Or if we even should do so.
Fwiw, Gnumeric for the .xlsx file does the same (with slightly different display values due to a different double to string conversion).
Dear NISZ LibreOffice Team, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug