Dov Feldstern wrote:
Abdelrazak Younes wrote:
Right now the transformChar() is called only before painting, which is
wrong because cursor positioning happens at metrics calculation time.
So to solve this we have two solution:
1) we move the RTL logic out of rowpainter.C and use transformChar()
in FontMetrics.[Ch] to properly calculates the character level within
each word.
2) we use Qt for word level bidi stuff for painting and metrics. This
means that on-screen appearance will be correct even if you didn't set
the language to Hebrew, Arabic or Farsi. It will just work.
I see what the problem is, I think. I'm not yet sure how to solve it,
though. Abdel, you may be right ;)
Ahh, I am glad you discovered that by yourself :-)
--- we may have to let Qt take care
of this --- although I fear that doing that will be a nightmare...
Don't be so pessimistic! We'll see.
And I
still don't know that that will solve the issue, either. I'm playing
around with this a bit now, but in the meantime I just wanted to let you
know what I've found out:
The problem is this: the metrics are getting filled in incorrectly,
because of the reason stated in the warning here
http://doc.trolltech.com/4.2/qfontmetrics.html#width. (This Qt method is
called from
http://www.lyx.org/trac/browser/lyx-devel/trunk/src/frontends/qt4/GuiFontMetrics.C#L193,
which is ultimately called from
http://www.lyx.org/trac/browser/lyx-devel/trunk/src/frontends/qt4/QLPainter.C#L271
during the painting.)
Not only. GuiFontMetrics is also used indirectly in
BufferView::updateMetrics() which tells each inset to update its metrics.
So basically, we won't be able to cache the font
metrics.
We will and we already are, see above.
As I said, I'm still looking at this, but if anyone has any suggestions,
I'd be happy to hear...
The only thing to do is to modify GuiFontMetrics a bit so that it take
into account Arabic shaping.
Abdel.
