Hello, everybody. This appended picture shows a test of bidi-display-reordering. The upper case is the case that bidi-display-reordering is nil. The lower case is non-nil. The problem is that the characters are ordered left to right even they should been right to left when bidi-display-reordering is non-nil. This test is in Emacs Ver. 24.0.50.1 (i686-pc-cygwin) on Microsoft Windows XP Professional Version 2002 Service Pack 3.
Shunsuke oshima ej9...@hotmail.com
> Date: Wed, 1 Sep 2010 12:47:23 +0900
> From: due...@it.aoyama.ac.jp
> To: ha...@m17n.org
> CC: e...@gnu.org; emacs-bidi@gnu.org; emacs-de...@gnu.org; jas...@gnu.org
> Subject: Re: [emacs-bidi] Re: Arabic support
>
> We have made similar observations with what might be double reordering
> (or no reordering) on a Windows system. I expect we will report more
> details tomorrow.
>
> Regards, Martin.
>
> On 2010/09/01 11:17, Kenichi Handa wrote:
>> In article<e1oq50d-0006yc...@fencepost.gnu.org>, Eli Zaretskii<e...@gnu.org>
>> writes:
>>
>>>> In Emacs, bidi reordering is done by Emacs itself, so the `shape'
>>>> method of font backend should not reorder glyphs. But, perhaps
>>>> Uniscribe backend reorders Arabic text, right?
>>
>>> No, not AFAIK. We call the ScriptItemize API of Uniscribe with NULL
>>> as the 4th and 5th arguments, which AFAIU should disable reordering.
>>> Perhaps Jason could chime in and tell if I'm right here.
>>
>> I read the function uniscribe_shape roughly. It has this
>> code:
>>
>> for (i = 0; i< nitems; i++)
>> {
>> int nglyphs, nchars_in_run, rtl = items[i].a.fRTL ? -1 : 1;
>> [...]
>> if (SUCCEEDED (result))
>> {
>> int j, nclusters, from, to;
>>
>> from = rtl> 0 ? 0 : nchars_in_run - 1;
>>
>> Doesn't it mean uniscribe_shape reorders glyphs?
>> after ×× × ××××× ×× × >> ×××××
<<attachment: bdr.PNG>>
_______________________________________________ emacs-bidi mailing list emacs-bidi@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-bidi
