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

[Kenichi Handa]

In article <wlvcgfuyjt.wl%mituharu@math.s.chiba-u.ac.jp>, YAMAMOTO Mitsuharu 
<mituharu@math.s.chiba-u.ac.jp> writes:

> 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.

Almost right.  We can't tell that the order in a grapheme
cluster is in physical or logical; it's just in "drawing"
order.

For instance, when we have an Arabic text "AbCdEf"
(consonants:uppercase, vowels:lowercase), the gstring that
should be returned by a shaper should be "XYZ" (where X is
actually a grapheme cluster for "Ab", Y for "Cd", Z for
"Ef").  Here how glyphs in each cluster should be ordered
depends on metrics of glyphs.  If a glyph for "A" has
positive xadvance, and a glyph for "b" has negative lbearing
(and zero xadvance), the order should be "Ab" because the
display engine should draw A and b in that order to make b
aligned on/under A.  But, if a glyph for "b" has
non-negative lbearing (and zero xadvance), the order should
be "bA".

> 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.

I don't have the codes of Mac port at hand now.  How did you
identify boundaries of grapheme clusters?  Do Core Text and
NSLayoutManager return that information?

Anyway, perhaps w32uniscribe.c should do the similar
reordering, or should be fixed to do that reordering
correctly.

---
Kenichi Handa
handa@gnu.org