Ben Harper wrote:
> Some of my customers want to use the 'l' symbol from the MT Extra
> font. If one takes a look at that font in the Windows Character Map
> tool, it shows up as character 0x6C, which is the ascii code for 'l'.
> However, if one loads the font in freetype ( 2.1.10), it appears to
> have two charmaps. The first is APPLE_ROMAN, and the second is
> MS_SYMBOL. Now neither of these charmaps yields the correct glyph for
> character code 0x6C (they both yield the .notdef glyph for 0x6C). I
> don't understand. How does Windows make the connection between 0x6C
> and that 'l' glyph. I've looked at the embedded glyph names, but they
> don't seem to be useful.
http://www.microsoft.com/typography/otspec/os2.htm#fci
For fonts witn cmap 3.0 (MS_SYMBOL), Windows maps that cmap onto the
Windows ANSI range in the way that the value found in
OS/2.usFirstCharIndex is mapped onto the space character (0x0020) and so
on. Since MT Extra has 0xF020 in OS/2.usFirstCharIndex, it means that in
Windows, that font's cmap 3.0 (MS_SYMBOL) is mapped onto Windows ANSI so
that the ANSI 0x006C character accesses the MS_SYMBOL cmap entry 0xF06C,
which indeed maps to the glyph named "l" (containing the litre symbol).
--
Adam Twardoch
| Language Typography Unicode Fonts OpenType
| twardoch.com | silesian.com | fontlab.net