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

Previous Next

Full log

Message #68 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, jasonr <at> gnu.org
Subject: Re: bug#11860: 24.1;
	Arabic - Harakat (diacritics, short vowels) don't appear
Date: Sun, 19 Aug 2012 21:52:38 +0300

> From: Kenichi Handa <handa <at> gnu.org>
> Cc: eliz <at> gnu.org,  11860 <at> debbugs.gnu.org,  smias <at> yandex.ru
> Date: Sun, 19 Aug 2012 22:37:29 +0900
> 
> > > The comment refer to "clusters".  I don't know what it
> > > exactly means in uniscribe, but I guess it relates to
> > > grapheme cluster, and if so, this part seems to relates to
> > > the ordering of glyphs in this kind of grapheme clauster:
> > >
> > >   [0 1 1593 969 8 1 8 12 4 nil]
> > >   [0 1 1593 760 0 3 6 12 4 [1 -2 0]]
> 
> > That seems to be correct.
> 
> Why?  As the xadvance of the first glyph is 8, and
> the xoffset of the second glyph is 1, the second glyph is
> never drawn at the same column as the first glyph.

I agree with your analysis, but then it is unclear to me why the other
components of the vector are different between GNU/Linux and Windows 7.
Can you explain them?

For instance, this (Windows):

  [0 1 1593 969 8 1 8 12 4 nil]

vs this (GNU/Linux):

  [0 1 1593 969 8 2 8 4 4 nil]

raises the following questions:

 . why are the values of LBEARING different (1 vs 2)?
 . why are the values of ASCENT different (12 vs 4)?  The Windows code
   takes ASCENT and DESCENT values from the font -- is that correct?

The fonts are identical, so I'd expect identical values here, at least
for the base character.  It is hard to debug more complex portions of
the code when such basic values already differ.

Previous Next

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