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/
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.