Ntemacs chooses wrong font.

Ntemacs chooses wrong font.

[Kevin Yu]

[-- Attachment #1: Type: text/plain, Size: 939 bytes --]

If you input any Chinese into a new buffer, Ntemacs will use the same font
as ASCII characters (iso8859-1). Of course that font is not suitable for
Chinese, so I get only white spaces on the window. describe-char shows that
emacs has detected that it's a Chinese character, but chosen a wrong
font(wrong charset):
      character: 实 (23454, #o55636, #x5b9e)
preferred charset: gb18030 (GB18030)
       code point: 0xCAB5
           syntax: w     which means: word
         category: C:Chinese (Han) characters of 2-byte character sets
c:Chinese
           |:While filling, we can break a line at this character.
      buffer code: #xE5 #xAE #x9E
        file code: #xCA #xB5 (encoded by coding system chinese-gb18030-unix)
          display: by this font (glyph code)
     -outline-Monaco-normal-normal-normal-mono-13-*-*-*-c-*-iso8859-1 (#x03)
if I open a existed file with Chinese characters, everything goes well.

Best wishes.

Kevin

[-- Attachment #2: Type: text/html, Size: 1821 bytes --]

Re: Ntemacs chooses wrong font.

[Jason Rumney]

Kevin Yu wrote:
> If you input any Chinese into a new buffer, Ntemacs will use the same
> font as ASCII characters (iso8859-1). Of course that font is not
> suitable for Chinese, so I get only white spaces on the window.
> describe-char shows that emacs has detected that it's a Chinese
> character, but chosen a wrong font(wrong charset):
> character: 实 (23454, #o55636, #x5b9e)
> preferred charset: gb18030 (GB18030)
> code point: 0xCAB5
> -outline-Monaco-normal-normal-normal-mono-13-*-*-*-c-*-iso8859-1 (#x03)

Another font that maps unsupported glyphs to 0x03 instead of 0x00.
DejaVu Sans Mono seems to do this too. Perhaps it is common amongst
truetype fonts that were not designed for Windows.

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

Can you show the output you get from C-u C-x = in that case? It seems
strange that a different font would be used for the two cases. Perhaps
comparing the two outputs will give some clues.

Re: Ntemacs chooses wrong font.

[Kevin Yu]

[-- Attachment #1: Type: text/plain, Size: 2047 bytes --]

       character: 实 (23454, #o55636, #x5b9e)
preferred charset: gb18030 (GB18030)
       code point: 0xCAB5
           syntax: w     which means: word
         category: C:Chinese (Han) characters of 2-byte character sets
c:Chinese
           |:While filling, we can break a line at this character.
      buffer code: #xE5 #xAE #x9E
        file code: #xCA #xB5 (encoded by coding system chinese-gb18030-unix)
          display: by this font (glyph code)
     -outline-      -normal-normal-normal-mono-13-*-*-*-c-*-gb2312.1980-0
(#x1172)

Emacs displays the font family name as:"\320\302\313\316\314\345"
those octal bytes represent for "新宋体", in fact it isn't the font I tell
emacs to choose for Chinese characters.

By the way, in the elisp manual, all localized strings are showed as octal
bytes, Here's an example:

-- \272\257\312\375: funcall function &rest arguments
     `funcall' calls FUNCTION with ARGUMENTS, and returns whatever
     FUNCTION returns.

On Sat, Jun 7, 2008 at 5:23 AM, Jason Rumney <jasonr@gnu.org> wrote:

> Kevin Yu wrote:
> > If you input any Chinese into a new buffer, Ntemacs will use the same
> > font as ASCII characters (iso8859-1). Of course that font is not
> > suitable for Chinese, so I get only white spaces on the window.
> > describe-char shows that emacs has detected that it's a Chinese
> > character, but chosen a wrong font(wrong charset):
> > character: 实 (23454, #o55636, #x5b9e)
> > preferred charset: gb18030 (GB18030)
> > code point: 0xCAB5
> > -outline-Monaco-normal-normal-normal-mono-13-*-*-*-c-*-iso8859-1 (#x03)
>
> Another font that maps unsupported glyphs to 0x03 instead of 0x00.
> DejaVu Sans Mono seems to do this too. Perhaps it is common amongst
> truetype fonts that were not designed for Windows.
>
> > if I open a existed file with Chinese characters, everything goes well.
>
> Can you show the output you get from C-u C-x = in that case? It seems
> strange that a different font would be used for the two cases. Perhaps
> comparing the two outputs will give some clues.
>
>

[-- Attachment #2: Type: text/html, Size: 2921 bytes --]

Re: Ntemacs chooses wrong font.

[Kevin Yu]

[-- Attachment #1: Type: text/plain, Size: 2208 bytes --]

This issue still exists. :)...

Best Wishes

2008/6/7 Kevin Yu <yujie052@gmail.com>:

>        character: 实 (23454, #o55636, #x5b9e)
> preferred charset: gb18030 (GB18030)
>        code point: 0xCAB5
>            syntax: w     which means: word
>          category: C:Chinese (Han) characters of 2-byte character sets
> c:Chinese
>            |:While filling, we can break a line at this character.
>       buffer code: #xE5 #xAE #x9E
>         file code: #xCA #xB5 (encoded by coding system
> chinese-gb18030-unix)
>           display: by this font (glyph code)
>      -outline-      -normal-normal-normal-mono-13-*-*-*-c-*-gb2312.1980-0
> (#x1172)
>
> Emacs displays the font family name as:"\320\302\313\316\314\345"
> those octal bytes represent for "新宋体", in fact it isn't the font I tell
> emacs to choose for Chinese characters.
>
> By the way, in the elisp manual, all localized strings are showed as octal
> bytes, Here's an example:
>
> -- \272\257\312\375: funcall function &rest arguments
>      `funcall' calls FUNCTION with ARGUMENTS, and returns whatever
>      FUNCTION returns.
>
>
> On Sat, Jun 7, 2008 at 5:23 AM, Jason Rumney <jasonr@gnu.org> wrote:
>
>> Kevin Yu wrote:
>> > If you input any Chinese into a new buffer, Ntemacs will use the same
>> > font as ASCII characters (iso8859-1). Of course that font is not
>> > suitable for Chinese, so I get only white spaces on the window.
>> > describe-char shows that emacs has detected that it's a Chinese
>> > character, but chosen a wrong font(wrong charset):
>> > character: 实 (23454, #o55636, #x5b9e)
>> > preferred charset: gb18030 (GB18030)
>> > code point: 0xCAB5
>> > -outline-Monaco-normal-normal-normal-mono-13-*-*-*-c-*-iso8859-1 (#x03)
>>
>> Another font that maps unsupported glyphs to 0x03 instead of 0x00.
>> DejaVu Sans Mono seems to do this too. Perhaps it is common amongst
>> truetype fonts that were not designed for Windows.
>>
>> > if I open a existed file with Chinese characters, everything goes well.
>>
>> Can you show the output you get from C-u C-x = in that case? It seems
>> strange that a different font would be used for the two cases. Perhaps
>> comparing the two outputs will give some clues.
>>
>>
>

[-- Attachment #2: Type: text/html, Size: 3322 bytes --]

Re: Ntemacs chooses wrong font.

[Jason Rumney]

Kevin Yu wrote:
> character: 实 (23454, #o55636, #x5b9e)
> preferred charset: gb18030 (GB18030)
> code point: 0xCAB5
> syntax: w which means: word
> category: C:Chinese (Han) characters of 2-byte character sets c:Chinese
> |:While filling, we can break a line at this character.
> buffer code: #xE5 #xAE #x9E
> file code: #xCA #xB5 (encoded by coding system chinese-gb18030-unix)
> display: by this font (glyph code)
> -outline- -normal-normal-normal-mono-13-*-*-*-c-*-gb2312.1980-0 (#x1172)
>
> 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.

> those octal bytes represent for "新宋体", in fact it isn't the font I
> tell emacs to choose for Chinese characters.

How do you tell Emacs which font to use for Chinese characters?

I am trying to reproduce the scenario here so I can see what is going wrong.

> By the way, in the elisp manual, all localized strings are showed as
> octal bytes, Here's an example:

I don't see any localized strings in the elisp manual. Perhaps that is a
problem with the version of makeinfo that you use to build them. It is
not related to the font names, anyway.

>     > -outline-Monaco-normal-normal-normal-mono-13-*-*-*-c-*-iso8859-1
>     (#x03)
>

What does the following report if you press C-x C-e at the end of the line?

(insert (prin1-to-string (list-fonts (font-spec :family "Monaco"
:registry "iso8859-1"))))

Re: Ntemacs chooses wrong font.

[Kevin Yu]

[-- Attachment #1: Type: text/plain, Size: 2409 bytes --]

Thanks for your reply.

Here follows my comments.

2008/6/11 Jason Rumney <jasonr@gnu.org>:

> Kevin Yu wrote:
> > character: 实 (23454, #o55636, #x5b9e)
> > preferred charset: gb18030 (GB18030)
> > code point: 0xCAB5
> > syntax: w which means: word
> > category: C:Chinese (Han) characters of 2-byte character sets c:Chinese
> > |:While filling, we can break a line at this character.
> > buffer code: #xE5 #xAE #x9E
> > file code: #xCA #xB5 (encoded by coding system chinese-gb18030-unix)
> > display: by this font (glyph code)
> > -outline- -normal-normal-normal-mono-13-*-*-*-c-*-gb2312.1980-0 (#x1172)
> >
> > 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.
>
> > those octal bytes represent for "新宋体", in fact it isn't the font I
> > tell emacs to choose for Chinese characters.
>
> How do you tell Emacs which font to use for Chinese characters?
>
> I am trying to reproduce the scenario here so I can see what is going
> wrong.

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


>
>
> > By the way, in the elisp manual, all localized strings are showed as
> > octal bytes, Here's an example:
>
> I don't see any localized strings in the elisp manual. Perhaps that is a
> problem with the version of makeinfo that you use to build them. It is
> not related to the font names, anyway.
>
> >     > -outline-Monaco-normal-normal-normal-mono-13-*-*-*-c-*-iso8859-1
> >     (#x03)
> >
>
> What does the following report if you press C-x C-e at the end of the line?
>
> (insert (prin1-to-string (list-fonts (font-spec :family "Monaco"
> :registry "iso8859-1"))))

(#<font-entity uniscribe outline Monaco mono iso8859-1 normal normal normal
0 nil 110 nil ((:format . truetype) (:script latin))> #<font-entity gdi
outline Monaco mono iso8859-1 normal normal normal 0 nil 110 nil ((:format .
truetype) (:script latin))>)

[-- Attachment #2: Type: text/html, Size: 3472 bytes --]

Re: Ntemacs chooses wrong font.

[Jason Rumney]

Kevin Yu wrote:
> 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"))

Thanks, I can reproduce the original problem with these settings.

For the other problem (a different font being used even when Chinese
characters display), you may need to use the localized font name of
Microsoft Yahei. Maybe the following will tell you what that is, as I
expect that Windows recognizes the ASCII names for fonts even if it
outputs the localized name.

(list-fonts (font-spec :family "Microsoft Yahei"))

Re: Ntemacs chooses wrong font.

[Kenichi Handa]

In article <42b562540806110351p699e4ad8l19b5841724eef431@mail.gmail.com>, "Kevin Yu" <yujie052@gmail.com> 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
handa@ni.aist.go.jp

Re: Ntemacs chooses wrong font.

[Kevin Yu]

[-- Attachment #1: Type: text/plain, Size: 1609 bytes --]

If I change font configuration to:
(set-frame-font "Monaco-10")
(set-fontset-font (frame-parameter nil 'font)
          'han (font-spec :family "Microsoft Yahei" :size 16))
(set-fontset-font (frame-parameter nil 'font)
          'symbol (font-spec :family "Microsoft Yahei" :size 16))
(set-fontset-font (frame-parameter nil 'font)
          'cjk-misc (font-spec :family "Microsoft Yahei" :size 16))
(set-fontset-font (frame-parameter nil 'font)
          'bopomofo (font-spec :family "Microsoft Yahei" :size 16))

Emacs will use the right Chinese font.

On Wed, Jun 11, 2008 at 7:27 PM, Jason Rumney <jasonr@gnu.org> wrote:

> Kevin Yu wrote:
> > 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"))
>
> Thanks, I can reproduce the original problem with these settings.
>
> For the other problem (a different font being used even when Chinese
> characters display), you may need to use the localized font name of
> Microsoft Yahei. Maybe the following will tell you what that is, as I
> expect that Windows recognizes the ASCII names for fonts even if it
> outputs the localized name.
>
> (list-fonts (font-spec :family "Microsoft Yahei"))
>
>
>

[-- Attachment #2: Type: text/html, Size: 2372 bytes --]

Re: Ntemacs chooses wrong font.

[Kevin Yu]

[-- Attachment #1: Type: text/plain, Size: 2269 bytes --]

On Wed, Jun 11, 2008 at 7:50 PM, Kenichi Handa <handa@m17n.org> wrote:

> In article <42b562540806110351p699e4ad8l19b5841724eef431@mail.gmail.com>,
> "Kevin Yu" <yujie052@gmail.com> 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.

Why does the backend say the frame font support the Chinese charset?
Is it a bug of Windows font backend or a bug of "Monaco" font?
I have tried to use "Courier New", but emacs can't choose the right font for
Chinese either.


>
>
> > 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
> handa@ni.aist.go.jp
>

[-- Attachment #2: Type: text/html, Size: 3443 bytes --]

Re: Ntemacs chooses wrong font.

[Kenichi Handa]

In article <42b562540806110509k597da392xa83823c47958e007@mail.gmail.com>, "Kevin Yu" <yujie052@gmail.com> writes:

> Why does the backend say the frame font support the Chinese charset?
> Is it a bug of Windows font backend or a bug of "Monaco" font?

I think so because you wrote that C-u C-x = shows this:
      character: 实 (23454, #o55636, #x5b9e)
[...]
     -outline-Monaco-normal-normal-normal-mono-13-*-*-*-c-*-iso8859-1 (#x03)

It means that the backend says that the monaco font has the
glyph for U+5B9E at the glyph-ID 3.

---
Kenichi Handa
handa@ni.aist.go.jp

Re: Ntemacs chooses wrong font.

[Jason Rumney]

Kenichi Handa wrote:
> 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.
>   

Does that mean that the encoding will eventually be done in generic 
code, so I should avoid fixing this in w32font.c?

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

The problem appears to be that the system API used in one of the 
encode_char functions on Windows (I don't know whether it is uniscribe 
or gdi) seems to return a space glyph for unsupported characters in some 
fonts, instead of 0 (which is ".notdef" according to the truetype spec).

Perhaps C-u C-x = should also report which font backend a font belongs 
to, to make tracking these sorts of bugs down easier.

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

Ah, that explains a lot.

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

Where is the has_char function used? On Windows, this should work to 
filter out unsuitable fonts, as it checks the character against the 
font's supported scripts.

Re: Ntemacs chooses wrong font.

[Jason Rumney]

Kevin Yu wrote:
> If I change font configuration to:
> (set-frame-font "Monaco-10")
> (set-fontset-font (frame-parameter nil 'font)
>           'han (font-spec :family "Microsoft Yahei" :size 16))
> (set-fontset-font (frame-parameter nil 'font)
>           'symbol (font-spec :family "Microsoft Yahei" :size 16))
> (set-fontset-font (frame-parameter nil 'font)
>           'cjk-misc (font-spec :family "Microsoft Yahei" :size 16))
> (set-fontset-font (frame-parameter nil 'font)
>           'bopomofo (font-spec :family "Microsoft Yahei" :size 16))
>
> Emacs will use the right Chinese font.

It seems the problem is using "unicode-bmp" for the registry. There are 
so many aliases for the unicode registry, and it seems that to work 
correctly, the w32 font backends need to explicitly recognize them all. 
I think things will work better with "iso10646-1", which the w32 font 
backends do recognize.

>     > (set-fontset-font (frame-parameter nil 'font)
>     > 'han '("Microsoft Yahei"."unicode-bmp"))
>

Re: Ntemacs chooses wrong font.

[Kenichi Handa]

In article <484FC664.1070403@gnu.org>, Jason Rumney <jasonr@gnu.org> writes:

> Kenichi Handa wrote:
> > 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.

> Does that mean that the encoding will eventually be done in generic 
> code, so I should avoid fixing this in w32font.c?

No.  The encoding and decoding must be done in each font
backend because only the backend knows how to do that.

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

> The problem appears to be that the system API used in one of the 
> encode_char functions on Windows (I don't know whether it is uniscribe 
> or gdi) seems to return a space glyph for unsupported characters in some 
> fonts, instead of 0 (which is ".notdef" according to the truetype spec).

It seems that this is a serious problem, but it's
unbelievable that Windows doesn't have a proper API to check
whether a font supports a specific character or not.

> Perhaps C-u C-x = should also report which font backend a font belongs 
> to, to make tracking these sorts of bugs down easier.

Ok, I'll add that soon.

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

> Ah, that explains a lot.

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

> Where is the has_char function used? On Windows, this should work to 
> filter out unsuitable fonts, as it checks the character against the 
> font's supported scripts.

The has_char method is called in fontset_find_font (in
fontset.c) to decide that the selected font is usable for
a specific character.

---
Kenichi Handa
handa@ni.aist.go.jp

Re: Ntemacs chooses wrong font.

[Juanma Barranquero]

On Wed, Jun 11, 2008 at 14:34, Jason Rumney <jasonr@gnu.org> wrote:

> The problem appears to be that the system API used in one of the encode_char
> functions on Windows (I don't know whether it is uniscribe or gdi) seems to
> return a space glyph for unsupported characters in some fonts, instead of 0
> (which is ".notdef" according to the truetype spec).

FWIW, that's what I see:

  - using gdi (because I've forced Emacs to fail loading usp10.dll or
by using Emacs.fontBackend: gdi) => Emacs "finds" U+2200 at glyph #3
of DejaVu Sans Mono.
  - using uniscribe (by means of Emacs.fontBackend: uniscribe) =>
Emacs correctly finds U+2200 at #421 of MS Mincho.
  - leaving it to itself to choose (no Emacs.fontBackend): it "find"
the #x3 glyph in DejaVu Sans Mono

so it seems gdi-related.

> Perhaps C-u C-x = should also report which font backend a font belongs to,
> to make tracking these sorts of bugs down easier.

BTW, perhaps there should be a (trivial) function to list available
backends. Currently the only way I can see is

   (cdr (assq 'font-backend (frame-parameters)))

and that depends on Emacs.fontBackend not being set to limit the list.

   Juanma

Re: Ntemacs chooses wrong font.

[Jason Rumney]

Kevin Yu wrote:
> If you input any Chinese into a new buffer, Ntemacs will use the same
> font as ASCII characters (iso8859-1).

Can you confirm whether this is fixed now?