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.
(1) Paint Hebrew/Arabic characters one at a time, so that Qt's Bidi
algorithm doesn't get applied. This is the easiest solution, and also
the most conservative, and therefore least likely to introduce new bugs.
I think that this is definitely the way to go at least until 1.5.0 is
released. This does have the disadvantage, however, of painting the
characters one at a time, which may be less efficient (does anyone know
if this really makes a significant difference?).
Probably not much.
I have no idea.
Attached is a patch applying this fix. Hebrew should now work even with
real, legal, locale settings! (I haven't tested the Arabic at all, I
have never used Arabic in LyX and have no idea what the current state
is, or what it ever was. I also am not currently set up for testing
Arabic, and I'm not sure how one would go about it. I'd be happy to get
any input on this.)
Each and every arabic letter has a different shape if it is at the
beginning, the middle or the end or a word. So it would really be better
to let Qt handle that really.
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:
There is no need for fixing, just for deleting.
[...]
* I'm not sure that using Qt's Bidi would mean that we wouldn't need
to use our own anyhow. We'd still need to know how things look on the
screen, for laying out insets; for cursor movements across the screen;
etc. So would we really be able to just use Qt's bidi?
I agree with you here, this last point being the main reason.
I still disagree and still think we should let Qt decide at word level
and disable the LyX bidi code there. Arabic support is obviously broken
now. But as I haven't done anything up to now, I won't complain.
Abdel.
