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 ej9460@hotmail.com > Date: Wed, 1 Sep 2010 12:47:23 +0900 > From: duerst@it.aoyama.ac.jp > To: handa@m17n.org > CC: eliz@gnu.org; emacs-bidi@gnu.org; emacs-devel@gnu.org; jasonr@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, Eli Zaretskii 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?