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 [email protected] > Date: Wed, 1 Sep 2010 12:47:23 +0900 > From: [email protected] > To: [email protected] > CC: [email protected]; [email protected]; [email protected]; [email protected] > 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<[email protected]>, Eli Zaretskii<[email protected]> >> 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 [email protected] http://lists.gnu.org/mailman/listinfo/emacs-bidi
