Another kind of IMEs, they recognize the shape of Chinese characters.
As most Chinese characters are group by small pieces, we make every key on keyborad stand for one or more single shape. When we type different keys in a specified order, the IME must know what it is.
Eg. “碧” is group by “王”, “白” and “石”, someone just need to type GRDF then he has “碧”.(Don‘t ask why GRDF…You won’t want to learn the rules, it is not easier than you learn Chinese)
This is really interesting, 谢谢.
It should not be a problem to support this system “pinyin”. Simply have a text field that accepts the string “ni hao” or “nihao” and then make a new string “你好” from that. To improve that, we could make an “intelligent text field” from the normal text field (as soon as another letter combination is entered, we try to match the String and replace it, then in the same text field we can continue to type). The problem is when you have also some similar english words like “night” or “nifty” (contain “ni”) or maybe some english words are exactly the same letters which would be an even bigger problem when mixing those with pinyin words.
The other system “shape system” would be easy too - I just need to know which key stands for what and then lookup in the Unihan.txt or similar data source. The UCD (or more specifially the Unihan database) has some dictionary information that I can parse and put into the new BitmapFont2 system.
By the way … just yesterday I looked over some Unicode documents for Chinese and it seems that they also have some new symbols each year. I also know some things about Korean and Japanese writing systems (have used the “Batang” and “Hanazono” Fonts before - Batang is Hangul and Hanazono is Japanese and Chinese consisting of two files because there are so many characters that they don’t fit into one true type font file).
Also it seems that Chinese character fonts are a little different depending on “style” - e.g. how you draw the characters in Chinese and how you draw the characters in Japanese. My question: Can you still understand characters that are in Japanese style?
I hope that I can provide something useful in the future. I’m currently working on better Unicode support in the new BitmapFont2 system.
I think the problem is how to know a user use IME and accpet input from IME.
Yes, my idea is to make a custom IME inside jmonkeyengine.
Since they all seem to be very similar and the rules might always be the same.
That seems like an achievable task and it would use everything as it is (LWJGL etc.).
I have one problem with that though: jME seems only to read English keyboard layout - for example: I have a German keyboard layout and some keys are different (" Ö Ä Ü " become useless things like " ? ] # " and if I want to press " ? " (question mark) then something other than that is received by jME.
→ I guess the same problem of wrong keyboard layout might become a problem for pinyin too…
I don’t know if and how “nifty gui” deals with keyboard layout.
I’m not yet at the point when I need to implement my own “text field” class.
The custom IME could be made with “nifty gui”, but I would try to make this with “Lemur” first - so that pspeed has no opportunity to take a nap and will be forced to answer questions and update the Lemur code… :chimpanzee_wink:
Problem is that LWJGL handles input near hardware level, not on software level - game developers usually need as fast input response as possible. While IMEs you are talking about are operating on software level.
If it were me - I’d just add possibility to listen to input on software level and switch between hardware/software depending on current needs - player character control goes from near hardware level while typing text into text field turns hardware listeners off and enables software listeners affected by OS and whatever special software you use.
Not sure if it’s possible to achieve this in a such way though.
On the other side @Ogli is talking about making own IME based on data from near hardware level - it will work for sure but requires more time to be invested while potentially giving more flexibility and better visual results.
Yes, you are right. I just think that it’s too difficult to make a IME.
I have read the source code of Nifty-gui and toneg0d-gui, they just accept input from LWJGL, and LWJGL accept input from keyborad, that’s the problem.
As far as I konw, there are two parts of Japanese characters.
(1) Old styles (Chinese characters)
Japanese learn Chinese characters 1600 years ago, but they don’t use them usually now. They call it old styles.
However, Japanese is a spell language, the shape of Japanese characters means nothing but the sound.
When they use old styles, they write in Chinese character but spells different.
eg. 桜 spells さくら, sakura.
(2) Hiragana & Katakana
Japanese language is a spell language. they use 50 charactors to stand for 50 different sounds.
eg. あいうえお sounds [a] [i] [u] [e] [o].
eg. かきくけこ sounds [ka] [ki] [ku] [ke] [ko].
Japanese language learned a lot from west country such as America, Franch, British and so on. Many words in Japanese are just the same words in foreign language. They write hiragana to spell their own words, and write katakana to spell foreign words.
But if you speak Janpanese hiragane and katakana sounds just the same. Feeling like this… JMONKEYENGINE & jmonkeyengine.
When I type Japanese words I need IME too. I type “sakura” and the IME recognize it as “さくら” in hiragane style and “サクラ” in katakana style, or maybe “桜” in old Chinese style. I need to choose which is the right word I need.
Here is description of the biggest news website in Japan:
朝日(asahi)新闻(Shinbun)
朝日新聞デジタルは朝日新聞のニュースサイトです。政治、経済、社会、国際、スポーツ、カルチャー、サイエンスなどの速報ニュースに加え、教育、医療、…
谢谢 again,
those explanations have given me more ideas about this topic than the Wikipedia articles.
I still hope that I will be able to get Asian languages included without having to learn Chinese and Japanese and Korean (CJK). Also, including Arabic and Hebrew and possibly other languages is the goal. It would be nice if jmonkeyengine could provide game makers with the ability to serve games in every language. In some games you can already chat in any language (like Starcraft 2 - it seems to have all CJK characters in the chat - and is very popular in Korea).
But that should not be a problem if you want to make your own pinyin IME.
We get the events somehow for “letter entered into textfield” and we can set the text content of the text field.
The only problem would be that we will need to hack our own IME into jME.
The listenening to a different software would definitely speed things up. I don’t know if and how that could be made too - I’m not very experienced with this particular task.
I know that you can grab the copy-paste data under Windows (I have the Java code for that). And that is currently my only way to insert Chinese into a running jME application.
Supposedly the situation will improve a lot once we switch to LWJGL 3.0 (which uses GLFW under the hood). There’s full support for unicode text input there, not just keyboard input.
That’s a good news. 
Too bad that we will most certainly still need JInput (for joysticks).
Well, there seem to be strong differences between some Asian languages.
And there seem to be minor differences between other Asian languages.
For example: All of these are supposed to represent the same ideograph(次):
→ CJK Unified Ideographs - Wikipedia<—
Here is an interesting text from the Unicode standard:
"
3.7 Variants
Although Unicode encodes characters and not glyphs, the line between the two can sometimes be hard to draw, particularly in East Asia. There, thousands of years worth of writing have produced thousands of pairs which can be used more-or-less interchangeably.
To deal with this situation, the Unicode Standard has adopted a three-dimensional model for determining the relationship between ideographs, and has formal rules for when two forms may be unified. Both are described in some detail in the Unicode Standard. Briefly, however, the three-dimensional model uses the x-axis to represent meaning, and the y-axis to represent abstract shape. The z-axis is used for stylistic variations.
To illustrate, 說 and 貓 have different positions along the x-axis, because they mean two entirely different things (to speak and cat, respectively). 貓 and 猫 mean the same thing and are pronounced the same way but have different abstract shapes, so they have the same position on the x-axis (semantics) but different positions on the y-axis (abstract shape). They are said to be y-variants of one another. On the other hand, 說 and 説 have the same meaning and pronunciation and the same abstract shape, and so have the same positions on both the x- and y-axes but different positions on the z-axis. They are z-variants of one another.
"
That’s really interesting if you would like to learn some Asia history.
Chinese characters are much different from it was thousands years ago, it is a growing language. Many conutry learn it from China at different time from different teacher, so they write it differently, even means different thing.
Howevey, most of them find that Chinese are too high level culture, so they changed it in their own way. This is what Japaniese did.
Hello,
if you have a .fnt file for Chinese, then you could test your input system with this:
jme3test.gui.TestBitmapFont.java
It’s also in the jME SDK’s JME_Tests project and it can recognizes some local (language) key input.
For example, on my keyboard it successfully recognizes Ä Ö Ü and ä ö ü.
It also recognizes modifiers, so if I press key ` and key a, it correctly shows à.
Just type something, press ENTER / RETURN and view the output.
But as I said: You will need a Chinese .fnt (BitmapFont) first.
It could be generated with this free tool: BMFont - AngelCode.com
It’s a Windows programm and the forum is here: http://www.gamedev.net/forum/49-angelcode/
I guess you have a Chinese font (true type font) on your computer, but if not, then you can use the free “Hanazono” font (find via web search) - it’s primarily made for Japanese but includes some extended Chinese Characters too (only Korean is not included).
Hope it helps,
and wish a happy year of the monkey!
EDIT: Note, that the BitmapText of jME currently does not support unicode codepoints consisting of two char variables (some unicode characters are in Java represented by two Java char - this can’t be handled by BitmapText and I’m working on that problem).
where can I find the code to change it?
I need RTL text rendering to show Hebrew texts…
The BitmapText class in jME has a right-to-left mode - just try that. That class is not good though. It is very simplistic and poorly implemented. I’m currently working on my Java-based font code again. But it will not be finished in the near future.