bug#11860: 24.1; Arabic - Harakat (diacritics, short vowels) don't appear

[YAMAMOTO Mitsuharu]

>>>>> On Sat, 18 Aug 2012 18:33:21 +0300, Eli Zaretskii <eliz@gnu.org> said:

> And w32uniscribe.c sets that flag to TRUE a few lines before it calls
> ScriptShape, because Emacs itself reorders characters:

>   for (i = 0; i < nitems; i++)
>     {
>       int nglyphs, nchars_in_run;
>       nchars_in_run = items[i+1].iCharPos - items[i].iCharPos;
>       /* Force ScriptShape to generate glyphs in the same order as
>        they are in the input LGSTRING, which is in the logical
>        order.  */
>       items[i].a.fLogicalOrder = 1;  <<<<<<<<<<<<<<<<<<<<<<<<

IIUC, the resulting gstring should be ordered as:

  * in the logical order between the grapheme clusters because Emacs
    itself reorders them.
  * in the physical order between the glyphs inside a single grapheme
    cluster because drawing and metric calculation routines for a
    grapheme cluster do not know about the direction.

The font backend driver on the Mac port is implemented as above, and
seems to work correctly.  The APIs used for shaping generates glyphs
either in the physical order (Core Text) or in the logical order
(NSLayoutManager), so I had to reorder the information about the
generated glyphs locally by maintaining a permutation on the glyph
indices.  You can look at the variable `permutation' in the function
`mac_ctfont_shape' (for Core Text, in src/macfont.c) or the function
`mac_font_shape_1' (For NSLayoutManager, in src/macappkit.m) in the
source of the Mac port.

                                     YAMAMOTO Mitsuharu
                                mituharu@math.s.chiba-u.ac.jp