bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Eli Zaretskii
Subject: bug#11860: 24.1; Arabic - Harakat (diacritics, short vowels) don't appear
Date: Wed, 12 Sep 2012 19:34:48 +0300

> From: Kenichi Handa <handa@gnu.org>
> Cc: mituharu@math.s.chiba-u.ac.jp, 11860@debbugs.gnu.org, smias@yandex.ru
> Date: Wed, 12 Sep 2012 22:14:50 +0900
> 
> In article <83k3w0wivf.fsf@gnu.org>, Eli Zaretskii <eliz@gnu.org> writes:
> 
> > AFAICS, all Ffont_shape_gstring does is modify the FROM and TO
> > components of the glyph-string.  For this to have any effect on the
> > screen, these components need to be used by the drawing routines.  But
> > the code in xterm.c and w32term.c that draws the composite characters
> > (x_draw_composite_glyph_string_foreground) doesn't seem to use these
> > components.  At least for w32term.c, we just draw the glyphs returned
> > by the shaper, one by one.
> 
> Each grapheme cluster is a "display element" in the sense of
> get_next_display_element.  get_next_display_element calls
> next_element_from_composition which calls
> composition_update_it which updates it->cmp_it.from and
> it->cmp_it.to from FROM and TO elements for LGLYPH.

Yes, but wasn't this discussion about the effects of
Ffont_shape_gstring on drawing the resulting glyphs?
get_next_display_element has no bearing on that.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]