TOYAMA Shin-ichi <[EMAIL PROTECTED]> wrote in
news:[EMAIL PROTECTED]:
>> Does this mean we can remove these lines?
>
> Yes. I checked it out using attached sample code with
> Borland's free compiler.
> I think there is no need to set $OUTPUT_CHARSET.
OK. What about the
convert_open() (and convert_close and converts())
lines for some languages?
It looks like this converts from various encodings to UTF-8. Is
this used? I tried removing the functions, and everything worked
as before. But inputting non-ASCII characters in the text tool
didn't work.
'Luckily', inputting non-ASCII characters in the text tool doesn't
work if I keep the lines either! It looks like 'isprint' returns
false for these characters, so nothing is printed (and no 'click'
sound is played). Removing the 'isprint' check, nothing is printed
if 'converts' returns true. So to get non-ASCII characters
printed, both 'isprint' and 'converts' must always return true.
But then the characters that come out are *not* the correct ones!
I've checked the latest Windows test build (a bit old, and built
before all my UTF-8 related changes), and non-ASCII characters
doesn't work there either. Something *is* printed, but not the
correct characters (and the same as on Linux either).
In summary, non-ASCII input in the text tool is totally broken ...
Something worth noting anyway. Code such as this:
else if (language == LANG_HE)
{
putenv("OUTPUT_CHARSET=he_IL");
convert_open("ISO8859-8");
}
will never work correctly (everywhere), as there doesn't exist a
unique mapping from languages to encodings.
And catching characters by checking for key_down sounds dubious,
since creating a character may take several key presses. But
perhaps the SDL libraries handle this correctly anyway?
Well, I have no idea how to solve this. Please, someone who knows
more about keyboard handling and I18N take a look! ;)
--
Karl Ove Hufthammer
_______________________________________________
Tuxpaint-dev mailing list
[EMAIL PROTECTED]
http://tux4kids.net/mailman/listinfo/tuxpaint-dev
