Georg Baum wrote:
Dov Feldstern wrote:
So that explains the bug. Now, to the possible solutions:
Dov, you are definitely a hero! The outcome of the analysis is simple (and
does not surprise me), but it was probably a lot of work.
Thanks... Yeah, it took a while, since the changes that caused the
problem to reappear really have nothing to to with RTL/Bidi, and only
indirectly, by chance, affect it...
I can tell you that isComposeChar_arabic and isComposeChar_hebrew are
definitely wrong. They still assume the old encodings. Fixing them is easy,
but tedious: You have to translate each explicit codepoint in
src/encoding.C from the old encoding to ucs4. The old encodings are
probably iso8859-8 (hebrew) and iso8859-6 (arabic), but I am not sure.
Maybe you can have a look at the hebrew part?
I'll try to look at it at some point. Note, however, that in Hebrew (and
also in Arabic, I believe), the compose characters are only used for
"points" ("nikud" in Hebrew), which are the equivalent of vowels, and
are expressed by dots or lines printed above, below, or inside the
letters. (That's why they have to break the grouping --- they should
really be placed at the same position as the letter with which they
appear.) However, nikud is usually omitted, so this is not a
high-priority feature (although it certainly would be nice to have). In
fact, I have never seen a version of LyX which fully supported nikud ---
the backend chokes on it, too. So this is not really a regression
relative to older versions, but a new feature. I'll open a new feature
request for this in bugzilla.
Meanwhile I am going to apply a slightly modified version of your patch.
Great, thanks! It seems to be working perfectly now, straight out of svn.
Dov
