From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#11860: 24.1; Arabic - Harakat (diacritics, short vowels) don't appear Date: Tue, 21 Aug 2012 20:32:32 +0300 Message-ID: <83lih8b173.fsf@gnu.org> References: <87wr0sgzb0.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1345570370 20690 80.91.229.3 (21 Aug 2012 17:32:50 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 21 Aug 2012 17:32:50 +0000 (UTC) Cc: 11860@debbugs.gnu.org, smias@yandex.ru To: Kenichi Handa Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Aug 21 19:32:49 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 1T3sJr-00014Q-9B for geb-bug-gnu-emacs@m.gmane.org; Tue, 21 Aug 2012 19:32:47 +0200 Original-Received: from localhost ([::1]:54996 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T3sJp-0007Kq-Qi for geb-bug-gnu-emacs@m.gmane.org; Tue, 21 Aug 2012 13:32:45 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:58364) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T3sJn-0007K7-6x for bug-gnu-emacs@gnu.org; Tue, 21 Aug 2012 13:32:44 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1T3sJm-0002hn-5z for bug-gnu-emacs@gnu.org; Tue, 21 Aug 2012 13:32:43 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:60540) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T3sJm-0002hj-1u for bug-gnu-emacs@gnu.org; Tue, 21 Aug 2012 13:32:42 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1T3sK5-0007rZ-Qs for bug-gnu-emacs@gnu.org; Tue, 21 Aug 2012 13:33:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 21 Aug 2012 17:33:01 +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.134557037330207 (code B ref 11860); Tue, 21 Aug 2012 17:33:01 +0000 Original-Received: (at 11860) by debbugs.gnu.org; 21 Aug 2012 17:32:53 +0000 Original-Received: from localhost ([127.0.0.1]:41853 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1T3sJw-0007r9-Sf for submit@debbugs.gnu.org; Tue, 21 Aug 2012 13:32:53 -0400 Original-Received: from mtaout21.012.net.il ([80.179.55.169]:45442) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1T3sJu-0007qx-Ax for 11860@debbugs.gnu.org; Tue, 21 Aug 2012 13:32:51 -0400 Original-Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0M9400D008P7ED00@a-mtaout21.012.net.il> for 11860@debbugs.gnu.org; Tue, 21 Aug 2012 20:32:28 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0M9400D7T8Q37X90@a-mtaout21.012.net.il>; Tue, 21 Aug 2012 20:32:28 +0300 (IDT) In-reply-to: <87wr0sgzb0.fsf@gnu.org> X-012-Sender: halo1@inter.net.il 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:63345 Archived-At: > From: Kenichi Handa > Cc: jasonr@gnu.org, 11860@debbugs.gnu.org, smias@yandex.ru > Date: Tue, 21 Aug 2012 22:16:51 +0900 > > > (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. Well, it turns out that the truth is slightly different. When the Uniscribe shaper is handed a chunk of RTL text with the fLogicalOrder flag set to TRUE, it prepares the glyphs in the logical order, but assumes that they will be laid out in reverse. In this reverse order, the width advance value is applied _before_ drawing the glyph, and positive width advance values move the pen to the _left_. I found this important information on some Web page, which I unfortunately can no longer find. In addition, it looks like in this "reverse" mode, the X-OFFSET value is also interpreted in the reverse direction, so its sign must be flipped for glyphs in RTL grapheme clusters. Armed with this knowledge, with the information you posted, and after studying the drawing code in w32term.c, I made some semi-empirical changes in uniscribe_shape that produce good results both with Arabic and with Hebrew. In a nutshell, I adjusted the X-OFFSET values for the width of the base-character glyph. The results are committed as trunk revision 109726; as I only tested the modification on a small sample of composed texts, please see if you can run more tests with as complex compositions as you can find. > > 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. I see. This was somewhat counter-intuitive (why move first and then correct that by negative offsets, instead of not moving until all the glyphs in the cluster are drawn?). > > > 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? Yes. But I think swapping the glyphs in the cluster was not the right idea, because it violates the assumptions in w32font_draw, the drawing routine called by the font back-end. That routine expects the first glyph to be for the base character of the composition. > 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). Yes, that helped, thanks. Steffan, can you try the latest trunk code, and see if there are any problems left?