emacs-devel
[Top][All Lists]
Advanced

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

Re: Ntemacs chooses wrong font.


From: Kevin Yu
Subject: Re: Ntemacs chooses wrong font.
Date: Wed, 11 Jun 2008 10:32:53 +0800

This issue still exists. :)...

Best Wishes

2008/6/7 Kevin Yu <address@hidden>:
       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 <address@hidden> 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.




reply via email to

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