|
From: | Jason Rumney |
Subject: | Re: Font selection weirdness |
Date: | Mon, 26 May 2008 13:36:41 +0100 |
User-agent: | Thunderbird 2.0.0.14 (Windows/20080421) |
Juanma Barranquero wrote:
-------------------------------------------------------------------------------- character: ế (7871, #o17277, #x1ebf) preferred charset: unicode (Unicode (ISO10646)) code point: 0x1EBF syntax: w which means: word category: l:Latin v:Vietnamese buffer code: #xE1 #xBA #xBF file code: ESC #x2C #x31 #x2A (encoded by coding system iso-2022-7bit-dos) display: by this font (glyph code) -outline-DejaVu Sans Mono-normal-normal-normal-mono-13-*-*-*-m-*-iso8859-5 (#x03)
The choice of iso8859-5 is strange, but it doesn't actually matter on Windows, as all truetype fonts are treated as Unicode, and the different character sets reported as supported for a font are only to assist the font matching in finding the right fonts. It may just be that this font was first opened when displaying a Cyrillic character, so subsequent uses reflect that.
Character at glyph index 3 in most fonts is space, which is consistent with what you see, but it is strange that DejaVu Sans Mono maps this character to that and not glyph index 0 (.notdef) if it doesn't have a glyph for it.
If I type these characters in *scratch*, via ucs-insert, three of them are displayed correctly (U+2208, U+2022 and U+25A1), and the other three appear as empty boxes (though Emacs still thinks it has a font for them).
character: ∀ (8704, #o21000, #x2200) preferred charset: unicode (Unicode (ISO10646)) code point: 0x2200 syntax: . which means: punctuation category: h:Korean j:Japanese buffer code: #xE2 #x88 #x80 file code: #xE2 #x88 #x80 (encoded by coding system utf-8-unix) display: by this font (glyph code) -outline-DejaVu Sans Mono-normal-normal-normal-mono-13-*-*-*-m-*-iso10646-1 (#x2200)
Now the same font is being used (but with a iso10646-1 charset, so probably a different font_object pointing to the same font). But this time, it seems unicode code points are being used instead of glyph index, which indicates that an error has been returned by GetCharacterPlacementW or GetGlyphOutlineW.
To see why the error is occuring, set a breakpoint on clear_cached_metrics and when it is hit, go back up the stack (in gdb: frame 1) to see what function it has failed from. Then get information such as the return code of the failing function, the character or glyph code that it is failing on, and the font, tyo help diagnose why it has failed.
[Prev in Thread] | Current Thread | [Next in Thread] |