Is East Asian support installed?

by Michael S. Kaplan, published on 2006/07/25 05:01 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2006/07/25/677592.aspx

Michiel Salters asked in the Suggestion Box:

MLang font linking works without us asking , it's just too nice. Really too nice, because MLang isn't telling us it failed. And in fact, we can't figure out that it's failing.

So what's the problem? Most of our users won't have east asian fonts installed. Our application needs to know this. However, due to font linking MLang is rendering our text. It just renders them as a set of boxes.

The first 10 algorithms we tries to distinguish machines with and without east asian fonts have failed. Among the obvious:
CreateFont() with CHINESEBIG5_CHARSET : works even without east asian fonts installed

Call GetGlyphIndices for the font created for CHINESEBIG5_CHARSET : suggests that font created has real glyphs (i.e. U+4E00 and U+4E01 have different glyphs)

Use IMLangFontLink2 and call GetScriptFontInfo : MSDN documentation is incomplete here, and it just font names. We can't hardcode every fontname out there.

Compare IMLangFontLink2::GetFontCodePages with IMLangFontLink2::GetCharCodePages() for U+4e00

Create a font with MLangFontLink2::MapFont, passing U+4E00 to get a chinese font. (fails straight away)

Get the chinese codepage using GetCharCodePages for U+4E00, then create a font for the codepage using MapFont. That does work, but it also works if there is in fact no font installed.

Create the font via that chinese codepage, then get the glyphs with GetGlyphIndices for U+4e00 and U+4e01. Now we were getting pretty annoyed. If there are no east asian fonts installed, we still get a font, GetGlyphIndices  tells us the glyphs U+4e00 and U+4e01 differ, yet all we get is boxes (obviously)

The final lie was MLangFontLink2::GetFontUnicodeRanges. If there are no east-asian fonts installed, it will in fact include return a  range that contains all 20.000+ CJK ideographs. Apparently means 20.000 different(!) box glyphs.

We currently see two options. The real east asian fonts are incomplete. We can just hardcode a codepoint that is currently missing, and check if MLangFontLink2::GetFontUnicodeRanges claims support. If so, we assume it's lying about all code points. Of course, if Vista adds that code point, or the user installs a font which adds that missing code point, this assumption is wrong.

The only solution we haven't tried, and we really can't imagine we have to resort to this, is rendering U+4e00 to a bitmap and see if this renders a box (two vertical lines connected by two horizontal lines)

So, where is the BOOL IsThereAFontFor(wchar_t) function hidden? And did I mention we'd want it on Windows ME/IE5 as well?

Part of the problem here is simply stated -- MLang is not all about answering whether support is not there -- it is all about trying to make the support work.

And of course the GDI problem (like using CreateFont with the CHINESEBIG5_CHARSET) is similar -- as a function it will do its best to create the requested font but if the final answer is not perfect, GDI does not spend too much time weeping. If you catch my drift.

If you really need to know whether East Asain support is installed, the best way to do it is to use the NLS IsValidLocale function with the LCID_INSTALLED flag -- it is the way that you know whether the OS thinks that all of the supporting files are there....

Be sure to pick the right LCID on downlevel systems, since everything prior to XP was a bit more granular about language support. It is no big deal, just make sure you pick the LCID that best captures the support you are looking for, that's all. :-)

I can't say too much about the IE5/Windows Me situation -- I mean, since as I said in Is MSLU Still Supported?, Windows 98 and Windows Me aren't supported anymore. Though if you truly wanting to go beyond the OS answer when it says FALSE you can see if you have the IE language support -- ether by using the model described in Installable language components in Internet Explorer or looking for the specific fonts that it installs per language....

Generally, I find this whole scenario pretty unconvincing. Maybe that is just me.

But we are talking about users who don't install East Asian support. Yet these users expect a program to magically support CJK ideographs. Users, who further will refuse to understand that they need to install the EA support if they are seeing NULL GLYPHS instead of ideographs.

When I was consulting, I never had problems pointing out this particular requirement; I have even helped write up the justification to companies that were not always willing to allow the users permissions to install stuff like this. It is just not the sort of problem that I have found a huge lack of understanding about.

But if that fails, you can just blame Microsoft. It's not like everyone else dosen't do that. :-)

 

This post brought to you by ៘ (U+17d8, a.k.a. KHMER SIGN BEYYAL)

# Tom Gewecke on 25 Jul 2006 7:52 AM:

Is there a specific reason why Asian support is not installed by default?  This used to be a space issue, I suppose,  but that would seem a lot less of a concern these days.   In forums where I help people with problems with iPod/iTunes, one of the most common questions is "why won't my Chinese (or whatever) song titles display?".  I just refer them to Dr. International's instructions on the matter.  

OS X does install support for all languages by default, so this kind of problem and need for help does not arise.

# Michael S. Kaplan on 25 Jul 2006 8:09 AM:

I assume space is the reason for EA support not being the default, but either way it is always installed in Vista....

# Serge Wautier on 30 Jul 2006 3:58 PM:

Thanks for answering a question I was about to ask ;-)

Here's one hopefully convincing scenario:

Many appTranslator users ask me why appTranslator refuses to display Chinese, Japanese, whatever. They don't want  to translate themselves. They simply want to manage the project and be able to see (not read) the translators input.

I'm usually able to restrict from replying a bare "RTFM where it says how to install EA support".

But I thought it would be cool if appTranslator could automatically detect the problem and point the user to the right help page.

Maybe Michiel has a 2nd scenario.
Or maybe he's just a competitor of mine with the same needs, in which case we stick to one ;-)

# Michiel Salters on 3 Aug 2006 9:24 AM:

Thanks for the response, IsValidLocale() should help.

One clarification up front: we don't expect CJK characters to work at all if there are no East Asian fonts installed. I haven't heard customers complaining, either. But if they don't work, well, we don't want to suggest that they /do/ work, so we need to know up front.

In our current app, even the first screen the user sees has this problem: We offer a list of UI language choices, before we load any UI, and each language choice is localized independently. Now that means that Chinese localizations will require a CJK font, and thus show up as null glyphs for those without it.

I'm also wondering if it is possible that users do have CJK fonts, but no East Asian support enabled. IsValidLocale checks for full support, so in theory we might be able to render texts even when IsValidLocale() returns false. I guess these users will just have to live with that, though.

# Michael S. Kaplan on 3 Aug 2006 9:34 AM:

Users without the support installed who independently add the fonts will get the wrong linebreaking behavior and other problems -- the best thing you can/should likely do is detect the case and maybe put up a warning. :-)
Please consider a donation to keep this archive running, maintained and free of advertising.
Donate €20 or more to receive an offline copy of the whole archive including all images.

referenced by

2007/02/06 MLang and GDI and Uniscribe, oh my!

go to newer or older post, or back to index or month or day