I figured it out! The problem is not that Java is broken, but the problem with NeoJ is that it doesn't do the behind-the-scenes font substitution that TextEdit.app does.
If you open TextEdit.app, change the keyboard to "Big5", select the Format -> Font -> Show Fonts menu item, select "Song" in the Font window, and then, while the "Fonts" window is open, type the "~" key twice, you will see that TextEdit.app automatically changes the font in the "Fonts" window to "Hiragino Kaku Gothic Pro W3".
Apparently, when a character cannot be displayed by a font, TextEdit will automatically change the font to the first font that it can find that can display the character.
This is why NeoJ did not seem to work. NeoJ will try to display a character in your chosen font and, if the font cannot display the character. NeoJ (and the OOo code that it is based on) does not try to change the font but will only display a square.
I verified that only a few standard Mac OS X fonts (at least on Jaguar) can display the 0x223C key (my test Unicode key) and here is the list:
Apple LiGothic
Apple LiSung
BiauKai
Hiragino Kaku Gothic Pro
Hiragino Kaku Gothic Std
Hiragino Mincho Pro
LastResort
Symbol
Taipei
If you use any of these fonts, then you should have better results.
My problem is I can't input that unicode character into NeoOffice/J by OSX 10.3.2's Traditonal Chinese Input Method (TCIM) while TCIM support that characters.
The Font I use is DFMingLight-UN form DynaFont, but the result is same when I try all the fonts you listed. The TCIM just don't sent the character into NeoOffice's doc. You can try to type "gylh" (Unicode character 57D7) by TCIM-Cangjie, and see what happen.
Well a picture is better than million of word. You can see a screen capture in
PS. I find out that the TCIM can't input the unicode character, but the character Palette can insert the same character into NeoOffice/J. And when using NeoOffice/J, the Unicode Hex Input is greyed, so I can't use the UHI to into unicode character too!?
Thanks for the detailed example. I am able to replicate your problem on my Panther machine.
I found where the the problem is occurring. The problem is that the TCIM is incompatible with Java 1.3.1's "passive" input method handler. The "passive" input method handler is that one-line window that appears when you type Asian characters in NeoJ. Java 1.3.1 creates this window and, when it works properly, will resolve the input keystrokes. One the input keystrokes are resolved into a valid character, the "passive" input method handler will send a single "key typed" event to NeoJ. The problem is that, when the TCIM is used, the "passive" input method handler never sends the "key typed" event to NeoJ.
Although this is a bug in the TCIM (many new things in Panther do not work in Java 1.3.1 presumably because Apple doesn't bother to test Java 1.3.1 anymore), I have found a solution to the problem.
The solution is that I need to use Java 1.3.1's "active" input method handler. The "active" input method handler does not display the one-line input window. Instead, it sends events as you type them and the application (i.e. NeoJ) is supposed to resolve them into valid characters.
In other words, the solution is to implement "on-the-spot" editing. I looked at the OOo code and it appears that "on-the-spot" editing is supported in their Windows version. So, I am going to try to connect Java 1.3.1's "active" input method handler to OOo's "on-the-spot" editing code.
I have successfully implemented "on-the-spot" input for all languages. The good news is that with my new "on-the-spot" input, the TCIM input method now works properly.
Watch the NeoOffice/J Testing forum. I will post a test patch in that forum in the new few days.
All times are GMT - 7 Hours Goto page Previous1, 2
Page 2 of 2
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum You cannot attach files in this forum You cannot download files in this forum