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.
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? 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.
Dov
In addition, there are occasions in which ambiguities do arise, and in
those cases, explicit direction control codes are needed (HTML, for
example, includes all kinds of explicit control for overriding the
general behavior of the Bidi algorithm). So if we're in the situation
where we already have explicit control (setting the language), I think
we're better off not playing around with it, at least for the moment.
