From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Adrian Robert Newsgroups: gmane.emacs.devel Subject: Re: Font back end font selection process Date: Wed, 10 Jun 2009 14:27:34 +0700 Message-ID: References: <8BA022EF-AACD-495A-ABBB-24B230475217@gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1244619191 6786 80.91.229.12 (10 Jun 2009 07:33:11 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 10 Jun 2009 07:33:11 +0000 (UTC) Cc: emacs-devel@gnu.org To: Kenichi Handa Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jun 10 09:33:08 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 1MEIJ1-0006CQ-Os for ged-emacs-devel@m.gmane.org; Wed, 10 Jun 2009 09:33:08 +0200 Original-Received: from localhost ([127.0.0.1]:35216 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MEIJ1-0008SG-32 for ged-emacs-devel@m.gmane.org; Wed, 10 Jun 2009 03:33:07 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MEIIv-0008Of-D3 for emacs-devel@gnu.org; Wed, 10 Jun 2009 03:33:01 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MEIIq-0008IK-5o for emacs-devel@gnu.org; Wed, 10 Jun 2009 03:33:00 -0400 Original-Received: from [199.232.76.173] (port=51786 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MEIIq-0008I6-2N for emacs-devel@gnu.org; Wed, 10 Jun 2009 03:32:56 -0400 Original-Received: from mail-pz0-f181.google.com ([209.85.222.181]:58517) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MEIIp-0001Kx-I0 for emacs-devel@gnu.org; Wed, 10 Jun 2009 03:32:55 -0400 Original-Received: by pzk11 with SMTP id 11so561530pzk.14 for ; Wed, 10 Jun 2009 00:32:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:in-reply-to:references :mime-version:content-type:message-id:cc:content-transfer-encoding :from:subject:date:to:x-mailer; bh=WOPyKMeCtMnxNCK860xtDQIG8YfYfOabF0GBjKQlIxQ=; b=RjDOIYVfVHILXXt/gpYdp41m1pR6dGOA4J21+zEXfrTS/aUclwZU6sfxDrzuyUavZE gCmgkFyVvCyrbiAqxaJbHd7S87EMpGD1p3PYeQpmHdVgv/FncrkKsUYBqHb8qPQkz5a2 WM5IwqReyeGY409NvXhSjaFZFUc9MiMCQBcTg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=in-reply-to:references:mime-version:content-type:message-id:cc :content-transfer-encoding:from:subject:date:to:x-mailer; b=AdEfhWoXMvozn/irb1mkQezYAWnlFyYxWAhBUd0XrV1CF3t0hbbQF9iS8hnfkaZ7nI QgcFOCz8lADzwwIzCxYuRauTbuzO6pF1pklt9MaTA2vGwBv6ghDFbkjmNoVyHuESZUDp 2/NOi/IrP70DDEDZRUupjAiSZ0Y7eUt0Runek= Original-Received: by 10.142.135.16 with SMTP id i16mr394178wfd.335.1244618814476; Wed, 10 Jun 2009 00:26:54 -0700 (PDT) Original-Received: from ?192.168.1.25? (ppp-58-8-183-5.revip2.asianet.co.th [58.8.183.5]) by mx.google.com with ESMTPS id 30sm2048256wfc.18.2009.06.10.00.26.50 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 10 Jun 2009 00:26:52 -0700 (PDT) In-Reply-To: X-Mailer: Apple Mail (2.753.1) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) 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:111409 Archived-At: On Jun 8, 2009, at 9:49 AM, Kenichi Handa wrote: > In article <8BA022EF-AACD-495A-ABBB-24B230475217@gmail.com>, Adrian > Robert writes: >> >> - registry in the font spec proper >> - :script property in "extra" properties >> - :lang property in "extra" >> - part of the :otf property bundle in "extra" > >> I haven't found a way to respond to the first type of query using >> Cocoa APIs yet. > > In that case, you can simply reject any register other than > "iso10646-1". OK, that's what we are doing. >> In particular, for some >> languages like Thai, only OTF requests ever seem to get made. It >> seems like this class might be the scripts requiring compositional >> rendering, but why, since emacs used to be able to handle >> compositional rendering without making use of any OTF-specific >> properties provided by a font driver? > > Emacs 23 still can use non-OTF Thai font if the registry is > tis620 or iso8859-11. The default fontset has this entry > for Thai. > > (thai ,(font-spec :registry "iso10646-1" :otf '(thai nil nil > (mark))) > (nil . "TIS620*") > (nil . "ISO8859-11")) > > The reason why I added :otf for "iso10646-1" is that now we > have many OTF Thai fonts usable with Xft font-backend (and > perhaps with uniscribe backend). OTF Thai fonts provide > better Thai rendering than the simple relative stacking > method of Emacs 22. But, if OTF is not available on Cocoa, > I'll change the entry for Thai to something like this: > > (thai ,(font-spec :registry "iso10646-1" :otf '(thai nil nil > (mark))) > ,(font-spec :registry "iso10646-1" :scritp 'thai) > (nil . "TIS620*") > (nil . "ISO8859-11")) > > Does it solve your problem? 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. >> 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? > So, not only `ja', emacs should try `zh' if `ja' is not > available. Doesn't it happen on Cocoa? As long as there are Japanese fonts on the system (always true on OS X), the first 'ja request will return fonts and the 'zh one will never get made. >> 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".