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

[Kenichi Handa <handa@gnu.org>]

In article <83393hcwl0.fsf@gnu.org>, Eli Zaretskii <eliz@gnu.org> writes:

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

CHAR slot of a GLYPH has no meaning after shaping except for
as debugging information.  So, font->driver->shape doesn't
have to worry about it that much.

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

The meaning of elements (i.e. GLYPHs) in GSTRING is
described in the docstring of composition-get-gstring as this;

GLYPH is a vector whose elements have this form:
    [ FROM-IDX TO-IDX C CODE WIDTH LBEARING RBEARING ASCENT DESCENT
      [ [X-OFF Y-OFF WADJUST] | nil] ]
where
    FROM-IDX and TO-IDX are used internally and should not be touched.
    C is the character of the glyph.
    CODE is the glyph-code of C in FONT-OBJECT.
    WIDTH thru DESCENT are the metrics (in pixels) of the glyph.
    X-OFF and Y-OFF are offsets to the base position for the glyph.
    WADJUST is the adjustment to the normal width of the glyph.

and the meanings of WIDTH, LBEARING, RBEARING, ASCENT,
DESCENT are the same as X's XCharStruct which Emacs has been
used for long (man of XLoadFont shows this info).

typedef struct {
	short lbearing;			/* origin to left edge of raster */
	short rbearing;			/* origin to right edge of raster */
	short width;			/* advance to next char's origin */
	short ascent;			/* baseline to top edge of raster */
	short descent;			/* baseline to bottom edge of raster */
	unsigned short attributes;	/* per char flags (not predefined) */
} XCharStruct;

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

In the phase of ri->produce_glyphs, the function
autocmp_chars (in composite.c) is the start function of
shaping.  It calls auto-compose-chars (in composite.el) and
that leads to a call of font->driver->shape via
(compose-gstring-for-graphic and Ffont_shape_gstring).  This
builds up GSTRING.

Another work of this phase is to set (struct
glyph)->slice.cmp.from and ...cmp.to so that the actual
drawing routine knows which cluster of GSTRING each (struct
glyph) object corresponds to.  For that,
composition_update_it (in composite.c) sets and updates
indices of GSTRING to (struct composition_it)->from and to
according to the value of (stuct
composition_it)->reversed.p, and append_composite_glyph (in
xdisp.c) sets those values to (struct glyph)->slice.cmp.from
and ...cmp.to.

Now all the information is readly of the drawing routine.

In the phase of ri->write_glyphs, the function draw_glyphs
calls BUILD_COMPOSITE_GLYPH_STRING (via the macro
BUILD_GSTRING_GLYPH), and it sets (struct
glyph_string)->cmp, (struct glyph_string)->cmp_from, (struct
glyph_string)->cmp_to.  Next draw_glyphs calls
ri->draw_glyph_string which at last calls
x_draw_composite_glyph_string_foreground which calls
font->driver->draw.

---
Kenichi Handa
handa@gnu.org