bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#11860: 24.1; Arabic - Harakat (diacritics, short vowels) don't appea


From: Eli Zaretskii
Subject: 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@gnu.org>
> Cc: eliz@gnu.org,  11860@debbugs.gnu.org,  smias@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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]