https://bugs.documentfoundation.org/show_bug.cgi?id=163082
--- Comment #5 from Eyal Rozenberg <[email protected]> --- (In reply to V Stuart Foote from comment #4) > 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. Are you 100% sure that implication is mandated by the UBA? It's not what MS Notepad does. It's not what GTK text widgets do. It's not what Kate does (so, Qt widgets). > 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). Not 100% sure what "it" is. And not following the logic for applying bidi embed or override characters... do you mean you believe that's how MS Word is implementing its behavior? Anyway, the way I see it, once 148527 is implemented (whenever that is), we'll need to both: 1. Reconsider which chars have what kind of directionality, given that we know their language. 2. Feed the UBA characters with amended directionality (which may mean a modified UBA implementation, or a preprocessing introducing marks, although that doesn't sound fun). 3. Make sure we extract the language info from the OOXML and apply it. -- You are receiving this mail because: You are the assignee for the bug.
