Re: Patch to fix bug 134036
Diego Iastrubni <[email protected]>
| Newsgroups | gmane.comp.kde.devel.pim,gmane.comp.kde.internationalization.hebrew |
|---|---|
| Message-ID | <[email protected]> |
Shai Berger wrote: > I think deciding to choose an algorithm that contradicts the Unicode standard > is a mistake -- you choose to present some texts differently from > standard-complying implementations. In the process, you kill the option of > putting an RLM/LRM as the first character to set the direction, blur the > distinction between strong and weak directionality, and probably damage marks > of direction embedding. Can you point me to the rationale behind this > decision? > I kindly disagree... see seccion 4.3 of the Bidi Algorythm, called Higher Levels protocols, and in seccion 3.3.1 we see this text (*): Because paragraph separators delimit text in this algorithm, this will *generally *be the first strong character after a paragraph separator or at the very beginning of the text. Note that the characters of type LRE, LRO, RLE, or RLO are ignored in this rule. This is because typically they are used to indicate that the embedded text is the /opposite/ direction than the paragraph level. I think we can test using another algorythm for automatic determination of the text direction if the text itself does not include any LTR/RTL markups, nor the user specified any direction (input widgets). I just saw many ways in which the older code failed, and I want to test a new and "hopefuly better" way. (*) http://unicode.org/reports/tr9/ _______________________________________________ KDE PIM mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-pim KDE PIM home page at http://pim.kde.org/