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

[YAMAMOTO Mitsuharu]

>>>>> On Sat, 18 Aug 2012 11:45:27 +0900, Kenichi Handa <handa@gnu.org> said:

> If this problem happens only for bidi scripts, one
> possibility is that Emacs's rendering engine (xdisp.c)
> expects glyphs in a glyph-string are rendered in that order
> from left to right, but the returned glyph-string on Windows
> should be rendered in reverse order.  For instance, in the
> above case, we may have to render glyphs in this order
> (diacritical mark first):

>   [0 1 1593 760 0 3 6 12 4 [1 -2 0]]
>   [0 1 1593 969 8 1 8 12 4 nil]

The font backend driver on the Mac port is supposed to support
right-to-left shaping (including for non-BMP chars, though I don't
have a good example), and it gives the following result (diacritical
mark comes first) for Courier New 13pt:

  mac-ct:-*-Courier New-normal-normal-normal-*-13-*-*-*-m-0-iso10646-1
by these glyphs:
  [0 1 1618 760 8 0 2 11 -8 [-1 2 1]]
  [0 1 1593 969 8 0 6 5 4 [-1 0 8]]

In the above example, the grapheme cluster consists of glyphs having
non-nil adjustments (the last element of each vector).  In the
function Ffont_shape_gstring, there is some code that merges grapheme
clusters generated by a font backend driver so each of them starts
with a glyph having non-nil adjustment (except the first grapheme
cluster of the gstring).  I think this is not correct especially for
right-to-left text, and I disabled that part in the Mac port.  Could
you give an example if you think this part is necessary?

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