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

Previous Next

Full log

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

From: Kenichi Handa <handa <at> gnu.org>
To: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
Cc: eliz <at> gnu.org, 11860 <at> debbugs.gnu.org, smias <at> yandex.ru, jasonr <at> gnu.org
Subject: Re: bug#11860: 24.1;
	Arabic - Harakat (diacritics, short vowels) don't appear
Date: Sun, 19 Aug 2012 21:51:44 +0900

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

> IIUC, the resulting gstring should be ordered as:

>   * in the logical order between the grapheme clusters because Emacs
>     itself reorders them.

>   * in the physical order between the glyphs inside a single grapheme
>     cluster because drawing and metric calculation routines for a
>     grapheme cluster do not know about the direction.

Almost right.  We can't tell that the order in a grapheme
cluster is in physical or logical; it's just in "drawing"
order.

For instance, when we have an Arabic text "AbCdEf"
(consonants:uppercase, vowels:lowercase), the gstring that
should be returned by a shaper should be "XYZ" (where X is
actually a grapheme cluster for "Ab", Y for "Cd", Z for
"Ef").  Here how glyphs in each cluster should be ordered
depends on metrics of glyphs.  If a glyph for "A" has
positive xadvance, and a glyph for "b" has negative lbearing
(and zero xadvance), the order should be "Ab" because the
display engine should draw A and b in that order to make b
aligned on/under A.  But, if a glyph for "b" has
non-negative lbearing (and zero xadvance), the order should
be "bA".

> The font backend driver on the Mac port is implemented as above, and
> seems to work correctly.  The APIs used for shaping generates glyphs
> either in the physical order (Core Text) or in the logical order
> (NSLayoutManager), so I had to reorder the information about the
> generated glyphs locally by maintaining a permutation on the glyph
> indices.  You can look at the variable `permutation' in the function
> `mac_ctfont_shape' (for Core Text, in src/macfont.c) or the function
> `mac_font_shape_1' (For NSLayoutManager, in src/macappkit.m) in the
> source of the Mac port.

I don't have the codes of Mac port at hand now.  How did you
identify boundaries of grapheme clusters?  Do Core Text and
NSLayoutManager return that information?

Anyway, perhaps w32uniscribe.c should do the similar
reordering, or should be fixed to do that reordering
correctly.

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