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

[Kenichi Handa]

In article <83mx1qd85g.fsf@gnu.org>, Eli Zaretskii <eliz@gnu.org> writes:

> > Or maybe I am misremembering, and it was more about the difficulty in
> > figuring out which glyphs correspond to which characters in cases where
> > there is not a one to one correspondance

> This difficulty is indeed there.  How does libotf solve this problem?

If one GSUB feature converts the input gstring "AB" to "ab",
all what we can say is that the resulting glyph sequence
"ab" corresponds to "AB", and we can't say "a" corresponds
to "A" and "b" corresponds to "B".

So, m17nlib and libotf sets the same FROM and TO indices to
both "a" and "b" (in the above case, 0 and 1 respectively),
and thus they constitute a single grapheme cluster and Emacs
treat it as a single glyph on cursor movement.

But, when one GSUB feature converts "A" to "a" and another
convertes "B" to "b", "a" and "b" doesn't constitute a
grapheme cluster because they still have the different FROM
and TO indices.  Now, another GPOS features will be applied
to "b" to adjust its x/y offsets so that "b" will be placed
on "a".  In this case, it's up to an application to handle
them separately (the application should be able to put
cursor on "a" part and "b" part separately) or to handle
them as a single grapheme cluster.  Emacs does the latter by
forcing them to have the same FROM and TO indices (the code
mentioned by Yamamoto-san does it (in Ffont_shape_gstring
after calling font->driver->shape)).

---
Kenichi Handa
handa@gnu.org