Dov Feldstern wrote:
Abdelrazak Younes wrote:
This is not only about the bidi algorithm but also about unicode.
Right now, everything about RTL is based on the assumption that
encodings matters for the display. It does not.
I don't understand what you mean --- can you be more specific? What in
RTL is based on the assumption that the encodings matter?
With Unicode, encodings should not matter at the character level. In
pre-unicode time, the encoding mattered to understand an 8 bits character.
I think that
the Bidi algorithm looks at the language (as defined in LyX) rather than
the encoding of the letters themselves
This is exactly the problem. The Bidi algorithm in LyX will reorder the
letters inside a Word depending on the language and encoding settings.
It may be OK for Hebrew because the characters set used to fit in a
single byte in pre-unicode time. But this is not OK for Arabic and other
asian languages AFAIK.
Just another thought on this issue: this also has some GUII
implications, in the sense that if we decide to use Qt for the Bidi,
I said that we should Qt at letter level. We can still use our own Bidi
at word level.
that means that any other frontend that we may decide to use must also
do the right thing with Bidi. This may or may not be a problem, but we
need to be aware of this before deciding to adopt this path.
Sure but most modern toolkits do bidi just fine.
So, to summarize, the problems will not be solved automagically if we
manage to disable Qt bidi algorithm.
Actually, for Hebrew I think they will. For Arabic, you're right --- the
shaping is very encoding dependent, and therefore the move to unicode
will affect that a lot. But that's not a Bidi issue, per-se. I'm not
sure how entangled these two issues are in the code, however.
We should not implement two different algorithms for Hebrew and Arabic
IMHO. See above.
Abdel.
