tuxpaint-devel — General discussion list for Tux Paint developers

Re: [Tuxpaint-devel] Windows beta build to test Input Method support?

[Bill K. <nb...@so...>]

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!

Re: [Tuxpaint-devel] Windows beta build to test Input Method support?

[Mark K. K. <mkk...@gm...>]

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

Re: [Tuxpaint-devel] Windows beta build to test Input Method support?

[Mark K. K. <mkk...@gm...>]

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

Re: [Tuxpaint-devel] Windows beta build to test Input Method support?

[John P. <jo...@jo...>]

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.

Re: [Tuxpaint-devel] Windows beta build to test Input Method support?

[John P. <jo...@jo...>]

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.

Re: [Tuxpaint-devel] Windows beta build to test Input Method support?

[Mark K. K. <mkk...@gm...>]

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.

This may be a simple matter of moving some code around... or it may
break some interdependencies between the setup codes in which case it'll
be a little more involved.  Can someone more familiar with the setup
code take a stab at fixing this?

-Mark

Re: [Tuxpaint-devel] Windows beta build to test Input Method support?

[Mark K. K. <mkk...@gm...>]

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

Re: [Tuxpaint-devel] Windows beta build to test Input Method support?

[Mark K. K. <mkk...@gm...>]

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

Re: [Tuxpaint-devel] Windows beta build to test Input Method support?

[<tor...@at...>]

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.

Re: [Tuxpaint-devel] Windows beta build to test Input Method support?

[John P. <jo...@jo...>]

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:

http://johnnypops.demon.co.uk/files/tuxpaint-0.9.17/tuxpaint-0.9.17cvs-20070428-win32.zip
(8.6M)

It has the new IM stuff (great work!), SVG support, the printcfg bug fix
for Windows (the printer configuration dialog now appears without any
messing about), and I've changed the 'lockfile.dat' location to the
users temporary directory, usually:
'C:\Documents and Settings\<USER NAME>\Local Settings\Temp\'
so that it is independent of the savedir location. This works round a
problem with the lockfile when a shared savedir location is used,

cheers,
John.
PS I've only tested the IM stuff a little, with Japanese.

Re: [Tuxpaint-devel] Input Method support added

[TOYAMA Shin-i. <sh...@wm...>]

>Multi-character sequence support has been added.

Wow! Thank you!

> please add any other multi-character sequences to the ja.im 
> file.  Please let me know of any bugs, etc!

Of course I will, thank you again!

-- 
TOYAMA Shin-ichi

Re: [Tuxpaint-devel] Input Method support added

[Bill K. <nb...@so...>]

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.

BTW, here's a screenshot of it in Japanese:

  http://www.tuxpaint.org/screenshots/showshot.php3?which=18

-bill!

[Tuxpaint-devel] Windows beta build to test Input Method support?

[Bill K. <nb...@so...>]

On Fri, Apr 27, 2007 at 09:40:42AM +0200, "Tore B. Jørgensen" wrote:
> > 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!
> >   
> I use Windows and don't have time to figure out how to compile it, but 
> I'll test it (Norwegian and Russian/Cyrillic) when the compiled beta 
> versions for Windows become available. Based on Bill's test it sounds 
> like it works though.

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?

Thanks!

-- 
-bill!
bi...@ne...
http://www.newbreedsoftware.com/

Re: [Tuxpaint-devel] Input Method support added

[Bill K. <nb...@so...>]

On Thu, Apr 26, 2007 at 06:49:07PM -0700, Mark K. Kim wrote:
> 
> Thank you so much for doing this, Bill!  My comments are in-line:

Got 'em, thanks.

-bill!

Re: [Tuxpaint-devel] Input Method support added

[Bill K. <nb...@so...>]

On Thu, Apr 26, 2007 at 06:37:36PM -0700, Mark K. Kim wrote:
> It already works that way!  =D  You should be able to run Tux Paint in
> Korean or Japanese locale and see the bottom text change when you press
> R-Alt.

Hah!  Whoops, I hadn't even noticed!


> The text itself currently displays the text only in English.  It is
> i18n-abled if I did it correctly, so one should be able to update the
> *.po files and have the texts show up in the active language.

That was going to be my next question.


> I'll need your help fixing that in case it wasn't done properly.
> The Japanese font file distributed with Tux Paint (which contains
> characters only used in Tux Paint) may need to be updated after
> these translations are added... but I guess that's true after any
> translation update.


<snip>
> On the sidenote, I personally wanna see the Klingon IM.  Does Klingon
> have a standard keyboard mapping?

Klingon support in Tux Paint is currently romanized klingon... it doesn't
use a klingon writing system.  (Can't believe I'm having this
conversation :^) )


<snip>
> Which gives a leadway for the Right-Alt key discussion.  The Right-Alt
> key is used for cycling in Korean and Japanese, but only because
> im_event_ko() and im_event_ja() were coded that way.

Ah, got it.


<snip>
> Hew~.  I hope that makes sense.  It's certainly long and confusable if
> not confusing already!  I think I'll need to sit down at some point and
> make a simple tutorial using the Dvorak keyboard.  I think a tutorial
> will make things clearer.

:)

In the meantime, I'll update the docs to note what you've just pointed
out.

Thanks.


-- 
-bill!
bi...@ne...
http://www.newbreedsoftware.com/

Re: [Tuxpaint-devel] Input Method support added

[<tor...@at...>]

Mark K. Kim skrev:
> 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!
>   
I use Windows and don't have time to figure out how to compile it, but 
I'll test it (Norwegian and Russian/Cyrillic) when the compiled beta 
versions for Windows become available. Based on Bill's test it sounds 
like it works though.

Kind regards,
Tore

Re: [Tuxpaint-devel] Input Method support added

[Mark K. K. <mkk...@gm...>]

On Tue, Apr 24, 2007 at 09:18:15PM -0700, Mark K. Kim wrote:
[snip]
> > 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?
> 
[snip]
> Chinese will need this).  This is simple enough but extending it to
> multi-character sequences is an interesting idea.  I'll look into it.

Multi-character sequence support has been added.  I added the above two
character sequences to ja.im, but please add any other multi-character
sequences to the ja.im file.  Please let me know of any bugs, etc!

-Mark

Re: [Tuxpaint-devel] Input Method support added

[Mark K. K. <mkk...@gm...>]

On Thu, Apr 26, 2007 at 04:42:40PM -0700, Bill Kendrick wrote:
> 
> On Thu, Apr 26, 2007 at 04:25:34PM -0700, Bill Kendrick wrote:
[snip]
> > I've documented this briefly in EXTENDING.html / .txt in CVS, thanks!
> 
> And so you don't have to dig, and so you can yell at me if I got any of
> it wrong... :)

Thank you so much for doing this, Bill!  My comments are in-line:

>      As of version 0.9.17, Tux Paint's "Text" tool can provide alternative
>      input methods for some languages. For example, when Tux Paint is running
>      with a Japanese locale, the right [Alt] can be pressed to change between
>      Latin, Romanized Hiragana and Katakana modes. This allows native

Katakana is also Romanized, so the above line should probably be:

  Latin, Romanized Hiragana and Romanized Katakana modes. This allows native
                                ^^^^^^^^^
>      Start each character mapping section with the word "section", the follow

FYI, this is probably not an important point, but if you don't use the
word "section" then the section will default to section 0 (section with
array index of 0).  Subsequent word "section" will increment the array
index, up to index 7 (for now.)  So if you always precede a section with
the word "section", you can only have 7 sections, not 8.

>      Note: Flags must be set up on a per-locale basis (within the source
>      code, in "src/im.c"). For example, "b" is used in Korean to handle
>      Batchim, which may carry over to the next character.

How about:

  Note: Meanings of the flags are locale-specific, and are processed by
  the language-specific source code in "src/im.c".  For example...

>      Note: Additional input method support requires additions to Tux Paint's
                                            ^ also
>      source code (/src/im.c), and requires updates to the Makefile, to have
>      the ".im" files installed, for use at runtime.

This is awesome!  Thank you, Bill!!

-Mark

Re: [Tuxpaint-devel] Input Method support added

[Mark K. K. <mkk...@gm...>]

On Thu, Apr 26, 2007 at 04:44:23PM -0700, Bill Kendrick wrote:

> PS - Would it make sense to have Tux Paint inform the user what mode they're
> in?  (Temporarily change the Tux text at the bottom, for example?)

It already works that way!  =D  You should be able to run Tux Paint in
Korean or Japanese locale and see the bottom text change when you press
R-Alt.

The text itself currently displays the text only in English.  It is
i18n-abled if I did it correctly, so one should be able to update the
*.po files and have the texts show up in the active language.  I'll need
your help fixing that in case it wasn't done properly.  The Japanese
font file distributed with Tux Paint (which contains characters only
used in Tux Paint) may need to be updated after these translations are
added... but I guess that's true after any translation update.

i18n-izing the IM text seems sort of pointless since you're likely going
to need the text "Hangul" translated only in Korean.  However, there are
cases when this is not necessarily true:

  1. Koreans often use Japanese, so the word "Hiragana" and "Katakana"
     should also be translated to Korean.

  2. The word "English" needs to be translated to several languages that
     use the default US keyboard layout in one of the modes.

  3. We can enhance Tux Paint in the future to allow users running Tux
     Paint in one locale to type in another language using a different
     IM handler.

Feature like #3 is going to be useful in non-locale-specific ways also,
if one wants to try out the Dvorak keyboard with their QWERTY keyboards.

On the sidenote, I personally wanna see the Klingon IM.  Does Klingon
have a standard keyboard mapping?

> I didn't read clearly, nor understand, until reading your description of
> how the IM stuff works... I thought right-Alt toggled, but I see now that
> it cycles (between up to 9 modes, right?  Latin, and then up to 8
> locale-specific).

Almost.  Yes, the modes cycle rather than toggle, but only because
im_event_ko() and im_event_ja() were individually coded that way.  They
don't have to cycle (they can require a separate key for each mode,
for example.)  It depends on how im_event_<lang>() function is coded.

Which gives a leadway for the Right-Alt key discussion.  The Right-Alt
key is used for cycling in Korean and Japanese, but only because
im_event_ko() and im_event_ja() were coded that way.  Korean could have
used Left-Alt and Japanese Right-Control; it just so happens Right-Alt
was chosen for both because I felt like it when I was coding
im_event_ko() and im_event_ja().  (It's also the key used in Windows and
Gnome to switch between English/Hangul mode in the absence of a
dedicated English/Hangul key.)

In short, the C code determines all these behaviors.  This is necessary
to give enough flexibility to each IM handler for all the input methods
I don't know about.

As for the maximum number of modes, the *.im file can have up to 8
different sections, including the default section.  I mapped one of
these sections to Latin for im_event_ko() and im_event_ja(), but mapping
Latin is easy enough that it can lie outside of the 8 sections.  This is
determined by the C code so it's flexible.

Hew~.  I hope that makes sense.  It's certainly long and confusable if
not confusing already!  I think I'll need to sit down at some point and
make a simple tutorial using the Dvorak keyboard.  I think a tutorial
will make things clearer.

-Mark

Re: [Tuxpaint-devel] Input Method support added

[Mark K. K. <mkk...@gm...>]

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

Re: [Tuxpaint-devel] Input Method support added

[Bill K. <nb...@so...>]

On Thu, Apr 26, 2007 at 04:25:34PM -0700, Bill Kendrick wrote:
> On Wed, Apr 25, 2007 at 09:36:09PM -0700, Mark K. Kim wrote:
> > A brief explanation is that *.im files contain different key strokes
> > that generate the unicode.  I call this "character mapping".

PS - Would it make sense to have Tux Paint inform the user what mode they're
in?  (Temporarily change the Tux text at the bottom, for example?)

I didn't read clearly, nor understand, until reading your description of
how the IM stuff works... I thought right-Alt toggled, but I see now that
it cycles (between up to 9 modes, right?  Latin, and then up to 8
locale-specific).

-- 
-bill!
bi...@ne...
http://www.newbreedsoftware.com/

Re: [Tuxpaint-devel] Input Method support added

[Bill K. <nb...@so...>]

On Thu, Apr 26, 2007 at 04:25:34PM -0700, Bill Kendrick wrote:
> On Wed, Apr 25, 2007 at 09:36:09PM -0700, Mark K. Kim wrote:
> > A brief explanation is that *.im files contain different key strokes
> > that generate the unicode.  I call this "character mapping".
> 
> I've documented this briefly in EXTENDING.html / .txt in CVS, thanks!

And so you don't have to dig, and so you can yell at me if I got any of
it wrong... :)

===snip===

Alternative Input Methods

     As of version 0.9.17, Tux Paint's "Text" tool can provide alternative
     input methods for some languages. For example, when Tux Paint is running
     with a Japanese locale, the right [Alt] can be pressed to change between
     Latin, Romanized Hiragana and Katakana modes. This allows native
     characters to be entered into the "Text" tool by typing one or more keys
     on a keyboard with Latin characters (e.g., a US QWERTY keyboard).

     To create an input method for a new locale, create a text file with a
     name based on the locale (e.g., "ja" for Japanese), with ".im" as the
     extension (e.g., "ja.im").

     The ".im" file can have multiple character mapping sections for
     different character mapping modes. For example, on a Japanese typing
     system, typing [K] [A] in Hiragana mode generates a different Unicode
     character than typing [K] [A] in Katakana mode.

     Start each character mapping section with the word "section", the follow
     it with the mappings, one per line. Each line should contain (separated
     by whitespace):

       * the Unicode value of the character, in hexadecimal
       * the keycode sequence (the ASCII characters that must be entered to
         generate the Unicode character)
       * a flag (or "-")

     Example:

       # Hiragana
       section
       304B   ka   -
       304C   ga   -
       304D   ki   -
       304E   gi   -

       # Katakana
       section
       30AB   ka   -
       30AC   ga   -
       30AD   ki   -
       30AE   gi   -

     Note: Blank lines within the ".im" file will be ignored, as will any
     text following a "#" (pound/hash) character -- it can be used to denote
     comments, as seen in the example above.

     Note: Flags must be set up on a per-locale basis (within the source
     code, in "src/im.c"). For example, "b" is used in Korean to handle
     Batchim, which may carry over to the next character.

     Note: Additional input method support requires additions to Tux Paint's
     source code (/src/im.c), and requires updates to the Makefile, to have
     the ".im" files installed, for use at runtime.

===snip===

-- 
-bill!
bi...@ne...
http://www.newbreedsoftware.com/

Re: [Tuxpaint-devel] Input Method support added

[Bill K. <nb...@so...>]

On Wed, Apr 25, 2007 at 09:36:09PM -0700, Mark K. Kim wrote:
> A brief explanation is that *.im files contain different key strokes
> that generate the unicode.  I call this "character mapping".

I've documented this briefly in EXTENDING.html / .txt in CVS, thanks!

-- 
-bill!
bi...@ne...
http://www.newbreedsoftware.com/

Re: [Tuxpaint-devel] Input Method support added

[Bill K. <nb...@so...>]

On Wed, Apr 25, 2007 at 09:36:09PM -0700, Mark K. Kim wrote:
> 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.

I fwd'd this question over to the SDL list, FYI.

-bill!

Re: [Tuxpaint-devel] Input Method support added

[Bill K. <nb...@so...>]

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/