Dov Feldstern wrote:
Abdelrazak Younes wrote:
Dov Feldstern wrote:
The main problem I see right now with Arabic is that the widths of
the letters are not calculated correctly. This means that letters may
not totally connect with their neighbors, because their glyph doesn't
totally cover the space given to them. (Are you seeing the same
problem?) It sounds like this is related to the metrics calculations
(see
http://thread.gmane.org/gmane.editors.lyx.devel/79740/focus=79928,
although it looks like there has been some work done since then, so
I'm not sure if that is still relevant or not). If that is, in fact,
the case, then I don't think that moving to Qt will help us solve
this problem (correct me if I'm wrong?).
It will help, you can retrieve the proper metrics information thanks
to this method:
int QFontMetrics::charWidth ( const QString & text, int pos ) const
Returns the width of the character at position pos in the string text.
The whole string is needed, as the glyph drawn may change depending on
the context (the letter before and after the current one) for some
languages (e.g. Arabic).
This function also takes non spacing marks and ligatures into account.
Abdel.
Would this also allow you to determine the correct position when moving
the cursor over existing text?
Yes.
If so, then if you want to try to let Qt
do this, I'm open to suggestions. I'm still not sure what we'll gain by
letting Qt do it, though.
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.
Also, I think that any discussion of this should take into account *all*
Bidi issues we have. For example, those that I raised in
http://thread.gmane.org/gmane.editors.lyx.devel/80783/focus=80783.
Yes. I haven't answered this one because I am not sure I understand what
is the problem. For me, a word is a word is a word, independently from
the language of the space before... but I don't really know what I am
talking about.
We
have to be aware of the fact that our backend (latex) doesn't
necessarily behave exactly according to standard Bidi rules; and we do
have to make sure that the gui and backend behave in the same way;
Sure.
therefore the fact that we have control over the Bidi algorithm provides
us with more flexibility than we would have if the gui's bidi were not
our own.
I would rather say that we have to output a LateX file that will give
the correct output. But again, I don't know what I am talking about
(LateX ignorant here).
And again, there's always the issue to keep in mind of the possibility
of wanting to use a different frontend in the future which doesn't
support bidi in exactly the same way that Qt does...
As I said multiple times, this is a not a valid point. We are certainly
not going to switch to a non unicode capable toolkit. Even so, there are
plenty other alternative out there.
Besides, we should aim to reduce code in LyX, not add more. Using nice
and supported software is good.
OK Dov, I think I've summarized my points, I'll let you decide with
Mostafa how to go further. I will support any decision you make ;-)
Abdel.
- Re: improving Arabic-like language support Abdelrazak Younes
-
