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

Previous Next

Full log

Message #179 received at 11860 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Kenichi Handa <handa <at> gnu.org>
Cc: 11860 <at> debbugs.gnu.org, smias <at> yandex.ru, mituharu <at> math.s.chiba-u.ac.jp
Subject: Re: 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 <at> gnu.org>
> Cc: mituharu <at> math.s.chiba-u.ac.jp, 11860 <at> debbugs.gnu.org, smias <at> yandex.ru
> Date: Wed, 12 Sep 2012 22:14:50 +0900
> 
> In article <83k3w0wivf.fsf <at> gnu.org>, Eli Zaretskii <eliz <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.