by Michael S. Kaplan, published on 2006/10/21 05:31 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2006/10/21/852382.aspx
Michael (a different Michael, not me) asks:
Is Font.FontFamily localized?
We are doing string comparisons and wanted to use the correct culture info (CurrentCulture, CurrentUICulture, etc).
Some here will recall that I talked about part of the issue last year in East Asian Font Names and earlier this year in Getting all of the localized names of a font. While (as that first post points out) both the English name and the localized name will be accepted in a font creation function in GDI, I don't know if anyone has ever made the same claim about either GDI+ or WPF (Avalon). That could be something to try out (seeing if both ＭＳ ゴシック and MS Gothic work in GDI+ and Avalon, both in the Japanese system locale case and the non-Japanese system locale case).
Now none of this will help with the actual issue here, which is not font creation but the comparison of names. In this particular case, when trying to compare font names returned by Font.FontFamily, neither CurrentCulture nor CurrentUICulture are good options for comparison of the names. Because you really don't want behavior that is going to change based on system settings. In fact, if you simply use String.Compare with the StringComparison.OrdinalIgnoreCase option, you will mostly have the best results....
I say mostly because if different names can be returned then how good any comparison method works will depend on the strategy in place to handle the fact that the same font can return different family names. The best way to handle it would really depend on the application in question and its needs, and can vary from one extreme of never caring at all (because both names were created in the same session so they will be identical no matter what they are) to the middle solution of checking both names to the other extreme of using code like in that localized font names post and grabbing them on the fly. Which is best will depend entirely on the circumstances....
This post brought to you by ゴ (U+30b4, a.k.a. KATAKANA LETTER GO)
Carl on 21 Oct 2006 7:13 AM:
Would you happen to know what kind of font names are accepted by the various Explorers, Internet? I've had a lot of trouble getting Japanese fonts to be accepted by the various browsers. In the end, I've settled on just saying the name of the font twice in my .css files in hopes that at least one version will be accepted by someone. Also, does IE support the '@charset "utf-8";' element in CSS, or am I wasting my time by adding that? When I tested it before, it seems like it doesn't help much, so I broke down and converted the Unicode into the "\codepoint" escaped format as so:
font-family: "\ff24\ff26\ff30\96b7\66f8\4f53", DFPLeiSho-SB, serif;
Personally, I find this whole business of fonts having multiple names that are only supported by some browsers in some OSes for some language setting -- but not other! -- a bit tedious. ;-)
Michael S. Kaplan on 21 Oct 2006 12:13 PM:
Hi Carl,
Yes, sometimes that is all you can do (since lots of programs might do things like enumerate them and not accept anything outside the enumeration).
Personally, I think the multiple names things is a pretty bad design decision on the part of the font foundry, when it occurs....
Rosyna on 21 Oct 2006 2:55 PM:
I wonder, how does matching fonts via localized names work for "bad fonts". Evil fonts that report something like "Geneva CY" for the English name and "Geneva" for the Cyrillic name? If you do a search for "Geneva" which one would it pick if the current culture thingy is Russian McDealie?
These are the questions that keep me awake at night.
Michael S. Kaplan on 21 Oct 2006 3:53 PM:
It would never be based on CurrentCulture; it might be based on the UI language of Windows (which is what CurrentUICulture is based on), but still I would not use that for string comparisons (since there is no guarasnteed match between the name and the collation).
referenced by