Well, thanks to my second favourite debugging tool (after System.out.println), strace, I figured out what was going wrong in Rants and Revelations » Today’s Java puzzlement.
(Short aside: CentOS is actually RedHat Enterprise Linux with the proprietary stuff filed off. So any changes between versions are RedHat’s fault, not CentOS’s.)
I had a short program I wrote some time ago to print out the names of all the fonts that Java knew about. Today I straced it on my CentOS 4.4 and my CentOS 5.0 machines to see what was the difference. Both machines opened up /usr/java/jdk1.5.0_11/jre/lib/fontconfig.RedHat.bfc just fine. And both started opening up various TrueType font files. But what’s that? On the CentOS 5.0 machine, I’m getting ENOENT (file not found) for /usr/share/fonts/ko/TrueType/gulim.ttf. Oh, that’s not good, since I know the installer installs the “fonts-korean” rpm, which is the CentOS 5.0 equivalent of “ttfonts-ko”, which is what I’ve got installed on CentOS 4.4. Oh, but when the geniuses at RedHat renamed the rpm, they also renamed the directory the directory that the TrueType font files go, from /usr/share/fonts/ko/TrueType to /usr/share/fonts/korean/TrueType. And when they did similar renaming with Japanese and Chinese fonts, at least they had the decency to put symlinks at the old locations.
After that, it was a simple matter to copy the /usr/java/jdk1.5.0_11/jre/lib/fontconfig.RedHat.properties.src to /usr/java/jdk1.5.0_11/jre/lib/fontconfig.RedHat.properties, fix the directory names, and voila, I have Korean fonts.
Now I just have to figure out how to get this into the delivery RPMs.