From: Peter Constable (petercon@microsoft.com)
Date: Sat Apr 18 2009 - 21:43:07 CDT
From: unicode-bounce@unicode.org [mailto:unicode-bounce@unicode.org] On Behalf Of Andrew West
>> In other words, both 004A and F04A end up displaying the same glyph.
> And, in this case you are wrong as well ;-)
> There is no mapping of the glyph to 004A in the font's CMAP table.
Asmus described an experimental result. Anybody here can repeat that experiment and get those results. He is not wrong.
You have gone from his statement about empirical results to an assertion about the fonts, which assertion is true but is also one that Asmus would agree with.
> The
> fact that the smiley glyph is displayed for "J" is a Windows thing,
In this case, ultimately true; but Windows itself is not alone in this. For instance, RichEdit is also party to such conventions.
> whereby [Windows] adds an extra mapping layer from F020..F0FF in the font to
> ASCII codepoints if the font has a symbol encoding.
Not 100% true. GDI will map *some range* to ASCII code points based on the code points used in the font. (At least, it worked this way back in Win98; I haven't checked this since but I really doubt it has changed.) You can construct a font with a format 4 cmap set to platform ID 3, encoding ID 0 but with code points ranging from, say, E020..E0FF, and GDI will map "J" to E04A.
> This is no doubt
> for compatibility with pre-Unicode symbol fonts that did use ASCII
> mappings, but nevertheless the font itself does not have these ASCII
> mappings, only the Unicode ones.
You, I'm sure, would know, but clarifying for others that might not: "a pre-Unicode symbol font" would have to refer to a font in some format other than TrueType or OpenType -- raster or vector fonts in the FON or FNT format.
Peter
This archive was generated by hypermail 2.1.5 : Sat Apr 18 2009 - 21:45:57 CDT