|Subject:||Re: Ntemacs chooses wrong font.|
|Date:||Wed, 11 Jun 2008 10:32:53 +0800|
character: 实 (23454, #o55636, #x5b9e)
preferred charset: gb18030 (GB18030)
code point: 0xCAB5syntax: w which means: word-outline- -normal-normal-normal-mono-13-*-*-*-c-*-gb2312.1980-0 (#x1172)
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)
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.
Can you show the output you get from C-u C-x = in that case? It seems
> if I open a existed file with Chinese characters, everything goes well.
strange that a different font would be used for the two cases. Perhaps
comparing the two outputs will give some clues.
|[Prev in Thread]||Current Thread||[Next in Thread]|