by Michael S. Kaplan, published on 2006/12/03 09:01 -05:00, original URI: http://blogs.msdn.com/b/michkap/archive/2006/12/03/1196177.aspx
Chad's question was simple enough:
Hello. I am trying to output character 0x80 from font Wingdings 3.
I add the text as:tszText[2] = {0x80, '\0'};
I create the font as:
HFONT hFont = CreateFont(14, 0, 0, 0, 0, 0, 0, 0, SYMBOL_CHARSET, OUT_DEFAULT_PRECIS, CLIP_DEFAULT_PRECIS, NONANTIALIASED_QUALITY, FF_DONTCARE, _T("WingDings 3"));
I output the text as:
TextOut(hDC, iLeft, iTop, tszText, 1);
This produces the square that shows that the character isn't found. However, if you look at the character map, it is there.
If I change the text to output something like 0x21, then it has no problem displaying the character. Yes, the Wingdings 3 character is properly picked.
Any ideas what the problem may be?
Indeed, if you look at the font, the character clearly appears to be where Chad was expecting it:
The key to understanding the problem here is something I covered last year in More than you ever wanted to know about CP_SYMBOL.
Basically, within the font itself, this symbol may be at position 0x80.
But to NLS (and thus any attempt to convert the text via CP_SYMBOL), it is actually going to be at U+f080. Which of course points to the easy workaround....
Interestingly, fileformat.info (the provider of all those Unicode links) claims that U+F080 is not a valid unicode character, depite the fact that it returns data about the Unicode block it is in. I also noticed that it is not using CharUnicodeInfo to get its Microsoft data, which I suppose might be a cool enhancement to that site. :-)
But in the meantime it causes interesting problems if you don't use those PUA assignments, especially given all of the random places in GDI, GDI+, RichEdit, Word, and Avalon where sometimes 0x80 will work, and other times it won't, up to and including random problems like the one I pointed out in U+0080 is not the Euro!. You may see tht currency symbol popping up in random places if the font isn't Wingdings 3!
For what it's worth, there are suggestions in the Unicode community to encode many of the widely available symbols not already in Unicode, such as ones contained in the Webdings/Wingdings fonts. It is unknown whether that will happen or not (and even if it did it is unlikely that the fonts would be changed; only new fonts would use the new code points if they were added), but one advantage to this approach is that it removes the problems that symbol fonts can so easily run into.
This post brought to you by (U+f080, a character in the PRIVATE USE AREA)
# Ben Cooke on 3 Dec 2006 11:18 AM:
I actually made my own unicode version of Wingdings, because I'm weird like that. Obviously it only included the symbols that have unicode code-points in the Symbols and Dingbats range. The rest all live in the private use area.
It does seem a bit odd to me to have what is basically clip-art stored inside font files, though.
# Jonathan Wilson on 3 Dec 2006 7:54 PM:
I dont see that you could ever encode ALL of wingdings/webdings as characters (would microsoft allow 0xFF in Wingdings to be enoded for example)
Interestingly enough, the "Dingbats" block of unicode seems to be an almost verbatim encoding of Zapf Dingbats minus those that are encoded elsewhere. I wonder if there is a story behind that somewhere :)
referenced by