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: Mon, 20 Aug 2012 23:57:53 +0900 Message-ID: <87393hipam.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 1345474737 13152 80.91.229.3 (20 Aug 2012 14:58:57 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 20 Aug 2012 14:58:57 +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 Mon Aug 20 16:58:56 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 1T3TRO-0000uL-Ng for geb-bug-gnu-emacs@m.gmane.org; Mon, 20 Aug 2012 16:58:54 +0200 Original-Received: from localhost ([::1]:34237 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T3TRN-0001dC-E2 for geb-bug-gnu-emacs@m.gmane.org; Mon, 20 Aug 2012 10:58:53 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:39407) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T3TRK-0001d6-CF for bug-gnu-emacs@gnu.org; Mon, 20 Aug 2012 10:58:51 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1T3TRJ-00065F-40 for bug-gnu-emacs@gnu.org; Mon, 20 Aug 2012 10:58:50 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:58871) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T3TRJ-00065B-0L for bug-gnu-emacs@gnu.org; Mon, 20 Aug 2012 10:58:49 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1T3TRW-0003H5-C6 for bug-gnu-emacs@gnu.org; Mon, 20 Aug 2012 10:59: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: Mon, 20 Aug 2012 14:59: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.134547470012539 (code B ref 11860); Mon, 20 Aug 2012 14:59:02 +0000 Original-Received: (at 11860) by debbugs.gnu.org; 20 Aug 2012 14:58:20 +0000 Original-Received: from localhost ([127.0.0.1]:40184 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1T3TQp-0003GB-91 for submit@debbugs.gnu.org; Mon, 20 Aug 2012 10:58:20 -0400 Original-Received: from fencepost.gnu.org ([208.118.235.10]:42808) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1T3TQl-0003G2-Js for 11860@debbugs.gnu.org; Mon, 20 Aug 2012 10:58:16 -0400 Original-Received: from 126.229.accsnet.ne.jp ([202.220.229.126]:60542 helo=ubuntu) by fencepost.gnu.org with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1T3TQV-0008WU-Th; Mon, 20 Aug 2012 10:58:00 -0400 In-Reply-To: <83mx1qd85g.fsf@gnu.org> (message from Eli Zaretskii on Sun, 19 Aug 2012 21:54:51 +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:63322 Archived-At: In article <83mx1qd85g.fsf@gnu.org>, Eli Zaretskii writes: > > 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 > This difficulty is indeed there. How does libotf solve this problem? If one GSUB feature converts the input gstring "AB" to "ab", all what we can say is that the resulting glyph sequence "ab" corresponds to "AB", and we can't say "a" corresponds to "A" and "b" corresponds to "B". So, m17nlib and libotf sets the same FROM and TO indices to both "a" and "b" (in the above case, 0 and 1 respectively), and thus they constitute a single grapheme cluster and Emacs treat it as a single glyph on cursor movement. But, when one GSUB feature converts "A" to "a" and another convertes "B" to "b", "a" and "b" doesn't constitute a grapheme cluster because they still have the different FROM and TO indices. Now, another GPOS features will be applied to "b" to adjust its x/y offsets so that "b" will be placed on "a". In this case, it's up to an application to handle them separately (the application should be able to put cursor on "a" part and "b" part separately) or to handle them as a single grapheme cluster. Emacs does the latter by forcing them to have the same FROM and TO indices (the code mentioned by Yamamoto-san does it (in Ffont_shape_gstring after calling font->driver->shape)). --- Kenichi Handa handa@gnu.org