As you might know we’re developing a specialised information system. It’s been widely used in Asia, in fact one of our first international customers was (and still is) located in India. Thanks to this geographical variety we’re facing issues with exotic language/script support quite often. Last time we had an issue with Urdu script, that’s been used in Pakistan. It’s still not supported in mainstream operating systems (first support came with Vista/Office2007), a special commercial software is needed for that, it doesn’t to seem to adhere to Microsoft (or any) standards, it sort of works but there are still issues. The biggest problem with Urdu is it’s height which can really vary depending on what’s written
Yesterday I was asked about Dzongkha support. Dzongkha is the official language of the Kingdom of Bhutan. It’s using Tibetan script for written form. The good news is that there are free fonts available. I installed one of them (Jomolhari) and started experimenting with it. Just to run into complete failure – no part of the system was able to show anything else than “boxes” – at least on Windows I started with. There were only two parts of the system being able to show Dzongkha properly – but only thanks to their ability to change font used for them.
Imagining how complicated/annoying it would be to change all Swing controls to use Jomolhari font (ie. adding configuration, making sure that setFont() is called on every single JComponent, testing it….) made me feel really bad. On top of that latin script rendered by Jomolhari was really ugly (especially in small sizes like 10, 12pts).
I remembered that there was a way how to specify font substitutions in Java fortunately and after couple of minutes I got the right article http://java.sun.com/j2se/1.5.0/docs/guide/intl/fontconfig.html on Sun’s website.
I started reading the document but even after finishing I was not exactly sure what should be done – there’s a paragraph about substitution, about character subsets but – Tibetan, Dzonghka was not there. Having studied Unicode pages I knew that Tibetan characters are occupying their designated range starting with 0x0F00 yet there didn’t seem to be support for this subset. I tried adding line with:
sansserif.plain.tibetan=Jomolhari
but it didn’t seem to change anything, boxes again. While getting ready to leave the office I got one last idea – what if China somehow owns Tibetan range? They keep claiming that Tibet belongs to them, so why not the Unicode range too? So I changed line with Chinese subset:
sansserif.plain.chinese-ms950=MingLiU
to Jomolhari font
sansserif.plain.chinese-ms950=Jomolhari
and – voilà, there we go – it worked as a charm. But – what if this disables Chinese, I thought. Quick test revealed that my worries were needless, Kanji characters worked too. And latin as well, rendered in usual quality.
So, what exactly is needed? Just follow steps below:
- Install appropriate fonts (ie. Jomolhari)
- Locate
fontconfig.properties.src($JAVA_HOME/lib) - Rename it to fontconfig.properties (remove .src suffix)
- Replace all occurrences of
.chinese-ms950=(P/MingLiU)with.chinese-ms950=Jomolhari - Quit all Java processes and start your Swing application again
- Every single Swing component should be capable of displaying Tibetan script properly – if not check if you’re using “logical” fonts and not forcing physical ones (there are five logical fonts, read the Javadoc for Font class)
Having solved problem on Windows I moved to Mac – just to see that on MacOSX Leopard (10.5.6) fonts for Tibetan are installed by default and working in Java out of the box. Good work, Steve.
I have now made a version of the Jomolhari font (“Jomohari ID”) that should work cross-platform on Windows, Mac OSX (10.5.x), Linux and in Adobe InDesign CS3 & CS4 – so now you should be able use the same Tibetan script font on all platforms.
This version of the font is freely available from .
The extra open type features and lookups used in this font to enable it to work cross-platform will be incorporated into the main Jomolhari font with the next update.
The link to the font mentioned in the comment above should be:
http://www.thlib.org/tools/#wiki=/access/wiki/site/26a34146-33a6-48ce-001e-f16ce7908a6a/jomolhari%20id.html
I have tried both Jomolhari and “Tibetan Machine Uni” within the swing JTextPane and JEditorPane components, and they do not properly render ra-go characters (\u0F62 when atop a subjoined code), nor do they float aspirated “A” correctly. I was shocked that even the latest version of Java still renders these incorrectly. Anybody know of a solution for this? I know I am outputting the correct unicode, because I can copy these characters from my java app and paste them into Open Office Writer, and they appear correctly.
Chuck,
you’re more than right. I’ve found out later after this article was published and been struggling with it since then. We seem to have a solution now, expect an updated article about final solution soon.
I have gotten eclipse’s SWT to work, but I don’t like using that, for two other reasons. First, it means including a library in my executable JAR, making it much bigger. Second, it works great in Windows, but fails outright in Ubuntu (which is where I do most of my work). I have investigated another GUI toolkit called “Qt Jambi”, but it apparently makes things even less portable than SWT. Both of these ideas are going in the wrong direction.
I did see another project that sought to make a 100% java font rendering layer, mostly for mobile use of Java. But it bombed when I tried to run the applet. Not a good sign. Not only that, there’s no telling whether these libraries can (or should) be used in anything other than Java ME.
I tried several different JVMs on Windows, including Apache Harmony, BEA’s JRocket. No improvements.
So far, nothing built into Java seems to work. If I find something, I’ll post here…
Chuck,
in order to prevent you from trying dead ended paths – JTextComponent+set Document propery “i18n” to true+use Tibetan Machine Uni font. No solution for JLabel-based components yet.
This works fine on both Ubuntu and Windows (and fails miserably on MacOSX).
After circling back to SWT, I realized I missed what it was all about. It not meant to be a compile-once-run-anywhere solution. In that regard it’s very un-Java-like. One must vary the underlying JAR files according to the target platform, but by doing that, the java application will use more native features (and look more native, and run faster). That’s interesting enough for me to write SWT versions of this for various platforms. Since my transcriber is independent of the GUI bits anyway, I can roll this all into one project.
Funny how one cryptic line can make all the difference:
bottomDoc.putProperty(“i18n”, Boolean.TRUE);
THANKS AWE!
Since I don’t use Mac, I’ll have to wait until someone pesters me… and then I’ll probably just give them a SWT_based mac fix.