From: Asmus Freytag (firstname.lastname@example.org)
Date: Sat Apr 18 2009 - 16:41:20 CDT
On 4/18/2009 8:28 AM, Doug Ewell wrote:
> Peter Constable <petercon at microsoft dot com> replied to Christopher
>>>> The Wingdings and Webdings family of fonts, distributed with every
>>>> copy of Windows for over a decade, absolutely qualify as
>>>> "compatibility character sets" according to the guidelines being
>>>> applied for the emoji.
>>> At least Microsoft has always mapped the glyphs in Wingdings and
>>> Webdings to the PUA.
>> Not 100% true. These fonts are encoded in a encoding called "symbol"
>> -- which means a font-specific encoding. The Symbol encoding uses a
>> 16-bit representation in the fonts, and typically fonts have
>> characters mapped from F020 to F0FF. It looks a lot like Unicode PUA,
>> though strictly speaking it is not.
> The duck test tends to support Chris. When I type :) into a Word 2003
> file (thus changing it to the smiley-face Wingding) and copy and paste
> it into BabelPad, a plain-text but very Unicode-aware editor, BabelPad
> tells me the character (with font information stripped) is U+F04A.
> This is within the Unicode PUA, even if Microsoft has a different
> interpretation of what is going on.
And, in this case all of you are wrong ;-)
The way these fonts work, and the way the SYMBOL charset is designed,
was to allow BOTH the use of ASCII and the PUA.
To see this, try (on Windows):
-> you will see the smiley
Now type J
-> you will see another smiley
In other words, both 004A and F04A end up displaying the same glyph.
The way the designers of this feature explained this to me (a long time
ago) it allowed fonts to support the PUA so that they would not overload
the ASCII codes, but at the same time, existing fonts that were mapped
to the ASCII range would continue to function, as would existing
(pre-Unicode) applications that expected symbol fonts to be mapped to
the ASCII area.
This archive was generated by hypermail 2.1.5 : Sat Apr 18 2009 - 16:44:07 CDT