emacs-devel
[Top][All Lists]
Advanced

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

Re: Font back end font selection process


From: Kenichi Handa
Subject: Re: Font back end font selection process
Date: Wed, 10 Jun 2009 20:04:33 +0900

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




reply via email to

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