[Top][All Lists]

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

Re: Font selection weirdness

From: Jason Rumney
Subject: Re: Font selection weirdness
Date: Mon, 26 May 2008 13:36:41 +0100
User-agent: Thunderbird (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
          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.

reply via email to

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