Thread: [Tuxpaint-devel] Input Method support added
An award-winning drawing program for children of all ages
Brought to you by:
wkendrick
From: Mark K. K. <mkk...@gm...> - 2007-04-22 04:22:14
|
I probably should have given more warning, but an application-level Input Method support has been added to Tux Paint. There has been requests several times from users to include foreign-language text typing feature to Tux Paint and I think we've been pushing it back quite a bit now, hoping to integrate IMM-SDL with Tux Paint at some point. Then I found a website where someone had already integrated IMM-SDL with Tux Paint but I wasn't very satisfied with the level of application integration. Plus the fact that SDL has to be patched (which will likely not happen given that most SDL apps don't need foreign language input support), I felt an integrated application-level IM support is necessary. I just doodled with some coding at first but it became pretty obvious that this was quite doable. So a framework has been added to translate SDL Keysym sequences to the language under which Tux Paint is running (which, I guess, isn't technically an IM but a translator, but "IM" is a much more widely understood lingo.) Two language input methods have been implemented: Korean (Hangul 2-Bul) and Japanese (Romanized Hiragana and Katakana) input methods. The right Alt button can be used to switch between the language modes: Korean: English -> Hangul 2-Bul -> back to English Japanese: English -> Hiragana -> Katakana -> back to English This still needs a bit of refinement but it's in a usable state. Other languages should be fairly easy to implement as well, except perhaps Chinese, which will likely require some enhancements to the current code. Please do test out and see if it's lacking anything. -Mark |
From: Kees J. <kee...@gm...> - 2007-04-23 07:22:22
|
On 4/22/07, Mark K. Kim <mkk...@gm...> wrote: > I probably should have given more warning, but an application-level > Input Method support has been added to Tux Paint. Hello Mark, I am one of the interested and thus happy ones :) > > There has been requests several times from users to include > foreign-language text typing feature to Tux Paint and I think we've been > pushing it back quite a bit now, hoping to integrate IMM-SDL with Tux > Paint at some point. Then I found a website where someone had already > integrated IMM-SDL with Tux Paint but I wasn't very satisfied with the > level of application integration. Plus the fact that SDL has to be > patched (which will likely not happen given that most SDL apps don't > need foreign language input support), I felt an integrated > application-level IM support is necessary. Could you give me /us pointers to imm-sdl and the original port? greetings |
From: Mark K. K. <mkk...@gm...> - 2007-04-24 03:11:34
|
On Mon, Apr 23, 2007 at 09:22:22AM +0200, Kees Jongenburger wrote: > Could you give me /us pointers to imm-sdl and the original port? The SDL-imm port of Tux Paint is here: http://kldp.org/files/tuxpaint-0.9.15b+SDL_im-1.2.9-20060329.zip Sourcecode diff: http://kldp.org/files/tuxpaint-0.9.15b+SDL_im-1.2.9-20060329.diff.txt However, it is strictly made for Korean input so I am not sure if it works with other languages. Note that this is not the code I wrote. The code I wrote is integrated into Tux Paint so it creates a more natural environment for the user. It has its pluses and minuses comapred to using SDL-imm, already pointed out (though only briefly) in my previous post. -Mark |
From: Alessandro P. <apa...@gm...> - 2007-04-23 07:52:50
|
2007/4/23, Kees Jongenburger <kee...@gm...>: > > On 4/22/07, Mark K. Kim <mkk...@gm...> wrote: > > I probably should have given more warning, but an application-level > > Input Method support has been added to Tux Paint. > Hello Mark, > > I am one of the interested and thus happy ones :) > > > > > There has been requests several times from users to include > > foreign-language text typing feature to Tux Paint and I think we've been > > pushing it back quite a bit now, hoping to integrate IMM-SDL with Tux > > Paint at some point. Then I found a website where someone had already > > integrated IMM-SDL with Tux Paint but I wasn't very satisfied with the > > level of application integration. Plus the fact that SDL has to be > > patched (which will likely not happen given that most SDL apps don't > > need foreign language input support), I felt an integrated > > application-level IM support is necessary. > Could you give me /us pointers to imm-sdl and the original port? > > Is this related with an on screen keyboard? This could be a nice feature for internet tablets users (N800, N770). -- Alessandro Pasotti w3: www.itopen.it |
From: Bill K. <nb...@so...> - 2007-04-23 16:53:21
|
On Mon, Apr 23, 2007 at 09:52:38AM +0200, Alessandro Pasotti wrote: > Is this related with an on screen keyboard? > No, this provides an input method using the existing physical keyboard. (See my last post's "ro" example :) ) -bill! |
From: Bill K. <nb...@so...> - 2007-04-23 16:52:38
|
On Sat, Apr 21, 2007 at 09:22:12PM -0700, Mark K. Kim wrote: > I probably should have given more warning, but an application-level > Input Method support has been added to Tux Paint. Mark, nice work, thanks! I tested it out a little in Japanese ([r][o] first shows an "r", then switches to, presuambly, the 'ro' character :) I wonder, would you be willing to document this feature in Tux Paint's README.html documenation file? Also, it would be good to add a section to the website's "Help Us" pages that discusses how volunteers can create new ".im" files for other languages. If you could direct me to some page that explains them, I could try to put something together (or you could email me some text, HTML, or just commit to the 'tuxpaint-website' repository in CVS). Thanks a ton! Looking forward to hearing how this works for others! -bill! |
From: Bill K. <nb...@so...> - 2007-04-25 17:40:43
|
On Mon, Apr 23, 2007 at 09:52:36AM -0700, Bill Kendrick wrote: > I wonder, would you be willing to document this feature in Tux Paint's > README.html documenation file? I've added some info, under the "Text" tool, and listed the supported languages there. I also added "(+)" next to the languages where right-[Alt] switches IM, to the OPTIONS documentation. > Also, it would be good to add a section to the website's "Help Us" pages > that discusses how volunteers can create new ".im" files for other > languages. If you could direct me to some page that explains them, I > could try to put something together (or you could email me some text, > HTML, or just commit to the 'tuxpaint-website' repository in CVS). Still need to do this. I'll poke around the im.c file for it, I guess, if I have time. Thx! -- -bill! bi...@ne... http://www.newbreedsoftware.com/ |
From: <tor...@at...> - 2007-04-29 08:08:20
|
I use Win2K Norwegian version, and tested the new 0.9.17 2007-04-28 Windows-version from John. I have Norwegian, Russian and English keyboard setup in Windows, using alt-shift to change between them. It still works in TuxPaint 0.9.17. A note about fonts though. With Norwegian language chosen, I get these fonts: (N=Norwegian letters, R=Russian letters, .=works, n=doesn't work) N R Fontname . . FreeMono (Medium) . . FreeSans (Medium) . . FreeSerif (Medium) . . DejaVu Sans (Condensed) . n Garuda (Bold) . n ae_Nice (Regular) n n TSCu_Comic (Normal) . . Thryomanes (Regular) . n TuxPaint Georgian (Regular) . n Verajja (Regular) . . Sazanami Gothic (Gothic-Regular) As you can see, TSCu_Comic doesn't have the Norwegian letters, and Garuda, ae_Nice, TSCu_Comic, TuxPaint Georgian and Verajja doesn't have the Russian alphabet (Cyrillic). When I choose Russian as language in TuxPaint, I get three fonts extra: N R Fontname n n SubsetForTuxPaint (Regular) n n Nachlieli (Light) n n Tsampa Keyboard (Regular) (not english either) None of them support either Norwegian or Russian, and the last one doesn't even have the english letters. So if I use Russian as language, I get 14 fonts where 8 fonts just give me boxes or blanks when typing Russian letters. They show that way in the buttons as well, so it's easy to see which fonts will work, but still not very userfriendly. Would it be easy to set up a list of which fonts to load (for instance in the locale directories), maybe even with some way to add certain system fonts? Choosing system fonts in the config-program makes the font selection more difficult since it adds so many fonts that you must scroll, and many of the fonts look almost the same anyway. Kind regards, Tore ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. |
From: Mark K. K. <mkk...@gm...> - 2007-04-30 02:47:52
|
On Sat, Apr 28, 2007 at 04:05:36AM +0100, John Popplewell wrote: > On Fri, Apr 27, 2007 at 09:41:16AM -0700, Bill Kendrick wrote: > > John P. -- have you got a moment to throw together a beta EXE based on > > what's in CVS, so people can play with Mark's new IM feature? > > I've put together a complete zip archive here: Thanks, John! I discovered a couple bugs during testing. It appears the Windows Korean IME grabs the Right-Alt event and not letting Tux Paint switch into the Hangul mode. I think I'll make Left-Alt switch to Hangul mode also, so Left-Alt can be used when Windows won't pass Right-Alt events. Also, a certain key sequence is crashing Tux Paint in Korean language mode. I'll need to fix that. Something I realized is that the path loading of *.im files is hard-coded at compile-time, which doesn't work very well for Windows programs that needs to be able to run from any drive/path (C:\Program Files\ can be moved.) Yet *.im files are loading fine at runtime, regardless of where it's run from. Is this intentional, and how does this work? If not, why does it work?! =P Thank you again, John! -Mark |
From: Mark K. K. <mkk...@gm...> - 2007-04-30 02:55:07
|
On Sun, Apr 29, 2007 at 10:08:16AM +0200, Tore Jorgensen wrote: > Would it be easy to set up a list of which fonts to load (for instance > in the locale directories), maybe even with some way to add certain > system fonts? Choosing system fonts in the config-program makes the > font selection more difficult since it adds so many fonts that you > must scroll, and many of the fonts look almost the same anyway. That's partially controlled in the *.po files. The "Aa", "qx", "QX", etc. strings test the fonts to see which fonts should be loaded in which order, so that the fonts that are best for the language in use are loaded first. You should modify those strings in the Norwegian/Russian .po file in a way so that the fonts that are most friendly to the Norwegian/Russian show up first. This never has been an issue for Korean since Korean never could be typed in the first place, but now I gotta figure out a way to make this work for Korean, too. =) |
From: John P. <jo...@jo...> - 2007-04-30 12:02:56
|
On Sun, Apr 29, 2007 at 07:47:51PM -0700, Mark K. Kim wrote: > On Sat, Apr 28, 2007 at 04:05:36AM +0100, John Popplewell wrote: > > On Fri, Apr 27, 2007 at 09:41:16AM -0700, Bill Kendrick wrote: > > > John P. -- have you got a moment to throw together a beta EXE based on > > > what's in CVS, so people can play with Mark's new IM feature? > > > > I've put together a complete zip archive here: > > Thanks, John! :-) > I discovered a couple bugs during testing. It appears the Windows > Korean IME grabs the Right-Alt event and not letting Tux Paint switch > into the Hangul mode. I think I'll make Left-Alt switch to Hangul mode > also, so Left-Alt can be used when Windows won't pass Right-Alt events. OK, sounds good. > Also, a certain key sequence is crashing Tux Paint in Korean language > mode. I'll need to fix that. Ah, OK. > Something I realized is that the path loading of *.im files is > hard-coded at compile-time, which doesn't work very well for Windows > programs that needs to be able to run from any drive/path > (C:\Program Files\ can be moved.) Yet *.im files are loading fine at > runtime, regardless of where it's run from. Is this intentional, and > how does this work? If not, why does it work?! =P I have to confess I didn't look at your changes very closely - it seemed to be working so I shipped it! I took a proper look at the code and see that you use IMDIR as a prefix in the C source. Makefile sets it to "im/" when building the redistributable version (bdist-win32). This is the same way that the DATA_PREFIX, DOC_PREFIX and LOCALE_PREFIX work. Looks like you just copied and tweaked the existing Makefile stuff, regards, John. |
From: Mark K. K. <mkk...@gm...> - 2007-05-01 01:59:21
|
On Mon, Apr 30, 2007 at 01:02:55PM +0100, John Popplewell wrote: > I took a proper look at the code and see that you use IMDIR as a prefix > in the C source. Makefile sets it to "im/" when building the > redistributable version (bdist-win32). This is the same way that the > DATA_PREFIX, DOC_PREFIX and LOCALE_PREFIX work. > > Looks like you just copied and tweaked the existing Makefile stuff, Ah ha! Thus proves copy & paste often yields code that is not understood by the programmer. Q.E.D. >.< Thanks, John! -Mark |
From: Bill K. <nb...@so...> - 2007-05-03 06:32:53
|
On Sun, Apr 29, 2007 at 07:47:51PM -0700, Mark K. Kim wrote: > Also, a certain key sequence is crashing Tux Paint in Korean language > mode. I'll need to fix that. FYI, it looks like your fix for that causes a crash when Tux Paint is run in a locale that there's no specific IM support for (e.g., crashes when I run 'tuxpaint'; works fine when I run 'tuxpaint --lang japanese'). Undoing this (in im_read()) fixed it: IM_EVENT_FN* im_event_fp = NULL; // added * ... im_event_fp = &im_event_fns[im->lang]; // added & Investigating... -bill! |
From: Mark K. K. <mkk...@gm...> - 2007-04-27 00:36:26
|
On Thu, Apr 26, 2007 at 01:21:39PM -0700, Bill Kendrick wrote: > On Thu, Apr 26, 2007 at 03:33:06PM +0200, "Tore B. Jørgensen" wrote: > > Just a quick question. Do we need to make im-files for European > > languages as well, or is this just a topic for multiple byte letters? I > > use Norwegian, which work fine today, so I wonder if that's something > > that will break in the next release unless somebody make a im-file for > > Norwegian. > > I tested entering an ? (e?e in Spanish, an N with a tilde, > aka "ñ" in HTML) and it worked fine, even after Mark's IM update > for Japanese and Korean. Yes, it's supposed to be backwards compatible with the existing code. More specifically, the IM code will default to the im_event_c() event handler if there is no language-specific event handler, which will mimic the previous method of inputting characters. But please do test this if you can, to make sure this does indeed work as intended. It's all good in theory but one can never be too sure! -Mark |
From: Mark K. K. <mkk...@gm...> - 2007-04-24 03:23:58
|
On Mon, Apr 23, 2007 at 09:52:36AM -0700, Bill Kendrick wrote: > On Sat, Apr 21, 2007 at 09:22:12PM -0700, Mark K. Kim wrote: > > I probably should have given more warning, but an application-level > > Input Method support has been added to Tux Paint. > > Mark, nice work, thanks! I tested it out a little in Japanese > ([r][o] first shows an "r", then switches to, presuambly, the 'ro' character :) > > I wonder, would you be willing to document this feature in Tux Paint's > README.html documenation file? Thanks, Bill. I'll see if I can update README.txt when I get a chance. > Also, it would be good to add a section to the website's "Help Us" pages > that discusses how volunteers can create new ".im" files for other > languages. If you could direct me to some page that explains them, I > could try to put something together (or you could email me some text, > HTML, or just commit to the 'tuxpaint-website' repository in CVS). Unfortunately it's not as easy as creating just the .im files, but also requires additional code as well for each language (should be fairly minimal for most languages.) im.c has some information on that but let me put something together for the website also. -Mark |
From: Bill K. <nb...@so...> - 2007-04-24 07:16:11
|
On Mon, Apr 23, 2007 at 08:23:58PM -0700, Mark K. Kim wrote: > > Thanks, Bill. I'll see if I can update README.txt when I get a chance. Please updated README.html. README.txt is generated (by me, via a call to "links") from that file. If you'd be so kind... :^) <snip> > Unfortunately it's not as easy as creating just the .im files, but also > requires additional code as well for each language (should be fairly > minimal for most languages.) Ditto for adding new locales... I (or someone) needs to update the Makefile and i18n.c and .h. > im.c has some information on that but let > me put something together for the website also. Ok, thanks! -- -bill! bi...@ne... http://www.newbreedsoftware.com/ |
From: TOYAMA Shin-i. <sh...@wm...> - 2007-04-24 05:30:29
|
Hi! I compiled current CVS version on Windows XP and tested to input japanese. It is great work, Mark, thank you! By the way, We Japanese usually input many kind of sequence of two characters using three alphabets, like 304D:3083 kya - 3063:305F tta - Can you extend current feature to enable inputting two or more characters in one sequential alphabets? -- TOYAMA Shin-ichi mailto:sh...@wm... |
From: Mark K. K. <mkk...@gm...> - 2007-04-25 04:18:15
|
On Tue, Apr 24, 2007 at 02:30:31PM +0900, TOYAMA Shin-ichi wrote: > I compiled current CVS version on Windows XP and tested to input > japanese. It is great work, Mark, thank you! Awesome! I think some more key mapping need to be added or tweaked - please make adjustments as needed to ja.im and/or the source. > By the way, We Japanese usually input many kind of sequence of > two characters using three alphabets, like > > 304D:3083 kya - > 3063:305F tta - > > Can you extend current feature to enable inputting two or more > characters in one sequential alphabets? Ah! I didn't realize this (my friends never showed that to me when I was learning to use the keyboard in Japan!) I've been thinking about two-character sequences because some Unicode characters require two 16-bit character sequences to represent a single character (I think Chinese will need this). This is simple enough but extending it to multi-character sequences is an interesting idea. I'll look into it. Thanks!! -Mark |
From: Mark K. K. <mkk...@gm...> - 2007-04-26 04:36:24
|
On Wed, Apr 25, 2007 at 10:40:39AM -0700, Bill Kendrick wrote: > On Mon, Apr 23, 2007 at 09:52:36AM -0700, Bill Kendrick wrote: > > I wonder, would you be willing to document this feature in Tux Paint's > > README.html documenation file? > > I've added some info, under the "Text" tool, and listed the supported > languages there. Thanks, Bill! > I also added "(+)" next to the languages where right-[Alt] switches IM, > to the OPTIONS documentation. FYI, I've used Right-Alt because that's the key that switches modes when typing Korean on the American keyboard, but Korean keyboards have a dedicated "Korean/English" button. Simialr is true for Japanese keyboards. I'd like to find out the SDL codes for these buttons and allow those keys to change the modes also, but I don't have any Korean or Japanese keyboards to test with. > > Also, it would be good to add a section to the website's "Help Us" pages > > that discusses how volunteers can create new ".im" files for other > > languages. If you could direct me to some page that explains them, I > > could try to put something together (or you could email me some text, > > HTML, or just commit to the 'tuxpaint-website' repository in CVS). > > Still need to do this. I'll poke around the im.c file for it, I guess, > if I have time. A brief explanation is that *.im files contain different key strokes that generate the unicode. I call this "character mapping". Each *.im file can have multiple character mapping sections for different character mapping modes. For example, on a Japanese typing system, typing "ka" in Hiragana mode generates a different Unicode character than typing "ka" in Katakana mode. The *.im file format is as follows: <unicode_in_hex_1> <key_sequence_1> <flag_1> <unicode_in_hex_2> <key_sequence_2> <flag_2> <unicode_in_hex_3> <key_sequence_3> <flag_3> <unicode_in_hex_4> <key_sequence_4> <flag_4> ... section <unicode_in_hex_A> <key_sequence_A> <flag_A> <unicode_in_hex_B> <key_sequence_B> <flag_B> <unicode_in_hex_C> <key_sequence_C> <flag_C> <unicode_in_hex_D> <key_sequence_D> <flag_D> The word "section" breaks up the different character mapping sections. The first section is in section 0 by default, the next in section 1, etc. A maximum of 8 is allowed for the moment, but it's a simple constant change in im.c if more is needed. <unicode_in_hex> is a 16-bit hexadecimal number without the "0x". <key_sequence> is the sequence of characters on the user's keyboard that will generate the <unicode_in_hex>. <flag> is a flag that can be used by the C code to customize the behavior of the code. If there is no flag, you still have to add something as a placeholder, so "-" was chosen to represent a placeholder flag. Speaking of which, some C code needs to be added to im.c to handle these *.im files. Most languages will want to load the *.im file, look up a chracter sequence whenever a key is pressed, and return the corresponding unicode. The Japanese IM handler, for example, loads ja.im, looks up the corresponding unicode whenever a key is presed then returns the correpsonding unicode, unless Right-Alt is pressed in which case the character mapping section switches to the next. The Korean IM handler goes a bit further and checks state flags to handle certain key sequences uniquely. Oh, and... the *.im file may also have comments preceded by the # symbol. Okay, so that's not very brief but it's not that comprehensive either. Pleaset let me know if there's a gap in any explanation or if it just flat out doesn't make sense. Thanks, Bill! -Mark |
From: <tor...@at...> - 2007-04-26 13:47:15
|
Just a quick question. Do we need to make im-files for European languages as well, or is this just a topic for multiple byte letters? I use Norwegian, which work fine today, so I wonder if that's something that will break in the next release unless somebody make a im-file for Norwegian. Kind regards, Tore |
From: Bill K. <nb...@so...> - 2007-04-26 20:21:40
|
On Thu, Apr 26, 2007 at 03:33:06PM +0200, "Tore B. Jørgensen" wrote: > Just a quick question. Do we need to make im-files for European > languages as well, or is this just a topic for multiple byte letters? I > use Norwegian, which work fine today, so I wonder if that's something > that will break in the next release unless somebody make a im-file for > Norwegian. I tested entering an ñ (eñe in Spanish, an N with a tilde, aka "ñ" in HTML) and it worked fine, even after Mark's IM update for Japanese and Korean. (I did this by telling KDE to change my keyboard mapping from US English to Spanish, and then hitting the [;] key, for what it's worth.) -- -bill! bi...@ne... http://www.newbreedsoftware.com/ |
From: John P. <jo...@jo...> - 2007-04-30 12:17:35
|
On Sun, Apr 29, 2007 at 09:16:26PM -0700, Mark K. Kim wrote: > On Sun, Apr 29, 2007 at 07:55:07PM -0700, Mark K. Kim wrote: > > On Sun, Apr 29, 2007 at 10:08:16AM +0200, Tore Jorgensen wrote: > > > > > Would it be easy to set up a list of which fonts to load (for instance > > > in the locale directories), maybe even with some way to add certain > > > system fonts? Choosing system fonts in the config-program makes the > > > font selection more difficult since it adds so many fonts that you > > > must scroll, and many of the fonts look almost the same anyway. > > > > That's partially controlled in the *.po files. > [snip] > > Ah... I located an interesting bug. The *.po files are not loaded when > testing the fonts for best suitableness because gettext is not setup > when the fonts testing is done... thus gettext uses the original text, > not the text from *.po. Mark, This came up in this discussion: http://sourceforge.net/mailarchive/message.php?msg_name=20060214152223.GB18510%40rosa.blake but never got fixed. It required parsing the command-line arguments before starting the font-scanner, regards, John. |
From: Mark K. K. <mkk...@gm...> - 2007-05-01 02:11:31
|
On Mon, Apr 30, 2007 at 01:17:24PM +0100, John Popplewell wrote: > This came up in this discussion: > http://sourceforge.net/mailarchive/message.php?msg_name=20060214152223.GB18510%40rosa.blake > > but never got fixed. It required parsing the command-line arguments > before starting the font-scanner, Thank you for digging that up. It seems like there would be a way to keep the overhead to a minimum when parsing the command line arguments. Something similar to getopts() in PERL that pre-parses all the arguments before returning to the main code may be useful. -Mark |
From: Mark K. K. <mkk...@gm...> - 2007-05-06 04:16:01
|
On Thu, May 03, 2007 at 07:42:27PM -0700, Mark K. Kim wrote: > Thank, Bill. I added that code because I thought it's the correct C > syntax. I could be wrong... maybe they should be taken out. It > shouldn't crash, though. I'll look into it this weekend. I was one-off on the dereferences. I counted the stars and it looks good now. -Mark |
From: Bill K. <nb...@so...> - 2007-05-06 13:45:37
|
On Sat, May 05, 2007 at 09:16:02PM -0700, Mark K. Kim wrote: > I was one-off on the dereferences. I counted the stars and it looks > good now. Thanks, Mark! Looks fine now. -- -bill! bi...@ne... http://www.newbreedsoftware.com/ |