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
Subject: bug#11860: 24.1; Arabic - Harakat (diacritics, short vowels) don't appear
Date: Sat, 18 Aug 2012 10:14:11 +0300

> From: Kenichi Handa <handa <at> gnu.org>
> Cc: eliz <at> gnu.org, 11860 <at> debbugs.gnu.org, smias <at> yandex.ru
> Date: Sat, 18 Aug 2012 11:45:27 +0900
> 
> So, apparently Emacs on Windows and GNU/Linux uses the
> different metrics of glyphs.  As the shaper on GNU/Linux
> (m17n-lib library) works correctly for the same font, and
> the other applications on Windows have no problem, I suspect
> that the problem is in Emacs' interface with uniscribe
> (w32font.c or w32uniscribe.c).
> 
> If this problem happens only for bidi scripts, one
> possibility is that Emacs's rendering engine (xdisp.c)
> expects glyphs in a glyph-string are rendered in that order
> from left to right, but the returned glyph-string on Windows
> should be rendered in reverse order.

If this is the case, how come we display the diacriticals correctly on
Windows in other cases, e.g. with Hebrew?

> For instance, in the above case, we may have to render glyphs in
> this order (diacritical mark first):
> 
>   [0 1 1593 760 0 3 6 12 4 [1 -2 0]]
>   [0 1 1593 969 8 1 8 12 4 nil]

Could you propose a patch to try this isea?

> I think the further debugging must be done by those who
> knows uniscribe, w32font.c, and w32uniscribe.c.

Alas, I don't think we have such people on board, not with high enough
availability, anyway.  If you could kindly suggest where to look, what
variables to display, etc., I could try doing that, and reporting the
results.

Thanks.

Previous Next

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