[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Arabic support
From: |
Eli Zaretskii |
Subject: |
Re: Arabic support |
Date: |
Wed, 01 Sep 2010 20:55:24 +0300 |
> From: Kenichi Handa <address@hidden>
> Cc: address@hidden, address@hidden, address@hidden
> Date: Wed, 01 Sep 2010 16:08:50 +0900
>
> No, LGSTRING may contain multiple grapheme clusters. In the
> case of arabic, we make LGSTRING for one Arabic word then
> shape it (otherwise, the shaper can't know where in a word a
> consonant appears). So, usually LGSTRING contains multiple
> grapheme clusters for Arabic.
I indeed see under a debugger that the variable rtl gets a negative
value when HELLO is displayed, which means uniscribe_shape tries to
reorder the glyphs, which is wrong, because they are already reordered
by xdisp.c. But there's something else at work here, because even if
I force rtl to be always 1, the display is still wrong and only
slightly different.
Also, it looks like uniscribe_shape is repeatedly called from
font-shape-gstring to shape the same text that is progressively
shortened. For example, the first call will be with a 7-character
string whose contents is
{0x627, 0x644, 0x633, 0x651, 0x644, 0x627, 0x645}
The next call is with a 6-character string whose contents is
{0x627, 0x644, 0x633, 0x651, 0x644, 0x627}
then a 5-character string {0x627, 0x644, 0x633, 0x651, 0x644}, etc.
Note that the first 7-character string is the first word of the Arabic
greeting, properly bidi-reordered for display.
Are these series of calls expected?
- Re: Arabic support, Eli Zaretskii, 2010/09/01
- Re: Arabic support, Kenichi Handa, 2010/09/02
- Re: Arabic support, Eli Zaretskii, 2010/09/02
- Re: Arabic support, Kenichi Handa, 2010/09/02
- Re: Arabic support, Eli Zaretskii, 2010/09/03