MultiByte Language support pack for Irrlicht

Dorth · Post by **Dorth** » Sun Sep 28, 2008 6:30 am

Again, this should really be moved into Irrlicht core...

Virion · Post by **Virion** » Sun Sep 28, 2008 8:36 am

Dorth wrote:Again, this should really be moved into Irrlicht core...

i'll second this.

MadHyde · Post by **MadHyde** » Mon Sep 29, 2008 6:24 pm

I agree.

However, I worry whether to exert a bad influence on users who use only the Latin-1 code by this change.
Please propose a better implementation.

fmx · Post by **fmx** » Tue Sep 30, 2008 8:54 pm

not sure why it isn't already part of the core, perhaps because of the licence/requirements of including the freetype lib with the Irrlicht distro?

I'm not too much of a font-guru myself, but I'll post my thoughts anyway

maybe just create a set of custom font grid "bitmaps" with all the required characters for these languages, then create a simple sort of parser which converts the ascii value to a reference number to render out the characters as image-quads?

I currently use a similar method to render plain Latin texts in my non-irrlicht project, and I was planning to use the same method to add Japanese support

I do realise, however, it might become quite tricky when dealing with lots of text onscreen, changing font size, etc.
ofcourse, there's also the slight issue of these bitmap images bloating the end filesize of the Irrlicht dist, and the need to include them with all irrlicht-compiled programs...

or maybe a new "font-type" plugin system for these additional language characters, with all the neccessary image data precompiled (hardcoded) into additional DLL files, then included if they're needed?
I guess it wouldn't need to be Irrlicht-specific then...

tell me if I'm talking nonsense...

MadHyde · Post by **MadHyde** » Thu Oct 02, 2008 6:35 pm

Thanks fmx.

fmx wrote:maybe just create a set of custom font grid "bitmaps" with all the required characters for these languages, then create a simple sort of parser which converts the ascii value to a reference number to render out the characters as image-quads?

Multibyte languages can be used for original Irrlicht by the Bitmap font, only displays them, isn't it?

In multibyte language support, there are three problems, input, display, and font.
Most difficult problem is the input, then I want the idea how to implement this.

[INPUT]
"problem"
Multibyte character cannot be input, because Irrlicht disregards WM_IME messages.
"implementation candidacy"
* The WM_IME message processing is added to the core by using imm32 lib. (Need to modify the core like IrrlichtML. imm32 will die gradually in future)
* Hijack irr::IrrlichtDevice::run(). (No need to modify the core like IrrIM Test. Imperfection)
* Use Third party window system. WPF, SDL, CEGUI... and the input is left them. (No need to modify the core)
* Use TSF(Text Services Framework) COM API. (No need to modify the core? The mainstream in near future. But, I don't know how to code...

)

Which is best among these candidates? or don't you have other ideas?

[DISPLAY]
"problem"
Multibyte character is garbled in IGUIEditBox and IGUIFileOpenDialog.
"implementation"
It is necessary to convert multibyte char to wide char. (Not need to modify the core?)

[FONT]
"problem"
Bitmap font is inconvenient.
"implementation"
Use IrrTT class. (No need to modify the core)

fmx · Post by **fmx** » Fri Oct 03, 2008 3:05 pm

Like I said, I'm not a font-guru

you're right, using Bitmaps only renders the fonts, it doesn't deal with Input and issues related to Irrlicht's GUI

for INPUT it would probably be best to use either IrrIM test, or TSF.
I don't know much about TSF either but I'll have a look into it and see if its appropriate or how it could be implemented.

I think its about time I contributed back to Irrlicht... been a while since my last endevours (went horribly wrong

)

Can I just ask everyone, what non-Latin languages do you think should be specifically targeted to allow support for in Irrlicht?
I'm personally just trying to get more Japanese support, but I guess Korean and Chinese might also be desirable?

MadHyde · Post by **MadHyde** » Sat Oct 04, 2008 11:59 am

fmx wrote:for INPUT it would probably be best to use either IrrIM test, or TSF.
I don't know much about TSF either but I'll have a look into it and see if its appropriate or how it could be implemented.

OK, I will also research TSF in fuller detail:D

fmx wrote:Can I just ask everyone, what non-Latin languages do you think should be specifically targeted to allow support for in Irrlicht?
I'm personally just trying to get more Japanese support, but I guess Korean and Chinese might also be desirable?

Japanese,Korean,Chinese, and Virion's country Malaysia?

kevincool · Post by **kevincool** » Thu Nov 20, 2008 9:38 am

I don't know why the author didn't add the multi-language function .there are a lot of Chinese programmer give up irrlicht because the multi-luanguage problem.Me,too!

hybrid · Post by **hybrid** » Thu Nov 20, 2008 9:52 am

Well, for now you can use this patch, can't you? Anyway, bye

MadHyde · Post by **MadHyde** » Fri Dec 19, 2008 5:35 pm

Version 1.5 has been released.
http://etwas.wolfish.org/files/Irrlicht ... 2Linux.zip

- Added EditBox's MultiLine and WordWrap switch support.
- Changed sample apps.
- Broke off the DirectX 8 support in precompiled DLL. (I'm using VS2008 and DirectX SDK - August 2008)

also, I submitted garbled CGUIFileOpenDialog fix patch from this code.

NewerCookie · Post by **NewerCookie** » Wed Feb 04, 2009 6:35 pm

Oh, Thanks, MadHyde!
I just display multibyte on the strength of you

venomj · Post by **venomj** » Sat Jul 25, 2009 8:15 am

MadHyde wrote:Version 1.5 has been released.
http://etwas.wolfish.org/files/Irrlicht ... 2Linux.zip

- Added EditBox's MultiLine and WordWrap switch support.
- Changed sample apps.
- Broke off the DirectX 8 support in precompiled DLL. (I'm using VS2008 and DirectX SDK - August 2008)

also, I submitted garbled CGUIFileOpenDialog fix patch from this code.

nice work. i read the code but i couldn't figure out how you draw the candidate list window? Why don't you get the candidate list and render them directly?

venomj · Post by **venomj** » Tue Jul 28, 2009 5:27 am

I modified the code to support rendering the IME candidate string list directly in the GUI. Check the pic below, the candidate string list was rendered on top of the red line.

Only avaliable on Windows.
I tried Chinese, but I think all the eastern languagies (mainly Chinese, Japanese and Korean) are supported.

MadHyde · Post by **MadHyde** » Wed Aug 05, 2009 3:47 am

venomj wrote: nice work. i read the code but i couldn't figure out how you draw the candidate list window? Why don't you get the candidate list and render them directly?

I set only window position. Candidate list window is under the contorol of OS. I'm not doing anything. because that is easy and comfortable.

venomj wrote:I modified the code to support rendering the IME candidate string list directly in the GUI. Check the pic below, the candidate string list was rendered on top of the red line.

Wow, that's great!!

How did you receive IME Messages? I want you to publish the source

venomj · Post by **venomj** » Sat Aug 08, 2009 5:29 am

Candidate list window is under the contorol of OS. I'm not doing anything.

Well, you may have problems displaying the candidate list window in full screen mode.
I process the WM_IME_NOTIFY message in CIrrDeviceWin32 to get the candidate list strings. Then I send an event to the edit to display the strings.
I add a minor improvement to display the composition string before the candidate list. Check pic below.

Tell me your email address, I can send you my code.