Created attachment 98785 [details] Sample file to test Win7x64Ultimate Version: 4.2.3.3 Build ID: 882f8a0a489bc99a9e60c7905a60226254cb6ff0 Version: 4.2.5.0.0+ Build ID: 948728a4159a8ba74ecc663373d31f1840fed9ac TinderBox: Win-x86@42, Branch:libreoffice-4-2, Time: 2014-05-09_01:06:23 Last working: Version: 4.2.2.1 Build ID: 3be8cda0bddd8e430d8cda1ebfd581265cca5a0f In the attached file, when value doesn't keeps in O3 the ##### are showed mixed with value showed in cell N3
Hello Miguel Angel, I don't reproduce with LO 4.2.4.1, LO 4.3.0.0.alpha1+ Build ID: 657004ae5c9f4a07b2cdafbb21bc8657842d4d74 TinderBox: Win-x86@39, Branch:master, Time: 2014-05-08_00:35:12 & Windows 7 Home Premium I join a screenshot. regard, Jacques
Created attachment 98983 [details] How it looks for me.
Created attachment 98987 [details] Configuration file with the ussue.
Created attachment 98988 [details] How it looks for me with the issue. Hi Jacques, thanks for review. I have forgot to try with a clean profile, what solve the issue, that is in the registrymodifications.xcu attached. I haven't the tools to find what in the configuration file is the source of the issue. But will be nice to find it, there are sometimes issues when updating with the user profile.
Created attachment 100730 [details] Sample file to test I think I have found where to begin the search. When the option for calc: Menu/Tools/Options/LibreOffice cal/General - Use printer metrics for text formatting is enable shows the issue, if disable not. Visible how E1 overlaps D1, and I1 overlaps H1. But even without it enable, I think it's not fine how those cells are shown partially. Reproducible with a clean user profile: Version: 4.2.5.1 Build ID: 881bb88abfe2992c6cede97c23e64a9885de87de Version: 4.2.6.0.0+Win-x86@42, Branch:libreoffice-4-2, Time: 2014-06-04_14:23:07 Version: 4.3.0.0.beta2 Id. compilation: a06aa316117a6ff0f05c697c82831c227812d810 Version: 4.4.0.0.alpha0+Win-x86@39, Branch:master, Time: 2014-06-04_04:27:18 Last version working for me: Version: 4.2.4.2 Build ID: 63150712c6d317d27ce2db16eb94c2f3d7b699f8
(In reply to comment #5) > Created attachment 100730 [details] > Sample file to test I can reproduce with that file with 4.3.1.0.0+ Time: 2014-07-30_10:54:10 under Ubuntu 12.04 x86 This bug is quite strange. I also have similar but different issue in Bug 66089
*** Bug 88593 has been marked as a duplicate of this bug. ***
This might be the same bug as 88593 although in my case only certain column widths produce it. The numbers are displayed correctly with some bigger _or_ smaller column widths. I don't mind if the numbers are obscured with ## characters in too narrow columns but in my case I got totally incorrect values when LibreOffice 4.3.4 and 4.3.5 omit significant numbers and misplace the decimal comma (see the attached screenshot and sample file). The decimal comma is misplaced so, depending on the column width, the displayed number is 70-2000 times more than it really is. So, depending on the column width the calculation 7830 * 0,45 = 3551,6282571 is displayed as the following variations: ,628 1,6283 51,62826 3552 (correct) 3551,6 (correct) 3551,63 (correct) 3551,62826 (correct) I had prepared the spreadsheet in an older version of LibreOffice and after upgrading to v4.3.4 I noticed the incorrect result in one cell. Setup: Mac mini (Late 2009), OS X 10.10.1. Locale setting Finnish -- otherwise default settings. Resetting the user profile does not help. BTW, on a MacBook Pro Retina the incorrect values are displayed VERY briefly before changing to the correct values. I had to watch out this very carefully and even then didn't always notice it when the file opens. On the other hand, LibreOffice 4.2.3 displays the correct spreadsheet numbers on the Mac mini. I have found some workarounds to fix the issue: 1. LibreOffice Calc > General > Use printer metrics for text formatting ON 2. LibreOffice Calc > Calculate > Limit decimals for general number format ON 3. Format > Cells... > Numbers > Number > Format: use some other setting than General
Created attachment 112726 [details] How it looks for me Depending on the column width the calculation 7830 * 0,45 = 3551,6282571 (in red) is displayed as the following variations: ,628 1,6283 51,62826 3552 (correct) 3551,6 (correct) 3551,63 (correct) 3551,62826 (correct)
Created attachment 112727 [details] Sample file
Created attachment 112729 [details] How it looks for me Depending on the column width the calculation 7830 * 0,45 = 3551,6282571 (in red) is displayed as the following variations: ,628 1,6283 51,62826 3552 (correct) 3551,6 (correct) 3551,63 (correct) 3551,62826 (correct)
*** Bug 89208 has been marked as a duplicate of this bug. ***
*** Bug 89474 has been marked as a duplicate of this bug. ***
*** Bug 90091 has been marked as a duplicate of this bug. ***
*** Bug 85942 has been marked as a duplicate of this bug. ***
*** Bug 90615 has been marked as a duplicate of this bug. ***
*** Bug 90984 has been marked as a duplicate of this bug. ***
*** Bug 90952 has been marked as a duplicate of this bug. ***
** Please read this message in its entirety before responding ** 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 on a currently supported version of LibreOffice (5.1.5 or 5.2.1 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System 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) http://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: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20160920
Seems works with 5.2.2.1, although columns wide change a bit with/without using printer metrics.
The content of attachment 98987 [details] has been deleted