From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Kenichi Handa Newsgroups: gmane.emacs.devel Subject: Re: font selection mechanism (e.g., Japanese) Date: Tue, 02 Feb 2010 20:51:20 +0900 Message-ID: References: <9775B394-9A01-4730-A4AE-98949DCA54DF@gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1265112893 30728 80.91.229.12 (2 Feb 2010 12:14:53 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 2 Feb 2010 12:14:53 +0000 (UTC) Cc: adrian.b.robert@gmail.com, emacs-devel@gnu.org To: David Reitter Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Feb 02 13:14:49 2010 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1NcHea-00088s-2J for ged-emacs-devel@m.gmane.org; Tue, 02 Feb 2010 13:14:48 +0100 Original-Received: from localhost ([127.0.0.1]:32919 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NcHeY-0002Lq-Sv for ged-emacs-devel@m.gmane.org; Tue, 02 Feb 2010 07:14:46 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NcHI5-0000Gv-7s for emacs-devel@gnu.org; Tue, 02 Feb 2010 06:51:33 -0500 Original-Received: from [140.186.70.92] (port=33024 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NcHI2-0000G0-SS for emacs-devel@gnu.org; Tue, 02 Feb 2010 06:51:32 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1NcHI0-0004yk-Lx for emacs-devel@gnu.org; Tue, 02 Feb 2010 06:51:30 -0500 Original-Received: from mx1.aist.go.jp ([150.29.246.133]:60199) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NcHHz-0004yS-TM for emacs-devel@gnu.org; Tue, 02 Feb 2010 06:51:28 -0500 Original-Received: from rqsmtp2.aist.go.jp (rqsmtp2.aist.go.jp [150.29.254.123]) by mx1.aist.go.jp with ESMTP id o12BpK3b028068; Tue, 2 Feb 2010 20:51:20 +0900 (JST) env-from (handa@m17n.org) Original-Received: from smtp2.aist.go.jp by rqsmtp2.aist.go.jp with ESMTP id o12BpKO4021237; Tue, 2 Feb 2010 20:51:20 +0900 (JST) env-from (handa@m17n.org) Original-Received: by smtp2.aist.go.jp with ESMTP id o12BpKne004555; Tue, 2 Feb 2010 20:51:20 +0900 (JST) env-from (handa@m17n.org) Original-Received: from handa by etlken with local (Exim 4.69) (envelope-from ) id 1NcHHs-0001uz-5Y; Tue, 02 Feb 2010 20:51:20 +0900 In-Reply-To: <9775B394-9A01-4730-A4AE-98949DCA54DF@gmail.com> (message from David Reitter on Fri, 29 Jan 2010 10:14:07 -0500) X-detected-operating-system: by eggs.gnu.org: Solaris 9 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:120818 Archived-At: In article <9775B394-9A01-4730-A4AE-98949DCA54DF@gmail.com>, David Reitter writes: > I'm trying to understand the font selection system in order to fix > problems, e.g., with the display of `han' characters in Japanese. I'd > appreciate your help if you're knowledgeable with font.c. I know about font.c, but know nothing about NS port. > A good example for font selection problems in Emacs 23 is Japanese, > which mixes characters from different scripts. For example, we have > latin characters, chinese (kanji, script: 'han'), and other scripts > (hiragana, katakana). > I have four issues. > 1. Selecting a better `han' font. > Finding a font to display 'han' characters is difficult for the > current algorithm. What is needed is a font that is similar to the > context font (the font chosen by the user for the face). In Emacs 23 > (at least on the NS port with my set of fonts), han characters look > very different in weight when combined with fonts common on my system, > e.g. Monaco or Lucida Grande. > See a user's complaint: http://lists.aquamacs.org/pipermail/aquamacs-devel/2009-August/002271.html > The reason for this is that font selection prefers high coverage of > the chosen font for the script; it finds some fonts on my system that > have high (90%) coverage and then chooses among them, even though > other fonts would have sufficient coverage and look much better. > `Han' is obviously a pretty big set of characters, so only few fonts > cover that many characters. At the same time, only a small portion of > these is commonly used (in Japanese at least), from what I understand. > Reducing the threshold for script coverage, eg. in ns_findfonts for > the NS port, addresses that - the `list' function of the font driver > will return a much bigger set of fonts so that font_select_entity() > can do its job. Hmmm, then NS's font-backend should be improved. Could someone working on NS port please port take a look at this problem. > The problem I have now is to get it to choose different fonts within > the same script in cases where a low-coverage font does not provide a > glyph. The above threshold change makes things work better in > practice, but the HELLO file shows serious regressions. Regression in which part? Only for Han scripts, or for all scripts? > Where in the code would one get it to choose a different font for a > character if the current font can't display it? This is by-character > selection, not by-script. The function fontset_find_font in fontset.c does that job. > 2. face-font-family-alternatives : broken? > face-font-family-alternatives does not work at all for me. In > font_find_for_lface(), "val" seems to empty; printing SDATA > (attrs[LFACE_FAMILY_INDEX]) shows something better, like > "Lucida_Grande". But that's not what the alist is queried for. Do you mean this code in font_find_for_lface? if (NILP (val) && STRINGP (attrs[LFACE_FAMILY_INDEX])) { val = attrs[LFACE_FAMILY_INDEX]; val = font_intern_prop ((char *) SDATA (val), SBYTES (val), 1); } If val is not correctly set, perhaps you compiled Emacs with some optimization. Please try to recompile Emacs as something like below: % make CFLAGS=-g clean all > 3. font driver specific matching > As an observation: The matching provided by the font driver (as a > backup to listing the entities) is not usually called, at least in the > NS port. This is because font_find_for_lface() usually seems to widen > the search so much (pretty much looking for all fonts) that the > matching algorithm never gets chance. In font selection, specs in fontset are mandatory but specs from face attributes are just preference. So, font_find_for_lface widens the restriction by setting only preferred specs to nil one by one. By the way, I locally have a code that respect the order of fonts returned by font_driver->list () in font sorting. I'm going to commit it for post 23.2 branch. Then, each driver can return fonts in their preferred order. > 4. Searching for fonts by foundry. > Below patch makes the selection algorithm a little more sensible > (fonts of the same foundry rarely have much in common graphically). > But it doesn't address the problem. Thank you for the patch. It seems good. I'll adopt it for post 23.2 branch. > commit d858f9ea2f60b37aa6f44b3d824cbaf0f1f867ae > Author: David Reitter > Date: Fri Jan 29 00:31:17 2010 -0500 > font_find_for_lface: do not try to find face by Foundry (Author) > name only > This is not sensible. > diff --git a/src/font.c b/src/font.c > index 557f1fb..b578c04 100644 > --- a/src/font.c > +++ b/src/font.c > @@ -3451,6 +3451,10 @@ font_find_for_lface (f, attrs, spec, c) > ASET (work, FONT_FAMILY_INDEX, family[i]); > for (j = 0; SYMBOLP (foundry[j]); j++) > { > + if (NILP (family[i]) && ! NILP (foundry[j])) > + /* do not look for "some foundry, any family". > + That doesn't tend to yield similar fonts. */ > + continue; > ASET (work, FONT_FOUNDRY_INDEX, foundry[j]); > for (k = 0; SYMBOLP (registry[k]); k++) > { --- Kenichi Handa handa@m17n.org