When using the format code <"d =" 0.00> on a cell containing -1.23, the cell wrongly displays "-d = 1.23" instead of "d = -1.23". (Seen with LO 4.3.6.2)
This is not a bug - just the incorrect number format. Set to "d="#.## without the <> and you'll get the right answer
Sorry, I have been unclear. I was using the angle brackets to quote the format code - I did not use them *in* the code. I did not know that the # sign can be used instead of 0. However, using "d="#.## still gives me the wrong -d=1.23 . Can't anyone reproduce this? Maybe it's dependent on the localization settings. I am using German LibreOffice on German Windows 7, with the standard document language set to English (USA) to get a period as decimal separator (bug 46448).
REOPENED is incorrect status - moving to UNCONFIRMED.
Could not reproduce. Please test with 4.4.3. For completeness: what operating system are you using? Set to NEEDINFO. Change back to UNCONFIRMED, if the problem persists. Change to RESOLVED WORKSFORME, if the problem went away. Win 7 Pro 64-bit, Version: 4.4.3.2 Build ID: 88805f81e9fe61362df02b9941de8e38a9b5fd16 Locale: fi_FI
Ok, I am now on 4.4: Version: 4.4.3.2 Build-ID: 88805f81e9fe61362df02b9941de8e38a9b5fd16 Gebietsschema: de_AT The language settings are now all set to default: Benutzeroberfläche (User Interface): Standard - Deutsch (Deutschland) Gebietsschema (Localization Scheme): Deutsch (Österreich) Standardsprachen der Dokumente - Westlich (Standard language): Deutsch (Österreich). The bug remains: Using "d="#,## gives me -d=1,23 . (I am always testing in new documents.) Switching localization scheme and standard language to English (USA) does not help. I will attach a screenshot. I assume the user interface language depends on the Windows language? Btw., I'm seeing this on two different machines, with Windows 7 Pro 64-bit.
Created attachment 115617 [details] screenshot of the bug
Created attachment 115684 [details] test file I can confirm with LO Version: 4.4.4.0.0+ Build ID: 1a2a094795e10f514eb421e68bbd705ea5251b76 TinderBox: Linux-rpm_deb-x86_64@46-TDF, Branch:libreoffice-4-4, Time: 2015-05-14_09:47:46 anf LO 3.5
** 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
I still see the but (e.g. with raal's attached test file) in: Version: 5.2.1.2 Build-ID: 31dd62db80d4e60af04904455ec9c9219178d620 CPU-Threads: 8; BS-Version: Windows 6.1; UI-Render: Standard; Gebietsschema: en-US (de_AT); Calc: group
** 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.4.1 or 5.3.6 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-20170929
The problem is still there, there is a in between solution, not a nice one "d= "-#.## So entering 1.23 will give you "d= -1.23" tested with Version: 6.0.0.0.alpha0+ Build ID: 19910c461230f70bb9e98ad44db3525f0d755724 CPU threads: 8; OS: Linux 4.9; UI render: default; VCL: kde4; Locale: nl-BE (en_US.UTF-8); Calc: group; and 5.4.3
** 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 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 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: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
I still see the bug in 6.0.6.2 on Linux Mint 19.
Dear Robert Pollak, 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 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: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
I still see the bug (with raals test file) on Version: 6.3.1.2 Build ID: 1:6.3.1~rc2-0ubuntu0.18.04.1~lo1 CPU threads: 8; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: en-US (en_DK.utf8); UI-Language: en-US Calc: threaded Note that Xavier's comment 11 is not a workaround, since it includes manually replacing negative values by positive ones. This does not work for computed values with arbitrary sign.
repro in Version: 7.1.0.0.alpha0+ Build ID: 2047a5978ac8188e61da9cd3b2f40d86df5570bb CPU threads: 4; OS: Mac OS X 10.15.5; UI render: default; VCL: osx Locale: ru-RU (ru_RU.UTF-8); UI: en-US Calc: threaded
You must defined your positive and negative format: "d = "0.00;"d = "-0.00 or "d = "0.00;"d = minus"0.00 Calc cannot guess where you want your negative sign. For instance, you may want it on left side of the cell: +* 0.00;-* 0.00 If you do not define a format for negative values, then Calc use as default: -format for positive value Check help about Number format codes: https://help.libreoffice.org/6.4/en-US/text/shared/01/05020301.html?DbPAR=SHARED#bm_id3153514
Thanks, Laurent. Looks like this was never a bug, so tweaking status.
For me and four other commenters here this violates the principle of least surprise. What about the definition: If you do not define a format for negative values, then Calc uses the format for positive value as default, with "-" inserted in front (or wherever the locale demands) of the _actual_number_. Why should the sign be anywhere else in this case?
(In reply to Robert Pollak from comment #19) > For me and four other commenters here this violates the principle of least > surprise. > > What about the definition: > If you do not define a format for negative values, then Calc uses the format > for positive value as default, with "-" inserted in front (or wherever the > locale demands) of the _actual_number_. > > Why should the sign be anywhere else in this case? I just described how spreadsheets work from decades. There exists many conventions to represent negative number (colored in red, between brackets). The default one was defined as "add a minus sign on the most left position". If you prefer a different one, you can define it through format codes given above. Changing default behavior is quite risky.
> Changing default behavior is quite risky. You are right. So I suggest adding the minus (-) sign as a new placeholder in number format codes, telling where the minus of negative numbers should be displayed. This would yield the simple format code "d =" -0.00 for my case.