Re: Arabic support

[Eli Zaretskii <eliz@gnu.org>]

> From: Jason Rumney <jasonr@gnu.org>
> Cc: Kenichi Handa <handa@m17n.org>,  emacs-bidi@gnu.org,  emacs-devel@gnu.org
> Date: Thu, 02 Sep 2010 21:48:29 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > 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.
> 
> The documentation seems to imply that, but it looks like items[i].a.fRTL
> is being set anyway according to how uniscribe thinks the direction
> should be.

My interpretation of this is that the fRTL flag is set according to
the explicit directionality of the character deduced solely from its
codepoint, e.g. it is TRUE for Hebrew and Arabic letters and FALSE for
the rest.  By contrast, a "full Unicode bidirectional analysis" that
ScriptItemize is advertised to perform when these arguments are
non-NULL includes the full implementation of UAX#9, under which
embeddings and implicit levels can affect the fRTL flag for characters
whose inherent attributes would say otherwise.

But that's a guess; the MS documentation is not very explicit on this,
to say the least.

> As well as removing the code that takes notice of the rtl flag and tries
> to reverse the output, you will probably have to set
> items[i].a.fLogicalOrder to 1 before calling ScriptShape to ensure
> logical order output from ScriptShape.

Right, thanks for the hint.  However, given what Handa-san wrote, I'm
now utterly confused regarding the issue of ordering between Emacs and
Uniscribe.