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

Previous Next

Full log

View this message in rfc822 format

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: bug#11860: 24.1; Arabic - Harakat (diacritics, short vowels) don't appear
Date: Thu, 13 Sep 2012 20:00:17 +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: Thu, 13 Sep 2012 15:07:14 +0900
> 
> In article <83fw6nw66v.fsf <at> gnu.org>, Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > 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.
> 
> When a font driver returns GSTRING "abcdef", how to segment
> it into clusters affect displaying especially in R2L text.
> If "abcdef" is segmented as "ab", "cd", "ef", it is
> displayed as "efcdab", but if it is segmented as "abc",
> "def", it is displaed as "defabc".  In addition cursor
> movement is also affected by how GSTRING is segmented.

OK, but in this case we are talking about diacriticals, which are
always drawn in the same character cell as the base character.  IOW,
the pen does not advance until the entire gstring is drawn.  In that
case, whatever Ffont_shape_gstring does will not affect the result on
the screen, would it?

Previous Next

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