From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Steffan Newsgroups: gmane.emacs.bugs Subject: bug#11860: 24.1; Arabic - Harakat (diacritics, short vowels) don't appear Date: Wed, 22 Aug 2012 23:40:55 +0200 Message-ID: <110631345671655@web11e.yandex.ru> References: <349071341393469@web30d.yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1345671707 3982 80.91.229.3 (22 Aug 2012 21:41:47 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 22 Aug 2012 21:41:47 +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 Wed Aug 22 23:41:47 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 1T4IgM-0004go-27 for geb-bug-gnu-emacs@m.gmane.org; Wed, 22 Aug 2012 23:41:46 +0200 Original-Received: from localhost ([::1]:35446 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T4IgK-0002yv-94 for geb-bug-gnu-emacs@m.gmane.org; Wed, 22 Aug 2012 17:41:44 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:44915) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T4IgG-0002qQ-J9 for bug-gnu-emacs@gnu.org; Wed, 22 Aug 2012 17:41:41 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1T4IgB-0005Hm-RR for bug-gnu-emacs@gnu.org; Wed, 22 Aug 2012 17:41:40 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:34314) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T4IgB-0005Hi-Na for bug-gnu-emacs@gnu.org; Wed, 22 Aug 2012 17:41:35 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1T4Igb-0002ib-UL for bug-gnu-emacs@gnu.org; Wed, 22 Aug 2012 17:42:01 -0400 X-Loop: help-debbugs@gnu.org In-Reply-To: <349071341393469@web30d.yandex.ru> Resent-From: Steffan Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 22 Aug 2012 21:42: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.134567169010411 (code B ref 11860); Wed, 22 Aug 2012 21:42:01 +0000 Original-Received: (at 11860) by debbugs.gnu.org; 22 Aug 2012 21:41:30 +0000 Original-Received: from localhost ([127.0.0.1]:43859 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1T4Ig5-0002hr-Pf for submit@debbugs.gnu.org; Wed, 22 Aug 2012 17:41:30 -0400 Original-Received: from forward7.mail.yandex.net ([77.88.61.37]:48538) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1T4Ig2-0002hi-6A for 11860@debbugs.gnu.org; Wed, 22 Aug 2012 17:41:28 -0400 Original-Received: from web11e.yandex.ru (web11e.yandex.ru [77.88.61.50]) by forward7.mail.yandex.net (Yandex) with ESMTP id B038F1C1B2A; Thu, 23 Aug 2012 01:40:57 +0400 (MSK) Original-Received: from 127.0.0.1 (localhost.localdomain [127.0.0.1]) by web11e.yandex.ru (Yandex) with ESMTP id 21A3E830072; Thu, 23 Aug 2012 01:40:57 +0400 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1345671657; bh=G/1UPaT+6lgN1g7KvcCfsF8l35miycTZ15UHt0aV5zg=; h=From:To:Cc:Subject:MIME-Version:Message-Id:Date: Content-Transfer-Encoding:Content-Type; b=phZKForSjqB9n7JCBMgd04Nd7/HJSzvl1G/BxlTJJ172hhGyY/NT7SW0gn9H3bKdT zuVk8C724tBNaAbHHSs81D7D6skPBeF5sbyKUMCMIlwFVr+TjnWotuyCiynQkRihV1 9/97Z7bOTaf/VED9wss1MZ+HT/wkv8caLucqyfe0= Original-Received: from [46.115.56.206] ([46.115.56.206]) by web11e.yandex.ru with HTTP; Thu, 23 Aug 2012 01:40:55 +0400 X-Mailer: Yamail [ http://yandex.ru ] 5.0 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:63408 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? -- Sorry, I miss this. I don't know where I can get this trunk code (r109726?). At http://alpha.gnu.org/gnu/emacs/windows/?C=M;O=A the latest version is this: emacs-20120813-r109584-bin-i386.zip.sig 13-Aug-2012 12:32 287 Thanks