Description: Steps to Reproduce: 1. In lowriter, enter "−1000". (That is not a hyphen, but a unicode minus, 0x2212). 2. Select, Copy, and then paste into A1 in localc. 3. In A2, enter "=A1+1". 4. In A3, enter "=ISNUMBER(A1)" Actual Results: Observed: A1 shows "−1000", right-justified as-if it was recognized as a number. A2 shows an error. A3 shows FALSE. Expected Results: Expected: B1 shows "-999" or "−999". A3 shows TRUE. Further expected: anything not recognized as a number should be shown left-justified after paste. Reproducible: Always User Profile Reset: No Additional Info: Stock OpenSuSE 43.3 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:59.0) Gecko/20100101 Firefox/59.0
(In reply to mwelinder from comment #0) > Observed: A1 shows "−1000", right-justified as-if it was recognized > as a number. Cannot reproduce *right-justified* part with Version: 6.1.0.0.alpha0+ (x64) Build ID: ba69036c8e889237da4bb312d7c5c94066abbfd3 CPU threads: 12; OS: Windows 10.0; UI render: GL; Locale: ru-RU (ru_RU); Calc: CL nor with Version: 5.4.4.2 Build ID: 2524958677847fb3bb44820e40380acbe820f960 CPU threads: 12; OS: Windows 6.2; UI render: default; Locale: ru-RU (ru_RU); Calc: group; neither using copy-paste to cell, nor to formula bar, nor using 2212->Alt+X to use "normal" keyboard input. I suppose that OP used manual right justification on cells, thus "automatic" left justification for texts naturally doesn't work.
> I suppose that OP used manual right justification No. This is into a fresh, empty workbook. However, I lied when I said "enter" in lowriter. I don't know how to do that, so I actually pasted into lowriter (from Gnumeric) which seems to have attached some kind of formatting to it. Mea culpa. FYI, localc is currently requesting text/html format from Gnumeric and that's really not a good idea. I will work on that on my end.
Well the point is to understand Unicode minus so let's set to NEW :)
Can you please make this enhancement?
Dear mwelinder, 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 https://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
in reply to 'MassPing-UntouchedBug': behaviour as in OP with ver.: Version: 7.2.0.0.alpha0+ (x64) / LibreOffice Community Build ID: 18e5e948dd66e41f17b0a63bf631d98aee84a03b CPU threads: 8; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: default; VCL: win Locale: de-DE (de_DE); UI: en-US Calc:
Tested it in M$ as well and it shows the same behaviour as LO. Should we support the unicode minus and threat it like a normal hyphen, or should we just autocorrect it to a hypen when it is entered? git grep \'-\' in the sc folder shows around ~50 places where we have to change the behaviour of LO not knowing if we it causes many side effects. Opinions?
IMO, treating Unicode minus as a minus is better (we could replace it to hyphen *internally* for recognition, it would likely make things easier). Autocorrection at entry would be wrong - especially when the direction is from the more "logically correct" character to the poor generic replacement from the pre-Unicode times.
A note on why I proposed this task to Andreas: MediaWiki has their magic word {{formatnum:}} render Unicode minuses, so formulas with negative values copied from Calc function wiki articles will be broken when pasted into Calc. https://phabricator.wikimedia.org/rMW7f61804bf5c717c5059f92fcccf95b470321c295
(In reply to Buovjaga from comment #9) > A note on why I proposed this task to Andreas: > MediaWiki has their magic word {{formatnum:}} render Unicode minuses, so > formulas with negative values copied from Calc function wiki articles will > be broken when pasted into Calc. > > https://phabricator.wikimedia.org/rMW7f61804bf5c717c5059f92fcccf95b470321c295 Another note: my idea is useless because as Mike pointed out in the chat today, formulas are a kind of programming language and should thus be more strict. So I should just adjust the wiki articles in this case.
(In reply to Buovjaga from comment #9) We had some short discussion about this on IRC; my assumption is that this bug is *not* related to the formulas, which have a strict syntax, and thus should continue to *not* accept the Unicode minus. Eike, could you advise here?
I think we could accept U+2212 − MINUS SIGN for _number input_ in the number scanner, but not preserve it. One would have to apply a number format like General;"−"General if that is wanted. I'm reluctant to support it in formula expressions as well, but so far don't see a compelling reason to not do it (for pasted numbers for example); again, of course not preserving the character. I'd refrain from adding it to the dreaded lazy data typist mode that can start formulas with + or - characters instead of =, that is already confusing enough. Anything showing up with git grep \'-\' sc probably should not be touched at all. Btw, I do not see that such pasted string would result in right-justified cell content as mentioned in comment 0. For me it's left-justified.
Andreas Heinisch committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/34510e6e57e58fb27071564f546bbd420404e66d tdf#117037 - Support Unicode minus (0x2212) in the number scanner It will be available in 7.6.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Xisco Fauli committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/2386279c4f0d91dc0758157578ecf62ae9e1ceaa tdf#117037: svl_qa_cppunit: Add unittest It will be available in 7.6.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Thank you Xisco for the unit test!
I confirm it now works for values, but is the final word that we won't accept unicode minuses in function arguments? Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 69b0fa8a6267a1fa77e77405000f42e8aeba5fa0 CPU threads: 8; OS: Linux 6.2; UI render: default; VCL: kf5 (cairo+xcb) Locale: fi-FI (fi_FI.UTF-8); UI: en-US Calc: threaded
If you read comment 12 you'll see that there is no such final word. However, I don't see much importance, how many formula expressions are created with pasted values containing Unicode minus? Furthermore the compiled expression yields a #NAME! error so there's no doubt it's wrong. Anyway, iff such thing should be supported in the formula compiler then it should _only_ be done for UI input, not any other formula language we support (ODFF, OOXML, API, ...). If the problem is that our Wiki renders Calc formulas with Unicode minus (where even?) as mentioned in comment 9 then change the Wiki formatting.
(In reply to Eike Rathke from comment #17) > If you read comment 12 you'll see that there is no such final word. However, > I don't see much importance, how many formula expressions are created with > pasted values containing Unicode minus? Furthermore the compiled expression > yields a #NAME! error so there's no doubt it's wrong. Anyway, iff such thing > should be supported in the formula compiler then it should _only_ be done > for UI input, not any other formula language we support (ODFF, OOXML, API, > ...). > > If the problem is that our Wiki renders Calc formulas with Unicode minus > (where even?) as mentioned in comment 9 then change the Wiki formatting. Hmm, now that I think about it, I *could* add a JavaScript widget that provides a copying helper like we have in Help. So I could sanitise the minus before it hits the clipboard. Thanks for pushing back and making me have more ideas, I guess :)
(In reply to Buovjaga from comment #18) > Hmm, now that I think about it, I *could* add a JavaScript widget that > provides a copying helper like we have in Help. So I could sanitise the > minus before it hits the clipboard. Thanks for pushing back and making me > have more ideas, I guess :) Went with an even simpler option, just replace minuses with hyphens: https://wiki.documentfoundation.org/WikiAction/edit/Widget:MinusToHyphen Convenient to target as we use the <bdi> element with negative numbers due to RTL compatibility.
Andreas Heinisch committed a patch related to this issue. It has been pushed to "libreoffice-7-5": https://git.libreoffice.org/core/commit/738eed58c12e74b1dd0d1d8f8d741448bde17c2c tdf#117037 - Support Unicode minus (0x2212) in the number scanner It will be available in 7.5.3. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.