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

[Eli Zaretskii]

> From: Kenichi Handa <handa@gnu.org>
> Cc: jasonr@gnu.org, 11860@debbugs.gnu.org, smias@yandex.ru
> Date: Mon, 20 Aug 2012 23:57:53 +0900
> 
> 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.

Thanks.  But I wasn't asking about LGLYPH_SET_FROM and LGLYPH_SET_TO,
I was asking about LGLYPH_SET_CHAR.  In the Windows implementation, we
assign the same codepoint there to all the glyphs in the grapheme
cluster, while on GNU/Linux you showed output that suggested we put
different character codepoints there.

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

Thanks.  I've spent the best part of the last day reading about font
metrics, trying to understand the meaning of every component of the
gstring object.  I still don't get all of it, though.  Specifically,
it is still largely unclear what do we use each component for in
drawing each glyph that belongs to a grapheme cluster.  One problem is
that terms like rbearing, lbearing, etc. are not always used in the
same sense as their definitions in digital typography references.

Could you please point to the documentation where the meaning of
gstring components is spelled out, or to code from which I could try
gleaning this information?  I see w32_compute_glyph_string_overhangs
and x_draw_composite_glyph_string_foreground in w32term.c -- are these
the places to look, or is there more?  What about lisp/composite.el --
is that still relevant for automatic compositions?

Thanks.