Re: Font selection weirdness

[Jason Rumney]

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.