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: Kenichi Handa <handa <at> gnu.org>
To: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
Cc: 11860 <at> debbugs.gnu.org, smias <at> yandex.ru
Subject: bug#11860: 24.1; Arabic - Harakat (diacritics, short vowels) don't appear
Date: Tue, 11 Sep 2012 23:49:40 +0900

In article <wlbohflu0z.wl%mituharu <at> math.s.chiba-u.ac.jp>, YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp> writes:

> As you explained, the grapheme clusters are in logical order, and
> glyphs in each grapheme cluster are in drawing order.  So simply
> merging grapheme clusters as in the code in Ffont_shape_gstring does
> not seem to be correct in the case of right-to-left text (what's drawn
> later comes earlier in a merged grapheme cluster).

Sure.

> IMO, dividing glyphs into grapheme clusters is font backed driver's
> task, and I don't understand why Ffont_shape_gstring merges the
> grapheme clusters for some cases.  Could you explain?

When I designed it, I consider such a situation that
grapheme clusters returned by a font-driver is so fine for
Emacs' display engine that Ffont_shape_gstring must combine
some of them into one grapheme cluster.  But, I agree that
it's much cleaner to make a font-driver to consider such a
thing.

I'll try to fix Ffont_shape_gstring, and check whether or
not it breaks rendersing of some scripts.

---
Kenichi Handa
handa <at> gnu.org

Previous Next

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