Dov Feldstern wrote:
Abdelrazak Younes wrote:
Andr� Poenitz wrote:
On Tue, Jan 02, 2007 at 10:53:47AM +0100, Abdelrazak Younes wrote:
Georg Baum wrote:
I have no idea why, and I don't have any idea why we need the \rtl
flag in lyxrc. Why is RTL display not derived from the language?
Hum, I've done some thinking about that... Instead of the language,
maybe we can base the RTL display upon the unicode codepoints and
set the language automatically as well if we detect hebrew or arabic?
I doubt this will work with numbers and punctuation.
We might have to adjust punctuation and number treatment, indeed but
this is exactly what Qt does when you pass it a whole string mixing
arabic and english. As a matter of fact, this is also what Fribidi does.
I guess the solution to our RTL problem is just to completely delete
our painting support code and rely on Qt to do right thing. This just
mean that we send complete string instead of single word.
Abdel.
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.
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.
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).
Abdel.
