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

Previous Next

Full log

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

From: Jason Rumney <jasonr <at> gnu.org>
To: Kenichi Handa <handa <at> gnu.org>
Cc: eliz <at> gnu.org, 11860 <at> debbugs.gnu.org, smias <at> yandex.ru
Subject: Re: bug#11860: 24.1;
	Arabic - Harakat (diacritics, short vowels) don't appear
Date: Mon, 20 Aug 2012 00:16:19 +0800

Kenichi Handa <handa <at> gnu.org> writes:

> In article <87393j7fdv.fsf <at> gnu.org>, Jason Rumney <jasonr <at> gnu.org> writes:
>
>>>> > So, apparently Emacs on Windows and GNU/Linux uses the
>>>> > different metrics of glyphs.
>
>> Right, but adding the offsets to the corresponding metrics, we get the
>> same result with both the Windows and GNU/Linux cases,
>
> ?? I don't understand what you mean.

I mean comparing the two cases below:

Composed with the following character(s) "ْ" using this font:
  uniscribe:-outline-Courier New-normal-normal-normal-mono-13-*-*-*-c-*-iso10646-1
by these glyphs:
  [0 1 1593 969 8 1 8 12 4 nil]
  [0 1 1593 760 0 3 6 12 4 [1 -2 0]]

Composed with the following character(s) "ْ" using this font:
  xft:-monotype-Courier New-normal-normal-normal-*-13-*-*-*-m-0-iso10646-1
by these glyphs:
  [0 1 1593 969 8 2 8 4 4 nil]
  [0 1 1618 760 0 -6 -3 8 -11 [-9 2 0]]

WIDTH = same in both cases.
(LBEARING - X-OFF) = off by 1 in both cases
(RBEARING - X-OFF) = off by 1 in second case

The off-by one is probably a different rounding convention used within
the respective font drawing engines.

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

I wasn't referring to the values in the vector, but your analysis, as
you said "I don't know ... but I guess ...".

>> Maybe this is the code that is changing the
>> character code to 1593.  I seem to recall that something like this was
>> required for Indic languages to let Emacs know which characters had been
>> linked back into one glyph.
>
> Is that Windows specific?

I don't think so. At the time, it wasn't entirely clear to me what the
requirements were for font backends, and I tried various things while
trying to figure out what the general font handling code was
expecting from the font_script function. I eventually determined that
Emacs was treating a run of glyphs that came back from font_shape with
the same character code as a single glyph for cursor movement purposes,
which prevented display problems when moving the cursor through text.
The implementation may have changed since then to make this unneccesary.

Or maybe I am misremembering, and it was more about the difficulty in
figuring out which glyphs correspond to which characters in cases where
there is not a one to one correspondance, and I didn't attempt to
resolve this difficulty because the current code seems to be working.

Previous Next

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