Multilingual Font Rendering
November 8, 2004
One of the most common questions I see on mailing lists and forums related to Java internationalization is “Why can’t my applet display Japanese and Chinese text when my native applications can?”
Well, if you’re using JDK 5.0, the famous “Tiger” release, there’s a good chance you don’t need to ask this question anymore. That’s because this release supports multilingual font rendering. Multi-what? OK, let’s look at a demo first – here’s one that comes with the JDK: Font2DTest.
Here’s Font2DTest running on J2RE 1.4.2 with English as the user language on Windows XP. The “CJK Unified Ideographs” characters are selected, the collection of basic Chinese (“C”) characters that are also used for Japanese (“J”) and Korean (“K”).
We see: Lots of empty boxes, indicating that the Java runtime in this environment can’t display Chinese characters. Let’s try the same with Japanese as the user language:
Well, that looks slightly better. The number of empty boxes has decreased significantly, and real characters have taken their place. The reason for the remaining empty boxes is that the CJK Unified Ideographs block contains the union of the basic characters used with Chinese, Japanese, and Korean. When running in a Japanese environment, JRE 1.4.2 finds glyphs for Japanese characters, but not for characters that are only used for Chinese or Korean.
Now, let’s see what happens with the mighty Tiger. And let’s try the most difficult environment first – plain English.
No more boxes! This is what we mean by “multilingual font rendering” – all languages together in one big happy application.
Would running in a Japanese environment still make a difference? In fact, it would:
If you look closely, you’ll see that some of the glyphs look different between the two screen shots. That’s because in a Japanese environment the JRE gives preference to Japanese fonts (and in a Korean environment to Korean fonts), while in other environments it prefers Chinese fonts.
In which situations does your application benefit from this feature? Well, first the host OS needs to have the necessary fonts installed. Most operating systems these days come with fonts for a long list of European and Asian languages; you just have to ask for them during installation or through a control panel such as the “Regional and Language Options” in Windows XP. Then, your application has to use Swing components or the Java 2D APIs for font rendering. If it uses AWT, results vary. One place where Swing applications may still see problems are window titles, because these are typically rendered using AWT. Finally, the application should use logical fonts – that’s Serif, SansSerif, Monospaced, Dialog, and DialogInput. If it uses a physical font, it gets the glyphs provided by that font, and nothing else.
There’s more information on related issues in the Java Internationalization FAQ. But at least for this question there’s now an easy answer: Get Tiger!