From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Kenichi Handa Newsgroups: gmane.emacs.bugs Subject: bug#11860: 24.1; Arabic - Harakat (diacritics, short vowels) don't appear Date: Tue, 21 Aug 2012 22:16:51 +0900 Message-ID: <87wr0sgzb0.fsf@gnu.org> References: <349071341393469@web30d.yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1345555084 12762 80.91.229.3 (21 Aug 2012 13:18:04 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 21 Aug 2012 13:18:04 +0000 (UTC) Cc: 11860@debbugs.gnu.org, smias@yandex.ru To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Aug 21 15:18:04 2012 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1T3oLG-0003m6-Hm for geb-bug-gnu-emacs@m.gmane.org; Tue, 21 Aug 2012 15:17:58 +0200 Original-Received: from localhost ([::1]:43686 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T3oLF-0001Jt-1U for geb-bug-gnu-emacs@m.gmane.org; Tue, 21 Aug 2012 09:17:57 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:34676) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T3oL7-0001Jo-LA for bug-gnu-emacs@gnu.org; Tue, 21 Aug 2012 09:17:55 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1T3oL1-0007Hw-J8 for bug-gnu-emacs@gnu.org; Tue, 21 Aug 2012 09:17:49 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:59860) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T3oL1-0007Hs-FB for bug-gnu-emacs@gnu.org; Tue, 21 Aug 2012 09:17:43 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1T3oLK-0001Aj-AM for bug-gnu-emacs@gnu.org; Tue, 21 Aug 2012 09:18:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Kenichi Handa Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 21 Aug 2012 13:18:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 11860 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 11860-submit@debbugs.gnu.org id=B11860.13455550424458 (code B ref 11860); Tue, 21 Aug 2012 13:18:02 +0000 Original-Received: (at 11860) by debbugs.gnu.org; 21 Aug 2012 13:17:22 +0000 Original-Received: from localhost ([127.0.0.1]:41173 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1T3oKe-00019q-Gt for submit@debbugs.gnu.org; Tue, 21 Aug 2012 09:17:21 -0400 Original-Received: from fencepost.gnu.org ([208.118.235.10]:48797) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1T3oKb-00019h-Bu for 11860@debbugs.gnu.org; Tue, 21 Aug 2012 09:17:18 -0400 Original-Received: from 126.229.accsnet.ne.jp ([202.220.229.126]:65468 helo=ubuntu) by fencepost.gnu.org with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1T3oKG-0007So-NE; Tue, 21 Aug 2012 09:16:57 -0400 In-Reply-To: <83sjbid9n3.fsf@gnu.org> (message from Eli Zaretskii on Sun, 19 Aug 2012 21:22:40 +0300) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:63342 Archived-At: In article <83sjbid9n3.fsf@gnu.org>, Eli Zaretskii 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