[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: |
Kenichi Handa |
Subject: |
bug#11860: 24.1; Arabic - Harakat (diacritics, short vowels) don't appear |
Date: |
Tue, 21 Aug 2012 22:16:51 +0900 |
In article <83sjbid9n3.fsf@gnu.org>, Eli Zaretskii <eliz@gnu.org> writes:
> > 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.
> You may be right, but it's hard to be sure. At least the advances[]
> array returned by ScriptPlace seems to point into that direction.
> Here's what I see in the debugger:
> Breakpoint 8, uniscribe_shape (lgstring=55041941) at w32uniscribe.c:373
> 373 LGLYPH_SET_CHAR (lglyph, chars[items[i].iCharPos
[...]
> (gdb) p advances[0]@nglyphs
> $5 = {8, 0}
> (gdb) p offsets[0]@nglyphs
> $6 = {{
> du = 0,
> dv = 0
> }, {
> du = 1,
> dv = -2
> }}
> (gdb) p chars[0]@2
> $7 = L"\x639\x652"
> (Note that the fRTL member of items[0].a is set to TRUE.) My
> understanding of the advances[] array is that it gives, for each glyph
> in the cluster, the number of pixels to advance to the right after
> drawing the glyph. So the fact that it is 8 for the first (base)
> character and zero for the second one tells me that this grapheme
> cluster is supposed to be rendered in reverse order: first the Sukun,
> then Ayin at the same location, and then advance by 8 pixels for the
> next character. Is this correct?
I think so.
> If it is correct, then how come the glyphs shown on GNU/Linux also
> have non-zero value of xadvance:
> [0 1 1593 969 8 2 8 4 4 nil]
> [0 1 1618 760 0 -6 -3 8 -11 [-9 2 0]]
Emacs draws the first glyph at its base point and advance
the base point 8 pixels to the right (because the WIDTH of
the first glyph is 8). Then Emacs draw the second glyph at
9 pixels left and 2 pixels up from the base point. So, the
second glyph is drawn above the first glyph.
> > 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]
> I tried the naive patch below, but it didn't quite work. It seems
> like those changes somehow prevented character composition. Perhaps
> Handa-san could give me some guidance here.
Did your patch produced the above GSTRING?
> > I think the further debugging must be done by those who
> > knows uniscribe, w32font.c, and w32uniscribe.c.
> It's very hard, given that glyph-string documentation leaves a lot to
> be desired, and the way its various components are used during drawing
> is also left without clear documentation. E.g., this:
> FROM-IDX and TO-IDX are used internally and should not be touched.
> is not really helpful for explaining what are FROM-IDX and TO-IDX, so
> how can I figure out whether the code you asked about is doing TRT?
The are indices to the original character sequence of that
GSTRING. If a glyph has N and M values for them, that glyph
corresponds to the Nth to Mth (inclusive) characters.
> And without knowing what is each component of glyph-string used for
> during drawing, how can I compare the values produced by Uniscribe
> APIs with what glyph-string needs? If someone could explain all those
> things, it would make debugging possible. Otherwise, I'm just
> randomly poking around...
Please see the function
x_draw_composite_glyph_string_foreground (in xterm.c and
w32term.c). It shows which component of GSTRING is used for
drawing (the last branch of "iff" condition).
---
Kenichi Handa
handa@gnu.org
- bug#11860: 24.1; Arabic - Harakat (diacritics, short vowels) don't appear, (continued)
- bug#11860: 24.1; Arabic - Harakat (diacritics, short vowels) don't appear, Kenichi Handa, 2012/08/19
- bug#11860: 24.1; Arabic - Harakat (diacritics, short vowels) don't appear, Jason Rumney, 2012/08/19
- bug#11860: 24.1; Arabic - Harakat (diacritics, short vowels) don't appear, Eli Zaretskii, 2012/08/19
- bug#11860: 24.1; Arabic - Harakat (diacritics, short vowels) don't appear, Kenichi Handa, 2012/08/20
- bug#11860: 24.1; Arabic - Harakat (diacritics, short vowels) don't appear, Eli Zaretskii, 2012/08/20
- bug#11860: 24.1; Arabic - Harakat (diacritics, short vowels) don't appear, Kenichi Handa, 2012/08/21
- bug#11860: 24.1; Arabic - Harakat (diacritics, short vowels) don't appear, Eli Zaretskii, 2012/08/19
- bug#11860: 24.1; Arabic - Harakat (diacritics, short vowels) don't appear, Eli Zaretskii, 2012/08/19
- bug#11860: 24.1; Arabic - Harakat (diacritics, short vowels) don't appear, YAMAMOTO Mitsuharu, 2012/08/19
- bug#11860: 24.1; Arabic - Harakat (diacritics, short vowels) don't appear, Eli Zaretskii, 2012/08/19
- bug#11860: 24.1; Arabic - Harakat (diacritics, short vowels) don't appear,
Kenichi Handa <=
- bug#11860: 24.1; Arabic - Harakat (diacritics, short vowels) don't appear, Eli Zaretskii, 2012/08/21
- bug#11860: 24.1; Arabic - Harakat (diacritics, short vowels) don't appear, Kenichi Handa, 2012/08/22
bug#11860: 24.1; Arabic - Harakat (diacritics, short vowels) don't appear, Steffan, 2012/08/22
bug#11860: 24.1; Arabic - Harakat (diacritics, short vowels) don't appear, Steffan, 2012/08/22
bug#11860: 24.1; Arabic - Harakat (diacritics, short vowels) don't appear, Steffan, 2012/08/27
bug#11860: 24.1; Arabic - Harakat (diacritics, short vowels) don't appear, Steffan, 2012/08/29