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 back end font selection process Date: Wed, 10 Jun 2009 20:04:33 +0900 Message-ID: References: <8BA022EF-AACD-495A-ABBB-24B230475217@gmail.com> NNTP-Posting-Host: lo.gmane.org X-Trace: ger.gmane.org 1244633134 15041 80.91.229.12 (10 Jun 2009 11:25:34 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 10 Jun 2009 11:25:34 +0000 (UTC) Cc: emacs-devel@gnu.org To: Adrian Robert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jun 10 13:25:30 2009 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.50) id 1MELvm-0001JH-5i for ged-emacs-devel@m.gmane.org; Wed, 10 Jun 2009 13:25:22 +0200 Original-Received: from localhost ([127.0.0.1]:56350 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MELvk-0006Px-Ib for ged-emacs-devel@m.gmane.org; Wed, 10 Jun 2009 07:25:20 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MELbx-0002qs-3G for emacs-devel@gnu.org; Wed, 10 Jun 2009 07:04:53 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MELbq-0002n6-AG for emacs-devel@gnu.org; Wed, 10 Jun 2009 07:04:50 -0400 Original-Received: from [199.232.76.173] (port=32893 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MELbq-0002ms-5Q for emacs-devel@gnu.org; Wed, 10 Jun 2009 07:04:46 -0400 Original-Received: from mx1.aist.go.jp ([150.29.246.133]:63355) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MELbp-00045l-9W for emacs-devel@gnu.org; Wed, 10 Jun 2009 07:04:45 -0400 Original-Received: from rqsmtp2.aist.go.jp (rqsmtp2.aist.go.jp [150.29.254.123]) by mx1.aist.go.jp with ESMTP id n5AB4aE6020710; Wed, 10 Jun 2009 20:04:36 +0900 (JST) env-from (handa@m17n.org) Original-Received: from smtp2.aist.go.jp by rqsmtp2.aist.go.jp with ESMTP id n5AB4ZCQ023002; Wed, 10 Jun 2009 20:04:35 +0900 (JST) env-from (handa@m17n.org) Original-Received: by smtp2.aist.go.jp with ESMTP id n5AB4XwS018362; Wed, 10 Jun 2009 20:04:33 +0900 (JST) env-from (handa@m17n.org) Original-Received: from handa by etlken with local (Exim 4.69) (envelope-from ) id 1MELbd-0001Fg-5T; Wed, 10 Jun 2009 20:04:33 +0900 In-reply-to: (message from Adrian Robert on Wed, 10 Jun 2009 14:27:34 +0700) X-detected-operating-system: by monty-python.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:111411 Archived-At: In article , Adrian Robert writes: > Currently I'm just responding to the 'thai' in :otf with a Thai font > and it seems to work reasonably. None of the otf functions are > implemented in the NS font driver and I'm unsure whether they can be, > but emacs' text layout must fall back to stacking automatically. If > it would be better to refuse the :otf list() request at this stage > then adding the :script 'thai entry would be good. The same goes for > other entries in the default fontset that use :otf in the same way. If NS backend doesn't support OTF, it is better that `list' method returns nil for that request. So, I'll add ,(font-spec :registry "iso10646-1" :script 'thai) for Thai. By the way, for lao, the default fontset already has this entry after the entry specifying :otf property. ,(font-spec :registry "iso10646-1" :script 'lao) But, for the other scripts that request OTF, it is impossible to implement a falling back method. Simple stacking doesn't work for them. >>> Also, often I have noticed that when given a Chinese text file >>> (encoded in UTF-8), the only request that comes through is :lang=ja. > > > > ?? For han script, the default fontset has this entry: > > > > (han (nil . "GB2312.1980-0") > > (nil . "JISX0208*") > > (nil . "JISX0212*") > > (nil . "big5*") > > ... > > ,(font-spec :registry "iso10646-1" :lang 'ja) > > ,(font-spec :registry "iso10646-1" :lang 'zh)) > Why not have > (font-spec :registry "iso10646-1" :script 'han) > before the lang entries? Just to reduce the number of font-specs to try. Here I assume that a font that supports han script supports ja and/or zh, and thus adding the entry of :script 'han is redundant. > > So, not only `ja', emacs should try `zh' if `ja' is not > > available. Doesn't it happen on Cocoa? >>> How should the font driver know to return a kanji font instead of >>> hiragana / katakana?. > > > > A font driver can return any 'ja' iso10646-1 fonts for this > > request (even if the font support only kana): > > > > ,(font-spec :registry "iso10646-1" :lang 'ja) > > > > If the first font in the returned list doesn't support a > > specific han character, Emacs tries another font in the > > returned list. > Ah, OK so for purposes of list() the driver should treat :lang='ja as > "kana | kanji" instead of "kana & kanji", and treat kanji itself as > "kanji | hanzi". Yes. --- Kenichi Handa handa@m17n.org