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.
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).
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.
