Created attachment 149356 [details] Sample Type number with dash in RTL text very difficult. When typing in empty line (paragraph) number with dash (from password, national id) it is work ok. When type number with dash inside arabic text it is doing by block from right to left like ...-222-111 but must be 111-222-... I found similar report with bug id 118137 but there using slash (/) and it is ok for me, but. Google docs, Microsoft Office Online have same problem
I confirm it with Version: 6.3.0.0.alpha0+ (x64) Build ID: f42554a1886ebe49170c25096dc3281b2c7bb1f4 CPU threads: 4; OS: Windows 10.0; UI render: default; VCL: win; TinderBox: Win-x86_64@42, Branch:master, Time: 2019-02-08_22:37:30 Locale: en-US (de_DE); UI-Language: en-US Calc: threaded and Version: 5.4.7.2 (x64) Build-ID: c838ef25c16710f8838b1faec480ebba495259d0 CPU-Threads: 4; BS: Windows 6.19; UI-Render: GL; Gebietsschema: de-DE (de_DE); Calc: CL
1. Your sample doesn't have dashes, it has minus signs. While those are often used instead of dashes, they're not the same thing. 2. Suppose we treat the minus sign as a dash. Why would the dash not appear _after_ the number, i.e. to the right of the number? It's reasonable to assume that the dash will be followed by more text, in which case the placement is valid. What _could_ be a bug is: 1. If we treat the minus as a minus sign, which is obviously a possibility - then it should be one number minus another number, so the minus should be placed to the right of the digits. 2. If we treat the minus as a dash, the fact that it's directly adjacent to a number suggests it is more likely to be continued by another number rather than by an RTL character. But what we really need to do is look at the Unicode bidirectional algorithm (UAX 9) and see what is says on this matter. It's located here: http://www.unicode.org/reports/tr9/ it's not an easy read, though.
Oh, also - same behavior with Hebrew. Same behavior in GTK text widgets. Same behavior in Qt text widgets. What is this like in Office? ... I have the sense that this is just a somewhat unopportune choice in the Unicode algorithm.
(In reply to Eyal Rozenberg from comment #2) > 1. Your sample doesn't have dashes, it has minus signs. While those are > often used instead of dashes, they're not the same thing. 1. Yes you right it is like minus (HYPHEN-MINUS, decimal code 45). In english keyboard it is only one symbol with short horizontal line (except LOW LINE, decimal code 95 ). In Arabic keyboard i see symbol ـ (it is ARABIC TATWEEL), but it is have same problem. Temporary solution is use Ctrl + "-" (but it have visual problem, i will do new bug report) > 2. Suppose we treat the minus sign as a dash. Why would the dash not appear > _after_ the number, i.e. to the right of the number? It's reasonable to > assume that the dash will be followed by more text, in which case the > placement is valid. Yes, minus sign is show after the number i.e. to the left side of the number and if we continue type text it is show correct. But i not sure it is good for mathematics formulas inside arabic text (like Alice in mirrorland). 2. BUT if you type only numbers in empty paragraph or before (from begin) arabic text like "arabic_text 1-2-3-4-5" it is work good for RTL, but adding any arabic letter in begin of string will do mirror number to "... 5-4-3-2-1 ..." > > What _could_ be a bug is: > > 1. If we treat the minus as a minus sign, which is obviously a possibility - > then it should be one number minus another number, so the minus should be > placed to the right of the digits. > Sure > 2. If we treat the minus as a dash, the fact that it's directly adjacent to > a number suggests it is more likely to be continued by another number rather > than by an RTL character. > > But what we really need to do is look at the Unicode bidirectional algorithm > (UAX 9) and see what is says on this matter. It's located here: > > http://www.unicode.org/reports/tr9/ > > it's not an easy read, though. Thanks for link, but please check my report #2 in this message, may be it helped dedicate problem
I check Office 2013 - it have same problem, but libreoffice is better because is show correct number with dash/minus on empty string or begin arabic string
That is how Unicode Bidirectional Alogorithm works, the same as bug 118137. You can manually insert left-to-right mark after the hyphen.
(In reply to Khaled Hosny (inactive) from comment #6) > That is how Unicode Bidirectional Alogorithm works, the same as bug 118137. > You can manually insert left-to-right mark after the hyphen. To be honest, I wonder if that's the right call to make. This situation (digits, no space, then minus or slash) could be special-cased in the algorithm.
(In reply to Eyal Rozenberg from comment #7) > (In reply to Khaled Hosny (inactive) from comment #6) > > That is how Unicode Bidirectional Alogorithm works, the same as bug 118137. > > You can manually insert left-to-right mark after the hyphen. > > To be honest, I wonder if that's the right call to make. This situation > (digits, no space, then minus or slash) could be special-cased in the > algorithm. You would need to address this with Unicode, applications tweaking the algorithm on their own (except where it is explicitly permitted by the algorithm) is just a recipe for broken interoperability.