Bug 125068 - Accepting the real minus as a minus sign
Summary: Accepting the real minus as a minus sign
Status: RESOLVED WONTFIX
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
6.2.3.2 release
Hardware: All All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-05-01 20:50 UTC by Frank Brütting
Modified: 2019-06-10 15:31 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Frank Brütting 2019-05-01 20:50:50 UTC
Description:
Would be good if the real minus character (`−`, U+2212) would work as a minus prefix, like the current dash does. If I for example write my numbers with the real minus (like `−1`), Calc handles the number as text instead of like a number. Also the numbers would look better, as the real minus has exact the same width as the plus sign.

Steps to Reproduce:
1. Format a cell number-specific (like number "# %")
2. Type −1 in that cell

Actual Results:
Cell is handled like text and "# %" isn’t applied.

Expected Results:
Cell should be handled as number.


Reproducible: Always


User Profile Reset: No



Additional Info:
Comment 1 V Stuart Foote 2019-05-02 03:54:14 UTC
Seems ill conceived, how exactly would one "enter" the U+2212 MINUS SIGN Unicode glyph? Normal keyboard input/keysym inputs the U+002D HYPHEN-MINUS Unicode glyph/

The 0x2212 glyph, from the Mathematical Operators Unicode BMP, is generally a typographic symbol.

Also, glyph appearance is totally controlled by the font selected. LO default is Open Symbol which has some weight issues, but you can work in alternate fonts that have better agreement between the "+" 0x002b and "-" 0x002d glyphs.
Comment 2 Regina Henschel 2019-05-02 10:56:30 UTC
The formula syntax as written to file format must use the HYPHEN-MINUS.
Changing the parser to allow MINUS SIGN in addition to HYPHEN-MINUS wouldn't be a worthwhile effort.
For entering a formula, it would be no help to allow MINUS SIGN.

If you want a display of the formula using MINUS SIGN, that is already possible by defining a format code. For example the format code
   General;"−"General
would produce an appearance with typographical correct minus.
Instead of the symbol 'General' you need to use the symbol, that is set for your language, for German it is 'Standard' for example.
Comment 3 Frank Brütting 2019-05-03 22:11:39 UTC
You can type the real minus easily with advanced keyboard layouts like Neo2 (neo-layout.org). Otherwise, you can include it by the usage of pasting from symbol tables, like the one inbuilt one or e.g. gnome-characters. Both of which are frequently used by me and surely a lot of other people for pasting other glyphs like ⇒, ≤, ≄, ≉, ⊆, ؉, • and greek letters, to name a few examples.

The Hyphen-minus is not really a minus, because it’s just a hyphen, as the length is too short for being a minus, by definition. In reality, it’s just a dirty hack, that hyphens get used as minuses, because most keyboard layouts don’t have a real minus easily reachable (without ALT/ALT_GR, etc.).

Exactly the same issue is the dash, being double the length of the hyphen (and most keyboards also not providing the dash conveniently). Word for example fixes this by auto-replacing hyphens with dashes, when heuristics detect that a hyphen should in reality be a dash (I don’t know if Writer does the same, as I deactivated some auto-replacement settings). It would only be consequent to do the same with minuses, as hyphen-minuses are even more ugly than hyphen-dashes, because they are regularly used in conjunction with pluses, which makes the discrepancy immediately visible.
Comment 4 V Stuart Foote 2019-05-03 23:43:47 UTC
Efficiency of formula input, not typography, is the functional requirement of the Calc module.

Ability to input/parse alternate glyphs (regardless of input method) while *convenient* would require rework of core functions--and IMHO the dev effort is not justified, => WF
Comment 5 Frank Brütting 2019-05-07 16:33:26 UTC
Isn’t this possible by just handling the real minus like the fake minus? I.e. mapping one to the other? So like operator overloading?
Comment 6 Frank Brütting 2019-05-07 16:34:17 UTC
And what means “WF”?
Comment 7 V Stuart Foote 2019-05-07 17:25:11 UTC
(In reply to zyklon87 from comment #6)
> And what means “WF”?

WF: for Bugzilla bug status -> WONTFIX

https://bugs.documentfoundation.org/page.cgi?id=fields.html#bug_status

And IMHO this issue of typography of the Unicode 0x2212 MINUS SIGN from the Unicode Mathematical Operators BMP block, rather than our spreadsheet legacy and perfectly functional 0x002d HYPHEN-MINUS is exactly that.

If you want/need the glyph for typographic formatting of Calc cells, use the format code as Regina indicates comment 2

Otherwise for keyboard data input the 0x002d is suited to task, and would not be worth dev effort to support input of alternate glyphs for formula operators. 

Again IMHO a clear WONTFIX for this feature request.
Comment 8 Eike Rathke 2019-05-08 10:40:23 UTC
We could add U+2212 MINUS SIGN to the lexical tokenizer for formula expressions and treat it like a U+002D HYPHEN-MINUS operator minus, whereas every output of the formula expression would display the U+002D HYPHEN-MINUS again. Maybe we could even recognize it for a simple numeric cell input. We probably could not catch every possible place where a negative number can be entered and is consumed, so it would work in some context and in others wouldn't. Not much desirable for me..
Comment 9 Xisco Faulí 2019-06-10 15:31:06 UTC
(In reply to Eike Rathke from comment #8)
> We could add U+2212 MINUS SIGN to the lexical tokenizer for formula
> expressions and treat it like a U+002D HYPHEN-MINUS operator minus, whereas
> every output of the formula expression would display the U+002D HYPHEN-MINUS
> again. Maybe we could even recognize it for a simple numeric cell input. We
> probably could not catch every possible place where a negative number can be
> entered and is consumed, so it would work in some context and in others
> wouldn't. Not much desirable for me..

Closing as RESOLVED WONTFIX then.