From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: YAMAMOTO Mitsuharu Newsgroups: gmane.emacs.bugs Subject: bug#11860: 24.1; Arabic - Harakat (diacritics, short vowels) don't appear Date: Sun, 09 Sep 2012 13:06:20 +0900 Organization: Faculty of Science, Chiba University Message-ID: References: <349071341393469@web30d.yandex.ru> <87393kgbp4.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Trace: ger.gmane.org 1347163603 6833 80.91.229.3 (9 Sep 2012 04:06:43 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 9 Sep 2012 04:06:43 +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 Sun Sep 09 06:06:44 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 1TAYnD-0004TB-CH for geb-bug-gnu-emacs@m.gmane.org; Sun, 09 Sep 2012 06:06:43 +0200 Original-Received: from localhost ([::1]:58700 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TAYn9-0006f2-P4 for geb-bug-gnu-emacs@m.gmane.org; Sun, 09 Sep 2012 00:06:39 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:52919) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TAYn7-0006ej-3q for bug-gnu-emacs@gnu.org; Sun, 09 Sep 2012 00:06:38 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TAYn5-00026P-VF for bug-gnu-emacs@gnu.org; Sun, 09 Sep 2012 00:06:37 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:39817) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TAYn5-00026L-RS for bug-gnu-emacs@gnu.org; Sun, 09 Sep 2012 00:06:35 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1TAYnW-0005tp-GS for bug-gnu-emacs@gnu.org; Sun, 09 Sep 2012 00:07:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: YAMAMOTO Mitsuharu Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 09 Sep 2012 04:07: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.134716361622665 (code B ref 11860); Sun, 09 Sep 2012 04:07:02 +0000 Original-Received: (at 11860) by debbugs.gnu.org; 9 Sep 2012 04:06:56 +0000 Original-Received: from localhost ([127.0.0.1]:49363 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TAYnQ-0005tV-4m for submit@debbugs.gnu.org; Sun, 09 Sep 2012 00:06:56 -0400 Original-Received: from mathmail.math.s.chiba-u.ac.jp ([133.82.132.2]:61780) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TAYnL-0005tI-B7 for 11860@debbugs.gnu.org; Sun, 09 Sep 2012 00:06:53 -0400 Original-Received: from church.math.s.chiba-u.ac.jp (church [133.82.132.36]) by mathmail.math.s.chiba-u.ac.jp (Postfix) with ESMTP id 79295C0562; Sun, 9 Sep 2012 13:06:20 +0900 (JST) In-Reply-To: User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?UTF-8?Q?Shij=C5=8D?=) APEL/10.6 Emacs/22.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) 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:63987 Archived-At: >>>>> On Sun, 19 Aug 2012 13:34:36 +0900, YAMAMOTO Mitsuharu said: >>>>> On Sat, 18 Aug 2012 11:45:27 +0900, Kenichi Handa said: >> If this problem happens only for bidi scripts, 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. 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] > The font backend driver on the Mac port is supposed to support > right-to-left shaping (including for non-BMP chars, though I don't > have a good example), and it gives the following result (diacritical > mark comes first) for Courier New 13pt: > mac-ct:-*-Courier New-normal-normal-normal-*-13-*-*-*-m-0-iso10646-1 > by these glyphs: > [0 1 1618 760 8 0 2 11 -8 [-1 2 1]] > [0 1 1593 969 8 0 6 5 4 [-1 0 8]] The above result was not correct in a couple of points. First, the font backend driver for the Mac port had a bug (*1). Second, OS X 10.7 and 10.8 seem to have a bug that they report incorrect lbearing and rbearing values for Courier New (*2). In particlar, the lbearing value is always reported as 0, as in the above result. *1: http://lists.gnu.org/archive/html/emacs-devel/2012-09/msg00157.html *2: http://openradar.appspot.com/10377021 Mac OS X 10.6 does not have the second issue, and with the patch in (*1), it reports the following result: mac-ct:-*-Courier New-normal-normal-normal-*-13-*-*-*-m-0-iso10646-1 by these glyphs: [0 1 1618 760 8 3 5 11 -8 [-1 2 0]] [0 1 1593 969 8 1 8 5 4 nil] > In the above example, the grapheme cluster consists of glyphs having > non-nil adjustments (the last element of each vector). In the > function Ffont_shape_gstring, there is some code that merges grapheme > clusters generated by a font backend driver so each of them starts > with a glyph having non-nil adjustment (except the first grapheme > cluster of the gstring). I think this is not correct especially for > right-to-left text, and I disabled that part in the Mac port. Could > you give an example if you think this part is necessary? The first glyph in the above result still has non-nil adjustments. Another example is the Arabic "u-S-u" case for Arial 30pt (*3). It consists of the following two grapheme clusters (from right to left): [0 1 1613 755 0 1 7 2 4 [0 0 -3]] [0 1 0 971 16 -1 15 15 -4 nil] [2 2 0 970 14 1 15 13 7 [0 0 16]] *3: http://lists.gnu.org/archive/html/bug-gnu-emacs/2012-09/msg00178.html As you explained, the grapheme clusters are in logical order, and glyphs in each grapheme cluster are in drawing order. So simply merging grapheme clusters as in the code in Ffont_shape_gstring does not seem to be correct in the case of right-to-left text (what's drawn later comes earlier in a merged grapheme cluster). IMO, dividing glyphs into grapheme clusters is font backed driver's task, and I don't understand why Ffont_shape_gstring merges the grapheme clusters for some cases. Could you explain? YAMAMOTO Mitsuharu mituharu@math.s.chiba-u.ac.jp