In a cell with default (automatic) formatting, using a column width of 0.90" and Calibri size-12 font, the number 5385137647.06696 is displaying as 37647, regardless of whether the cell produces the value from function or has the value written to it directly. The actual value is not lost, and manually choosing scientific notation corrects the display problem. Changing the cell width a sufficient amount in either direction also corrects the problem, triggering automatic scientific notation for the correct value when narrower, and the full length value when wider. Creating a new spreadsheet, adjusting the font of any cell to the above specifications, and placing 5385137647.06696 in that cell reproduces the effect (the default column width of 0.89" is within the necessary range).
Created attachment 109130 [details] Sample file showing the bug. Hi @Alexander, thanks for reporting. Reproducible. Win7x64Ult. Version: 4.2.7.2 Build ID: 933c0aa564ec4f8883ed5732c866db48dca4dac5 + Version: 4.4.0.0.alpha1+ Build ID: 8b21b5cbe78945b27525b4ce78ae3d981f90590f TinderBox: Win-x86@39, Branch:master, Time: 2014-11-06_03:55:51
Also reproducible with LO 4.3.3.2, Win 8.1.
I found the same on OSX 10.10 in LibreOffice 4.2.6.3 Build-ID: 3fd416d4c6db7d3204c17ce57a1d70f6e531ee21 Ill try to add another Attachement.
Created attachment 109265 [details] Broken formattting
Prio high as this may lead to completly wrong numbers
Bibisect results from 43all point to # first bad commit: [0acca754077bf74469c3e1a3c7eabbc3da795266] source-hash-5e651d4084df7662b56ea980934c0428ba31b062 Which is ~certain to be the below commit: commit 087a79db1272858f107656c5ca3c6efb45680986 Author: Kohei Yoshida <kohei.yoshida@collabora.com> Date: Tue Apr 15 20:47:37 2014 -0400 fdo#75665: Truncate string when clipped on screen. This improves performance of text layouting by HarfBuzz for very long strings. HarfBuzz's layout algorithm appears to be more expensive than ICU's. Change-Id: Ic9738b7b8f0f1a29c51c83b147763118939b90ef Bug 82377 is related to the same commit and has previously been patched, but I still see this issue on current 5.0 master
I have observed the same behavior on OS X 10.10.13 and LibreOffice 4.3.7.2.
*** Bug 93107 has been marked as a duplicate of this bug. ***
*** Bug 93260 has been marked as a duplicate of this bug. ***
Taking.
Eike Rathke committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=2a06a052b920f696a794c2fb847fce63038220e9 Resolves: tdf#86024 do not attempt to shorten numeric value output It will be available in 5.1.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Pending review https://gerrit.libreoffice.org/17636 for 5-0 https://gerrit.libreoffice.org/17637 for 4-4 https://gerrit.libreoffice.org/17638 for 5-0-1
Eike Rathke committed a patch related to this issue. It has been pushed to "libreoffice-5-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=de44c2459b85a2a804155fb38b9b30c713789c3d&h=libreoffice-5-0 Resolves: tdf#86024 do not attempt to shorten numeric value output It will be available in 5.0.2. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Eike Rathke committed a patch related to this issue. It has been pushed to "libreoffice-4-4": http://cgit.freedesktop.org/libreoffice/core/commit/?id=0f3d6a1bfb397d661390aaf3456adfcf418165e9&h=libreoffice-4-4 Resolves: tdf#86024 do not attempt to shorten numeric value output It will be available in 4.4.6. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Eike Rathke committed a patch related to this issue. It has been pushed to "libreoffice-5-0-1": http://cgit.freedesktop.org/libreoffice/core/commit/?id=e4bb1a1e2f4d48c8661b917ff4e5792f953ba6ff&h=libreoffice-5-0-1 Resolves: tdf#86024 do not attempt to shorten numeric value output It will be available in 5.0.1. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Migrating Whiteboard tags to Keywords: (bibisected) [NinjaEdit]