[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?

reply via email to

[Prev in Thread] Current Thread [Next in Thread]