GNOME Bugzilla – Bug 795280
Gnumeric uses unicode minus for negative numbers, not hyphen. Other applications mess that up.
Last modified: 2018-04-18 22:18:22 UTC
It appears someone brilliant decided to use a longer dash to make negatives more visible, but, when copy-pasting between apps, this longer dash is used instead of a minus sign, effectively turning what should be numerical values into text strings that can't be used by other applications. How to reproduce: 1. Open a .csv file in gnome that has negative numeric values using a minus -, which will open the default gnumeric application 2. copy from gnumeric into another spreadsheet, like LibreOffice, see that the new values are no longer registering as numbers but as strings because Gnumeric replaced the - (minus) with a − (emdash) 3. Add a '=' before the value in LibreOffice, see an Error:501, and then realize how badly Gnumeric screwed up your tax preparation which could have cost thousands on tax refunds had you not caught the numbers are off....
We don't use an emdash, we use a unicode minus. If LibreOffice doesn't understand unicode, then I would say filing a bug there would be appropriate.
https://blogs.gnome.org/mortenw/2006/06/07/bug-severity-guide/
No application submits text intended to be processed as numrical data using a unicode minus vs a normal -/negative sign. At least none except for Gnumeric. Try pasting a unicode minus into BC and see what happens? Maybe into a C/C++ or Java program for that matter? How about trying to write over the old .csv file that used the ASCII minus/dash for representing numbers and replace it with a unicode dash and see how many applications break? Unicode characters are fine to use for printing, but not for representing data that could be used between applications. Gnumeric's implementation is at fault, not other software for failing to treat a unicode character as a ASCII negative sign. Go on. Find one mainstream application that treats a unicode minus as a numerical negative symbol and treat it as valid input. The whole point of copy-paste operations is to transfer data between applications and windows. The choice to not follow established standards for numerical data and go for a unicode minus breaks this, therefore Gnumeric is broken--not LibreOffice, and all other applications in existence. Therefore it is very appropriate to file a bug here.
You have an attitude and your facts are too often wrong. It's not a good combination. Re LibreOffice, I filed a bug with them since a paste from lowriter shows the same problem. We'll see what they say. They clearly have an issue in that "−1000" [unicode minus] gets formatted right-justified as-if they see it as a number. But LO having an issue, doesn't mean Gnumeric doesn't. That's why I did not close the report outright. The reason LO gets a unicode minus -- whereas Firefox, Emacs, a terminal window, etc. get a hyphen -- is that LO specifically asks for the selection in text/html format. I don't see anything wrong with having unicode minus in text/html format, but we should probably negotiate a more suitable interchange format. One where we cannot confuse "." and ",". For what it's worth: The gnome calculator is happy with unicode minus. Google is happy with unicode minus: http://lmgtfy.com/?q=1%E2%88%921000 Perl6 is happy with unicode minus.
This problem has been fixed in our software repository. The fix will go into the next software release. Once that release is available, you may want to check for a software upgrade provided by your Linux distribution. Going forward we will use Biff8 as interchange format. That's the best I am able to make LO use, but at least it is well defined. The problems of unicode minus and decimal comma versus decimal point therefore no longer come up.