Re: Ntemacs chooses wrong font.

[Kenichi Handa]

In article <address@hidden>, "Kevin Yu" <address@hidden> writes:

> > > Emacs displays the font family name as:"\320\302\313\316\314\345"
> >
> > This is a bug, but it should at least be consistent, as there is no
> > encoding in either direction.

I currently explicitly generate a unibyte string for font
names just to avoid the font name encoding problem until the
font-backend codes gets stable.


> Here's my font related configuration

> (set-language-environment "chinese-gb18030")
> (set-frame-font "Monaco-10")
> (set-fontset-font (frame-parameter nil 'font)
>           'han '("Microsoft Yahei"."unicode-bmp"))
> (set-fontset-font (frame-parameter nil 'font)
>           'symbol '("Microsoft Yahei"."unicode-bmp"))
> (set-fontset-font (frame-parameter nil 'font)
>           'cjk-misc '("Microsoft Yahei"."unicode-bmp"))
> (set-fontset-font (frame-parameter nil 'font)
>           'bopomofo '("Microsoft Yahei"."unicode-bmp"))

Emacs at first checks if a charater is supported by the
frame font (here "Monaco-10") to avoid unnecessary looking
up of fontset table .  If supported, the frame font is used.
And, in your case, the font backend on Windows says that the
frame font supports it.  That is the problem.

> if I open a existed file with Chinese characters, everything goes well.

It seems that you saved the file with some of legacy
encoding (e.g. euc-cn, big5).  On reading such a file, Emacs
adds a charset text-property (e.g. chinese-gb2312, big5),
and if a character has such a property, Emacs doesn't try
the frame font, but does a normal fontset looking up
(because `charset' information may change the priority of
fonts).  So, your fontset setting above takes effect.

Perhaps, we should not try the frame font for a certain
group of charcters (e.g. han, indic, ??).

---
Kenichi Handa
address@hidden