Weird issue with Chinese characters

[hbquikcomjamesl]

We are having difficulty with a program (which currently exists as both an Eclipse plug-in and as a Windows standalone executable; at least the Eclipse plug-in uses org.eclipse.swt classes, and presumably the Windows standalone is from the same codebase) that theoretically should have no trouble displaying Chinese characters, yet it does, at least for us.

Our Chinese contract developer (in China) has no trouble with displaying (and entering) Chinese text in the program from his machine:

chines by Tracker-Backer, on Flickr

. . . yet all I get, viewing the same data in the same program (I selected a single-record view, whereas his screen shot shows a multi-record view) is a string of "substitute boxes."

failed by Tracker-Backer, on Flickr


So I banged out this simple Swing application:

package test20dec2012;

import java.util.*;
import java.awt.*;
import java.awt.geom.*;
import java.awt.image.*;
import java.awt.datatransfer.*;
import java.awt.event.*;
import java.awt.print.*;
import java.io.*;
import javax.swing.*;

public class Test20Dec2012 {
static String foo = "\u8FD9\u662F\u4E2D\u6587";

public static void main(String[] args) {
    JTextField bar = new JTextField(foo);
	JOptionPane.showMessageDialog(null, bar);
}
}

which has no trouble at all displaying Chinese characters:


test20dc2012 by Tracker-Backer, on Flickr

Any idea why the production application works on a box in China, but not on my box, even though the test application works fine?

[kaydell2]

I don't know. Could it be a difference in the font?

[hbquikcomjamesl]

I have more information since the original post:

It seems that an old Swing client program (from which the recalcitrant programs were derived) has no trouble at all displaying the Chinese characters properly from the live data, so long as either (a) I select one of the Java symbolic font names (e.g., "Dialog"), or (b) I run it on my Macintosh.

This suggests that it is indeed a matter of font rendering, and that the presence (implicit on the Mac) or absence (on the WinDoze XP box, unless it's explicitly installed) of "East Asian Language Support" is also a factor: the Firefox browser can render Chinese Unicode without requiring such support, and the Swing UI classes can do so if the Java "logical fonts" are used.

Unfortunately I don't know enough about the org.eclipse.swt UI classes to do anything about this myself.

[DarrylBurke]

I don't know enough about the org.eclipse.swt UI classes to do anything about this myself.

Moved from Advanced Java

db

[hbquikcomjamesl]

Turns out I was being stupid and pig-headed.

To have SWT applications render Chinese text properly in WinDoze XP (and presumably any other version of WinDoze in which East Asian Language Support is not built in), you need only install the East Asian Language Support option, a process that requires your installation media and a restart, and is done from the same control panel you use to set your locale (but you don't actually have to set your locale).

I realized why this is when I researched what SWT is, and how it works: Swing and SWT take diametrically opposite approaches to the inadequacies of AWT.

Swing strives for complete platform independence, doing everything in Java that it possibly can, while SWT strives for the closest possible integration with the platform, letting the OS do everything it possibly can. Therefore, it would make perfect sense for a Swing-based application to be able to display Chinese text independently of any OS-level support, while an SWT application to be totally dependent on such OS-level support.

While I still don't know enough about SWT to code my way out of a paper bag by calling it (and I still definitely prefer Swing, if I'm doing something in Java that requires a UI), at least I now understand something about the SWT approach, and the consequences thereof.