Abdelrazak Younes wrote:
Dov Feldstern wrote:
I think that this is unnecessary, at least at the moment. The (a?)
Bidi algorithm has already been implemented in LyX, and it works well.
It's true that Qt and Fribidi do this, but LyX already does it, too.
Not really, no. At least not reliably.
See below.
Also, I'm not sure that we could rely on Qt or Fribidi. These will
work if you output an entire line of text. But what happens when you
don't output the entire line at once? What if you have an inset in the
middle, or an image? Will Qt also manage in this case?
Sure, we just have to cut the lines in integral strings (between two
inset for example) and that's it, Qt will manage the ordering perfectly
in between the insets.
Okay, that may work.
It may, but I'm not sure that it will. And again, I just don't think
that it's necessary, I think LyX is already doing it well enough.
Maybe for Hebrew but Arabic support looks completely wrong and I managed
to crash LyX easily because of bad unicode codepoints (have a look at
encoding.C to see what I mean).
Yes, Arabic is much more complicated, because you have the issue of
"shaping", and that's what encoding.C mainly deals with, I think.
(BTW, how do you set up LyX to work with Arabic? I'd be willing to try
it out if I knew how to set it up --- I can read Arabic.)
For Hebrew, however, the bidi algorithm works very well. So the problems
in Arabic probably stem from the shaping issue, more than from the Bidi
issue. Therefore, I think that unless we can prove that the Bidi
algorithm as implemented in LyX really is problematic, we should just
stick with it.
Dov
