Re: Font back end font selection process

[Adrian Robert]

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