https://bugs.documentfoundation.org/show_bug.cgi?id=163082
V Stuart Foote <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW CC| |[email protected] Ever confirmed|0 |1 --- Comment #4 from V Stuart Foote <[email protected]> --- Huh, no idea what secret sauce MS might provide for "...infusing the characters with language". While we clearly implement Unicode bidi support, testing individual characters with ICU lib as "Strong", "Weak", "Neutral" or, "Explicit" and building against ICU lib tested word bounds. Failure in our bidi implementation lies within parsing the logical order text spans composed of some mix of the four categories. In Mike's example the "U+05BE HEBREW PUNCTUATION MAQAF" is strongly typed. So our handling should treat the whole expression to its bounds as a Hebrew language text run. We'd have to recognize it and probably apply Explicit bidi bracketing (i.e. LRE/RLE or LRO/RLO) with or without termination (PDF). In any case requiring additional i18n logic in the editengine(s). Khaled had done some work on the sm Formula editor to implement Arabic formula entry, so imagine some of that work could be applicable to broader bidi handling. =-refs-= https://en.wikipedia.org/wiki/Bidirectional_text https://unicode-org.github.io/icu-docs/apidoc/dev/icu4j/com/ibm/icu/text/Bidi.html -- You are receiving this mail because: You are the assignee for the bug.
