[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Font back end font selection process

From: Adrian Robert
Subject: Re: Font back end font selection process
Date: Wed, 10 Jun 2009 14:27:34 +0700

On Jun 8, 2009, at 9:49 AM, Kenichi Handa wrote:

In article <address@hidden>, Adrian Robert <address@hidden> 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

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".

reply via email to

[Prev in Thread] Current Thread [Next in Thread]