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 18:20:28 +0900 Message-ID: <87zk5oha8z.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 1345540861 23089 80.91.229.3 (21 Aug 2012 09:21:01 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 21 Aug 2012 09:21:01 +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 11:20:59 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 1T3kds-0001BZ-1S for geb-bug-gnu-emacs@m.gmane.org; Tue, 21 Aug 2012 11:20:56 +0200 Original-Received: from localhost ([::1]:35994 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T3kdq-0002l8-FB for geb-bug-gnu-emacs@m.gmane.org; Tue, 21 Aug 2012 05:20:54 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:52006) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T3kdn-0002e1-An for bug-gnu-emacs@gnu.org; Tue, 21 Aug 2012 05:20:52 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1T3kdh-0007l1-8B for bug-gnu-emacs@gnu.org; Tue, 21 Aug 2012 05:20:51 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:59697) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T3kdg-0007kt-UC for bug-gnu-emacs@gnu.org; Tue, 21 Aug 2012 05:20:45 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1T3kdy-0003Ra-LL for bug-gnu-emacs@gnu.org; Tue, 21 Aug 2012 05:21: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 09:21: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.134554085713226 (code B ref 11860); Tue, 21 Aug 2012 09:21:02 +0000 Original-Received: (at 11860) by debbugs.gnu.org; 21 Aug 2012 09:20:57 +0000 Original-Received: from localhost ([127.0.0.1]:41010 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1T3kdt-0003RG-5S for submit@debbugs.gnu.org; Tue, 21 Aug 2012 05:20:57 -0400 Original-Received: from fencepost.gnu.org ([208.118.235.10]:43050) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1T3kdq-0003R9-NP for 11860@debbugs.gnu.org; Tue, 21 Aug 2012 05:20:56 -0400 Original-Received: from 126.229.accsnet.ne.jp ([202.220.229.126]:64795 helo=ubuntu) by fencepost.gnu.org with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1T3kdW-0008Bv-Kt; Tue, 21 Aug 2012 05:20:35 -0400 In-Reply-To: <83393hcwl0.fsf@gnu.org> (message from Eli Zaretskii on Mon, 20 Aug 2012 20:16:59 +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:63340 Archived-At: In article <83393hcwl0.fsf@gnu.org>, Eli Zaretskii writes: > Thanks. But I wasn't asking about LGLYPH_SET_FROM and LGLYPH_SET_TO, > I was asking about LGLYPH_SET_CHAR. In the Windows implementation, we > assign the same codepoint there to all the glyphs in the grapheme > cluster, while on GNU/Linux you showed output that suggested we put > different character codepoints there. CHAR slot of a GLYPH has no meaning after shaping except for as debugging information. So, font->driver->shape doesn't have to worry about it that much. > Thanks. I've spent the best part of the last day reading about font > metrics, trying to understand the meaning of every component of the > gstring object. I still don't get all of it, though. Specifically, > it is still largely unclear what do we use each component for in > drawing each glyph that belongs to a grapheme cluster. One problem is > that terms like rbearing, lbearing, etc. are not always used in the > same sense as their definitions in digital typography references. > Could you please point to the documentation where the meaning of > gstring components is spelled out, or to code from which I could try > gleaning this information? The meaning of elements (i.e. GLYPHs) in GSTRING is described in the docstring of composition-get-gstring as this; GLYPH is a vector whose elements have this form: [ FROM-IDX TO-IDX C CODE WIDTH LBEARING RBEARING ASCENT DESCENT [ [X-OFF Y-OFF WADJUST] | nil] ] where FROM-IDX and TO-IDX are used internally and should not be touched. C is the character of the glyph. CODE is the glyph-code of C in FONT-OBJECT. WIDTH thru DESCENT are the metrics (in pixels) of the glyph. X-OFF and Y-OFF are offsets to the base position for the glyph. WADJUST is the adjustment to the normal width of the glyph. and the meanings of WIDTH, LBEARING, RBEARING, ASCENT, DESCENT are the same as X's XCharStruct which Emacs has been used for long (man of XLoadFont shows this info). typedef struct { short lbearing; /* origin to left edge of raster */ short rbearing; /* origin to right edge of raster */ short width; /* advance to next char's origin */ short ascent; /* baseline to top edge of raster */ short descent; /* baseline to bottom edge of raster */ unsigned short attributes; /* per char flags (not predefined) */ } XCharStruct; > I see w32_compute_glyph_string_overhangs > and x_draw_composite_glyph_string_foreground in w32term.c -- are these > the places to look, or is there more? What about lisp/composite.el -- > is that still relevant for automatic compositions? In the phase of ri->produce_glyphs, the function autocmp_chars (in composite.c) is the start function of shaping. It calls auto-compose-chars (in composite.el) and that leads to a call of font->driver->shape via (compose-gstring-for-graphic and Ffont_shape_gstring). This builds up GSTRING. Another work of this phase is to set (struct glyph)->slice.cmp.from and ...cmp.to so that the actual drawing routine knows which cluster of GSTRING each (struct glyph) object corresponds to. For that, composition_update_it (in composite.c) sets and updates indices of GSTRING to (struct composition_it)->from and to according to the value of (stuct composition_it)->reversed.p, and append_composite_glyph (in xdisp.c) sets those values to (struct glyph)->slice.cmp.from and ...cmp.to. Now all the information is readly of the drawing routine. In the phase of ri->write_glyphs, the function draw_glyphs calls BUILD_COMPOSITE_GLYPH_STRING (via the macro BUILD_GSTRING_GLYPH), and it sets (struct glyph_string)->cmp, (struct glyph_string)->cmp_from, (struct glyph_string)->cmp_to. Next draw_glyphs calls ri->draw_glyph_string which at last calls x_draw_composite_glyph_string_foreground which calls font->driver->draw. --- Kenichi Handa handa@gnu.org