Handling international characters

I’m having some difficulties using the unicode field in the keyboard
event.

When the unicode character is <= 128, there’s no problem - I cast to
char and everything works.

When the unicode character is > 128, I convert the unicode value (which
I assume to be in UCS-4) to UTF8, using as many bytes as needed, and
everything works. For example, when I press the ‘?’ (“LATIN SMALL LETTER
N WITH TILDE”) key in my keyboard (it’s a spanish keyboard), I get
unicode 0x1F, which I convert to 0xC3 0xB1, and SDL_TTF renders it
correctly (I use RenderUTF8)

However, to type the ‘?’ symbol (“LATIN SMALL LETTER A WITH ACUTE”), I
must press the ’ (“ACUTE ACCENT”) key and then the ‘a’ (regular A) key.
But in this case I get two key press events, one for TILDE, one for A,
instead of just one with the AACUTE.

How should this situation be handled? How do you implement international
keyboard input?

Thanks,
–Gabriel

Hi Gabriel,On 03/06/2005, Gabriel, you wrote:

When the unicode character is > 128, I convert the unicode value
(which I assume to be in UCS-4) to UTF8

However, to type the ‘?’ symbol (“LATIN SMALL LETTER A WITH ACUTE”), I
must press the ’ (“ACUTE ACCENT”) key and then the ‘a’ (regular A)
key. But in this case I get two key press events, one for TILDE, one
for A, instead of just one with the AACUTE.

I’m just using the event.key.keysym.unicode field if it is < 256, on
each SDL_KEYDOWN event. It works fine for chars that need “dead” keys
(pressing first ? then a, for example). However the < 256 test might be
a problem for some languages, I guess… I’m just handling ISO-8859-1,
nothing more.


Please remove “.ARGL.invalid” from my email when replying.
Incoming HTML mails are automatically deleted.

When you use “dead” keys, or “compose” keys to enter letters that don’t
appear directly on the keyboard in your ordinary applications, some
part of your operating environment is responsible for detecting
modifier keys and deciding what the resultant character is. Take even
the Shift key for example. Your operating environment takes that into
account when deciding what character(s) you intended to type. SDL
doesn’t automatically handle the Shift key, nor Caps lock, nor compose
keys, because SDL is for games, and we get a direct, low level
interface to the keyboard. It would be a nice project to create a small
library to take responsibility for this task.On Jun 3, 2005, at 1:09 PM, Gabriel wrote:

I’m having some difficulties using the unicode field in the keyboard
event.

When the unicode character is <= 128, there’s no problem - I cast to
char and everything works.

When the unicode character is > 128, I convert the unicode value (which
I assume to be in UCS-4) to UTF8, using as many bytes as needed, and
everything works. For example, when I press the ‘?’ (“LATIN SMALL
LETTER
N WITH TILDE”) key in my keyboard (it’s a spanish keyboard), I get
unicode 0x1F, which I convert to 0xC3 0xB1, and SDL_TTF renders it
correctly (I use RenderUTF8)

However, to type the ‘?’ symbol (“LATIN SMALL LETTER A WITH ACUTE”), I
must press the ’ (“ACUTE ACCENT”) key and then the ‘a’ (regular A) key.
But in this case I get two key press events, one for TILDE, one for A,
instead of just one with the AACUTE.

How should this situation be handled? How do you implement
international
keyboard input?

Thanks,
–Gabriel


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

El s?b, 11-06-2005 a las 18:54 -0400, Donny Viszneki escribi?:

SDL doesn’t automatically handle the Shift key, nor Caps lock, nor compose
keys, because SDL is for games, and we get a direct, low level
interface to the keyboard. It would be a nice project to create a small
library to take responsibility for this task.

I do use SDL for making games - and sometimes games need text input, to
ask for the player’s name, for example (it’s exactly our case).

I could [try to] implement this myself, at least in Windows, Linux and
Mac. The main question is, how should it work? Adding a new event type
is probably out of the question.

I think dead keys should generate SDL_KEYPRESSED and SDL_KEYRELEASED
with 0 as the Unicode value (so you know they’re dead keys) and the
composite keys should have the composed value in Unicode. If you want to
do game-style input you should use the SDLK_ constants anyway, so
Unicode == 0 shouldn’t matter; and if you’re doing character input, this
is how you’d like it to work.

Comments? Suggestions?

--Gabriel

El s?b, 11-06-2005 a las 18:54 -0400, Donny Viszneki escribi?:

SDL doesn’t automatically handle the Shift key, nor Caps lock, nor
compose
keys, because SDL is for games, and we get a direct, low level
interface to the keyboard. It would be a nice project to create a
small
library to take responsibility for this task.

I do use SDL for making games - and sometimes games need text input, to
ask for the player’s name, for example (it’s exactly our case).

I wasn’t trying to suggest that games don’t require text input. I did
however fail to mention that the secondary complication involved in
creating cross-platform internationalized key composition is that
different operating environments have very different configurations.
For instance on Mac OS X, one pressed Option + N to compose the ?
accent mark, and if the next letter I hit can have that accent applied,
then that is the character typed. Certainly this is different from
windows, which is in turn different from typical X configurations (as I
understand it the tilde key is involved in composing that particular
character in many default compose key configurations for X.)

I could [try to] implement this myself, at least in Windows, Linux and
Mac. The main question is, how should it work? Adding a new event type
is probably out of the question.

I think dead keys should generate SDL_KEYPRESSED and SDL_KEYRELEASED
with 0 as the Unicode value (so you know they’re dead keys) and the
composite keys should have the composed value in Unicode. If you want
to
do game-style input you should use the SDLK_ constants anyway, so
Unicode == 0 shouldn’t matter; and if you’re doing character input,
this
is how you’d like it to work.

Comments? Suggestions?

Gladly. What you should do is create a function that accepts an
SDL_Event, and returns a unicode character, or NULL if a unicode
character is not resultant of the event it has accepted. Applications
can, when accepting text input, run all events through this function,
and if it returns NULL, it can handle the event itself. This is a very
common design strategy for any functionality meant to augment the event
processing loop. (Look at SDL_console for example, which in fact could
perhaps benefit from a function such as the one I am describing, heh.)

A second thing to consider is the current operating platform. On X the
application could try to figure out the user’s compose-key
configuration. There may be a problem if different keyboard layouts on
Mac OS X use different compositions. Hmm I can probably try that right
now by changing my keyboard layout, just gimme a second here… zell
this is the french keyboqrd lqyout: the auick brozn fox ju,ped over the
lqwy dog: noz ti,e for qccents: ? ?o ? ? ?? ?? e: Ok yes on the French
keyboard layout, when I pressed Option + E, instead of creating an
acute accent and waiting on the next input to see which letter I will
apply, Mac OS X inserted an “?.”

An alternative to trying to decipher the keyboard layout, and then
emulate that operating environment’s compose-key system, it’s possible
that these platforms have provided ways to receive keyboard key presses
as a result of the user entering a compose-key.

Anyhow I don’t think I said anything all that ground-breaking here, I’d
be surprised if you couldn’t have figured all this out yourself. But if
anyone knows anything about that last part please share.On Jun 11, 2005, at 11:02 PM, Gabriel wrote:

Keep in mind that it is almost impossible to get the unicode value
from an SDL event (see also the often cited game pad comparison).

SDL does already use system dependent functions to create its unicode values.
On X11 for example, SDL uses the XLookupString function to get unicode values.

Unfortunately, X11R6 puts the burden of handling dead keys on X clients,
i.e. XLookupString returns unicode values even for dead keys.

IMHO, the correct way is to implement support for the
input method protocol.

Regards,
Johannes

< http://libufo.sourceforge.net > The OpenGL GUI ToolkitOn Sunday 12 June 2005 09:07, Donny Viszneki wrote:

I think dead keys should generate SDL_KEYPRESSED and SDL_KEYRELEASED
with 0 as the Unicode value (so you know they’re dead keys) and the
composite keys should have the composed value in Unicode. If you want
to
do game-style input you should use the SDLK_ constants anyway, so
Unicode == 0 shouldn’t matter; and if you’re doing character input,
this
is how you’d like it to work.

Comments? Suggestions?

Gladly. What you should do is create a function that accepts an
SDL_Event, and returns a unicode character, or NULL if a unicode
character is not resultant of the event it has accepted. Applications
can, when accepting text input, run all events through this function,
and if it returns NULL, it can handle the event itself.

El dom, 12-06-2005 a las 03:07 -0400, Donny Viszneki escribi?:

An alternative to trying to decipher the keyboard layout, and then
emulate that operating environment’s compose-key system, it’s possible
that these platforms have provided ways to receive keyboard key presses
as a result of the user entering a compose-key.

I wasn’t even considering emulating dead keys by hand :slight_smile: In fact every
OS already has that functionality so it’s a matter of finding out how to
integrate it with SDL.

A quick look at the sources shows the DX5 driver calling ToAscii() and
ignoring its result unless it generates exactly 1 byte (it can generate
0, 1 or 2 bytes). The X11 driver calls XLookupString and returns only
the first byte. The Quartz driver looks more correct but I’m not sure it
does the Right Thing. I think it’s a matter of
correcting/enhancing/fixing functionality instead of adding all-new
functionality. That’s a good thing :slight_smile:

Well… I’ll see what can I do and get back to the list.

--Gabriel