Some old new things about IME and XIM support

SDL Development
1

Hello all guys:

I have already written some mails to slouken at libsdl.org,
but there isn’t any reply to me.
I am afraid that some messages might be missed,
so I post to newsgroup.
That’s my first time to post. Please give me some suggestions.

First, Please forgive my ignorance,
I see the Change Log of SDL1.2.10 showed “The X11 input driver now
uses XIM to handle international input”.
But how to do?
I am a little confused,
because it seems as if there is not any new API or structure in the documents.

Second, Actually, I had done a little patch for SDL1.2.8 for supporting IME in
winodws and XIM in UNIX several years ago.
Here is the site:
http://sdl-im.csie.net/

This patch seems to work fine,
and there are some samples and projects use it well.

Then, I consider some portable conditions,
so I separate the further features into SDL_imm.
You can see the snapshots at http://sdl-im.csie.net/SDL_imm/sdl_imm_snapshot.html.
There are the further features that may be platform dependence.

Although I am not a skillful expert,
I have considered many conditions when using international input.
I hope this works could do some benefit for SDL.

2

The second post I am glad to explain what and why it is.
I will avoid jargon, because I am not a expert. :slight_smile:
And I will assume that the most readers never used IME and XIM before,
and didn’t know any other language except English.

Next, English is not my mother language,
if there are some wrong words or wrong grammar I used that confused you,
please let me know. I will be glad to explain more. :slight_smile:

[The reasons of why SDL should support Input Method(International Input)]

  1. Although many commercial online game, especially MMORPG,
    they will trend to use sending voice to communicate with each other player,
    Many potential customers also don’t have enough speed of internet
    to use this feature.
    Before every people have the highest bandwidth,
    typing to communicate is necessary.

  2. To make some application frameworks based on SDL become more popular.
    It’s clear.
    If there is an application framework that just allows you to type Japanese,
    I guess the people used English as mother language will not use this framework.
    I know SDL’s goal is the cross-platform layer, especially low level features,
    But the people whose mother language is not Latin system,
    they will consider SDL is not enough portable,
    because the native language input support is the basic item of platform input.
    People may not hear music with their computer every day,
    but they may type more often.

[Some fundamental understanding before explaining]

  1. Some language, like Traditional Chinese,
    the most complex language in the world,
    it might have more then fifty thousand words,
    and every word has a unique symbol that can not be spelled with alphabets
    like Latin language,
    so we could not type it just to change keyboard layout.
    Other language, like Chinese, Japanese, Koren,
    also needs IME or XIM to input strings to applications.

  2. In order to type a word, people have to use some rules to composite a word.
    It looks like use alphabets to spell a word,
    but the rules to composite a word are selectable,
    and people can choice their loving rule to composite.
    For me, I have learned two rule systems to type Chinese.

  3. What does IME or XIM looks like?
    For the most situation, when we say IME or XIM,
    we usually mean “IME Client” or “XIM Client”.
    IME or XIM Client is also an application could be installed or removed.
    And Server side is usually in kernel(imm32) or Video server(xlib).
    How to communicate between Server side and Client side is what SDL should do.

The Client looks like a window without title frame,
and it is always on top before the application that rised IME.
People usually type “Ctrl-Shift” or “Ctrl-Space” keys or any other hot keys to
rise IME Client.
For Win32, the full name of IME is “Input Method Editor”,
especially the word “Editor”,
it means you can edit your composition string in the IME window area.
Then, when you finish the composition string,
IME will transform the composition to a word or a string
and send to the depending application.

Please note the last sentence, composition to a string,
it means the application will receive not only a word but also a string.
Actually, the most IME Clients were used for Chinese and Japanese
could send a string to the application.

You could see all the simulated features were drew on SDL_app in win32.
http://sdl-im.csie.net/SDL_imm/sdl_imm_snapshot.html
The last picture to show how it works on Linux is that a part is simulated
and a part is real window.

  1. What encoding is the word or the string that application received?
    UTF8? UCS16? UCS32?
    Actually, it depend on what encoding your environment set.
    In my windows xp, my environment setting is Big5,
    so the string encoding is Big5.
    Big5 is a double-byte encoding used very long time in my country, Taiwan.
    In my Linux, it is set to UTF-8,
    so the string encoding the application received is UTF-8.
    Although the UNICODE is the final standard from now on,
    there were many systems still using old encoding.

In my patch, If setting SDL_EnableUNICODE(1) or SDL_EnableUNICODE(-1)
returns 1(or true),
the argument buffer is the Uint16-type UCS2 string.
If setting SDL_EnableUNICODE(0) or SDL_EnableUNICODE(-1) returns 0(or false),
the argument buffer is the char-type local string
(MBCS, multi-byte characters set)
depends on the local environment,
either DBCS(double-byte characters set) or UTF-8.

There is the sample used Ogre to show a little part of different encoding:
http://sdl-im.csie.net/OGRE_i18n.html
In the 1st picture the XIM window is real window, not simulated.

[What and Why it was]

  1. Why it was a patch? if it is an optional package, will it be better?
    Actually, I also hope it will be a optional package,
    but when I began to work, it was some problems bother me.

First, For Win32 example, Before SDL1.2.8,
SDL couldn’t receive IME event and flip IME window in fullscreen in DirectX,
because IME is a GDI window and use GDI event.
So I have to patch event and drawing processing.

Why flipping IME window in fullscreen is necessary?
It’s a simple reason:
People who may install many IME clients in one platform,
and they must know which one they are using.

If platform can provide further information to let we simulate a IME
in SDL_app window,
That’s great! But if not, how can user know which IME Client they used?

In fact, I can’t find how to get any further information of XIM
in the documents,
XIM don’t seems to provide the function to get further information,
so I just separated the further information from all features into SDL_imm,
( http://sdl-im.csie.net/SDL_imm/index.html )
and be sure that if any other platform can’t provide further information
to simulate,
user also can see the original IME Client Window.

Another interesting thing is, after adding the patch,
the performance of drawing in fullscreen mode is up to more then 200%
in my old laptop!
Maybe it is a specially case, but it’s my real experience
(really, more then 200%!).

How about SDL_inputmethod( http://sdl-im.csie.net/SDL_inputmethod.html )?
It can use IME and XIM without any patch!
SDL_inputmethod uses some “tricks” to hook event loop.
It’s very interesting. :smiley:
But it still has some problems when I used.
First, it hides the IME client window by default,
and not provide further information to simulate a window.
Second, it has strange bugs in win32 that can’t show the IM state
is on or off correctly.
Third, it fails in my Linux. In my laptop, it may crash,
and in another machine, it can’t work.
Honestly, SDL_inputmethod is a little complex to me.

However, the recent version of SDL can flip GDI in fullscreen,
I may find some spare time to research why it can do.
If fullscreen flipping is successful without patching SDL_dx5video.c,
I might consider just patch a little lines in SDL,
and move all the functions into a optional package.

Finally, the other information about SDL_im patch is in http://sdl-im.csie.net/
The APIs are almost stable, but it may be a few modified finally.

Best Regard.

3

courage <dr.courage gmail.com> writes:

However, the recent version of SDL can flip GDI in fullscreen,
I may find some spare time to research why it can do.
If fullscreen flipping is successful without patching SDL_dx5video.c,
I might consider just patch a little lines in SDL,
and move all the functions into a optional package.

Another reason why I prefer to add so many APIs without making a full
features optional package is that Win32 IME uses WM_IME_* switching case to
handle IM behavior.

It means to handle these behavior in an additional package of SDL,
I might add a few relative plugin interfaces in SDL_syswm.h,
then structure SDL_SysIMinfo will become a little heavy.

4

Hello:

I have registered a forum for SDL-IM.
If you are interested in this topic,
please visit http://sdlim.thoforum.com/ .

Pardon me, after a few days I had posted,
I am very curious about has anyone seen these posts?
I feel a little embarrassed.

5

Well, nobody else is replying, though I did get your messages; and
studying Japanese as I am, I would LOVE to have an open-source API
for IMEs! Unfortunately, I haven’t the time to dedicate to it, nor
have I the knowledge to help contribute. I can PROMISE I would use
it (eventually -_-) in future projects, however.

Here are my thoughts on that, however. I don’t recall (though I may
be very wrong) SDL having a focus on text input, necessarily. This
makes me think that an IME (I don’t know about XIM at all) would be
better served as a separate library altogether. My (off the top of
my head) method of implementation would likely be something where you
acquire an instance or a reference to an IME object based on the
language and encoding (probably need to do some abstraction of the
encoding here, though, as I don’t think every programmer using a
library should have to learn the minute details of things like that
to use it right), then as the user types in characters, the
programmer sends those characters (added to each other) to the IME
object, which returns an initial state of what to display. For
instance, when I type in Japanese using Windows’ or Apple’s IMEs, as
I type the string “watashi” I get it in chunks, like “w”, “?”, “?
t”, “??”, “??s”, “??sh”, “???”, because the
different characters represent larger sounds than are made by roman
alpha letters. (Hopefully most people could read that, otherwise
you’ll just have to imagine.)

So then the next thing to do is for the program to listen for the
window key (ie: the key to open the options for the other characters
to use in each case), and then get a list of the items and display
them, allow interaction, etc…

It occurs to me that one could design it such that if you’re editing
text, ALL keyboard input gets sent to the IME library which then
tells the program either what to do OR (somewhat like a UI library)
takes over drawing things itself using whatever variant’s drawing
methods, for instance Opengl, SDL, Allegro, etc… The UI library
Guichan does this and it generally works pretty well I’ve noticed.

Anyway, those are my thoughts, though where to even BEGIN writing an
IME library I am COMPLETELY lost! >.<

I am, however, always happy to theorize and discuss,
– ScottOn Mar 19, 2007, at 7:31 PM, courage wrote:

Hello:

I have registered a forum for SDL-IM.
If you are interested in this topic,
please visit http://sdlim.thoforum.com/ .

Pardon me, after a few days I had posted,
I am very curious about has anyone seen these posts?
I feel a little embarrassed.

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

6

I’m very interested, since a major problem in Tux Paint is
the inability to enter characters in many of the languages
Tux Paint supports (that is, that it has been translated to).

Just haven’t had time to delve into it closely… busy with
work and a newborn.

Thanks!On Tue, Mar 20, 2007 at 01:31:45AM +0000, courage wrote:

Pardon me, after a few days I had posted,
I am very curious about has anyone seen these posts?
I feel a little embarrassed.

–
-bill!
bill at newbreedsoftware.com
http://www.newbreedsoftware.com/

7

Scott Harper <lareon comcast.net> writes:

Here are my thoughts on that, however. I don’t recall (though I may
be very wrong) SDL having a focus on text input, necessarily. This
makes me think that an IME (I don’t know about XIM at all) would be
better served as a separate library altogether. My (off the top of
my head) method of implementation would likely be something where you
acquire an instance or a reference to an IME object based on the
language and encoding (probably need to do some abstraction of the
encoding here, though, as I don’t think every programmer using a
library should have to learn the minute details of things like that
to use it right), then as the user types in characters, the
programmer sends those characters (added to each other) to the IME
object, which returns an initial state of what to display. For
instance, when I type in Japanese using Windows’ or Apple’s IMEs, as
I type the string “watashi” I get it in chunks, like “w”, “?”, “?
t”, “??”, “??s”, “??sh”, “???”, because the
different characters represent larger sounds than are made by roman
alpha letters. (Hopefully most people could read that, otherwise
you’ll just have to imagine.)

??? ??? (Thank you very much!)
http://sdl-im.csie.net/image/thanks_jp.png
That is the same sample just with the different font
and using different IM Client.
The original one is here:
http://sdl-im.csie.net/image/sdl_ttf_sample.png

The Japanese input would be a simple case.
Because Japanese is a phonetic transcription language,
the most composition rules of Japanese IM is typing roman alpha letters
to combine the sounds form words.

But for ideogram, the composition rules is many.
As I know, there are more then twenty rules to type Traditional Chinese.

I also think SDL doesn’t focus on text input.
But If SDL could support IM handle,
there would be many possible imagination to implement.
For example, If I want to design a RPG that players could type
their native language to talk with AI NPC in the game
to get some information or make friends(or make girl friends),
not just select the talking selections to talk,
I could feel easy in mind to use SDL.
It would be more interesting.

Since to support IM handle couldn’t effect the performance of SDL,
we would be only too glad to do it!
(About performance statistics, please see http://sdlim.thoforum.com/ .
The title is “A strange problem with SDL1.2.8” in talk board.)

I also consider to provide a separated library altogether is a better idea,
(Wow, my own project! so cool, isn’t it?)
but to provide a optional package is difficult.
If it is easy, I am very glad to provide a cross-platform package,
even if it doesn’t need SDL.
Because to get an IM instance you could do nothing,
we have to patch the inner event handling of SDL to support IM handle.

I had complained the problems when I used SDL_inputmethod(it’s not my work):
http://sdl-im.csie.net/SDL_inputmethod.html
I had said that “it has strange bugs in win32 that can’t show
the IM state is on or off correctly.
it fails in my Linux. In my laptop, it may crash,
and in another machine, it can’t work.”.

But please see the official site of SDL_inputmethod:
http://sdlinputmethod.sourceforge.net/index.php?l=en
especially the screenshots, it worked fine, didn’t it?

Is their XIM server different from mine? Impossible.
Because SDL_inputmethod project is earlier then SDL-IM,
perhaps it is not the bugs of SDL_inputmethod.

Honestly, I guess the reason of working fail of SDL_inputmethod is
that the newer version of SDL might change some behavior of event handling
and SDL_inputmethod just support early version of SDL,
so that SDL_inputmethod works fail with newer version of SDL.

If it is true unfortunately and I decide to provide a optional package,
then people could see the announcement in my site:
"Well, SDL_im is an independent package altogether,
but it just support SDL-1.2.11.
If you want to upgrade to SDL-1.2.12, you have to patch it please."
Hmm… it looks not a good idea, doesn’t it?

Input Method is not a fashion word. Since the age of DOS,
people try hard to let they can type their native language.
Until the coming of win95, it has a standard to do,
although it is not a good standard.
In fact, I really don’t care whether my patch
could be a part of official release or not,
just because the IM support problem had bother many people so long time ago.
If anybody has a better idea, I will do my best to support him.

I planed to start a improved version of SDL-IM after three or four months.
(Maybe just support the newer version of SDL.)
Before starting, I hope to hear more suggestions, complaint, or bug reports.
If SDL developers could give me their thinking, I will be appreciated.

So then the next thing to do is for the program to listen for the
window key (ie: the key to open the options for the other characters
to use in each case), and then get a list of the items and display
them, allow interaction, etc…

Pardon me, I am not very sure what you mean.
If the window key is to act on IM window,
there is nothing to do with server side. :slight_smile:

It occurs to me that one could design it such that if you’re editing
text, ALL keyboard input gets sent to the IME library which then
tells the program either what to do OR (somewhat like a UI library)
takes over drawing things itself using whatever variant’s drawing
methods, for instance Opengl, SDL, Allegro, etc… The UI library
Guichan does this and it generally works pretty well I’ve noticed.

Pardon me, would you mean to draw IM window in SDL window?
If it is, you could use SDL_imm.

And you mention the Guichan,
there is a patch made by harpy for Guichan to use SDL-IM to support IME.
But the link in my site is dead.

Anyway, those are my thoughts, though where to even BEGIN writing an
IME library I am COMPLETELY lost! >.<

I am, however, always happy to theorize and discuss,

Thanks you again.
Your reply give me a chance to explain more.

I think Input Method support is a easy hard work.
It is easy because to patch is not a hard work.
It is hard because to test is not a easy work.

I will be appreciated any suggestion, complaint, or bug report.

Finally, thanks for Scott and Bill’s replies.

8

courage <dr.courage gmail.com> writes:

In fact, I really don’t care whether my patch
could be a part of official release or not,
just because the IM support problem had bother many people so long time ago.
If anybody has a better idea, I will do my best to support him.

I am afraid that sentances would make some misunderstanding.
I means that success doesn’t depend on me,
and I also really hope SDL could support Input Method very much. :wink:

9

courage escreveu:

I am afraid that sentances would make some misunderstanding.

I’m interested in this matter, but I’m not sure I’m understanding the
scope of your message. You did post some links with some rather old
dates, and no page explaining exactly what is what. You certainly look
experienced in the implementation, so what exactly is your proposal?

That is, what needs to belong to SDL itself, and what can be delegated
to GUI libraries? Can we reduce the SDL-specific part to just a new
event structure and IM activation/deactivation routines, and let an
outside library handle everything else?

Also, I think utf-8 is the way to go; most environments and libraries I
know support only utf-8, or use it by default. For example, I would
certainly like to use Pango, to render the text properly.—
Daniel K. O.

10

My question about what you’ve got thus far is about what you’re using
for the processing of text.

For instance, if you type characters, where does the key input go,
and how do you know what to display?

Looking at your website, it seems like you have things working on
Windows and Linux. Unfortunately, I am a Mac user, and while I love
Apple’s IME very much, I don’t know how to interface with it, and
would obviously prefer a portable/cross-platform solution when I need
to do text input.

Basically how does your current library work, echoing Daniel K. O.'s
message.

– ScottOn Mar 21, 2007, at 4:41 AM, courage wrote:

courage <dr.courage gmail.com> writes:

In fact, I really don’t care whether my patch
could be a part of official release or not,
just because the IM support problem had bother many people so long
time ago.
If anybody has a better idea, I will do my best to support him.

I am afraid that sentances would make some misunderstanding.
I means that success doesn’t depend on me,
and I also really hope SDL could support Input Method very much. :wink:

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

11

Daniel K. O. <danielko.listas gmail.com> writes:

I’m interested in this matter, but I’m not sure I’m understanding the
scope of your message. You did post some links with some rather old
dates, and no page explaining exactly what is what. You certainly look
experienced in the implementation, so what exactly is your proposal?

Sorry for my bad description.
Some links are old because I have done this patch since 2004/12/27,
then I had left a while and considered is it stable enough?

Simply to say, my proposal is a demo to show
which interface could be supported and
what problems should be paid attention to solve when supporting IM,
and let poeple consider the possibility of supporting IM in SDL.

Sorry for my bad description again.
I will try to explain more exactly,
but I need to know what details you couldn’t understand. :slight_smile:

That is, what needs to belong to SDL itself, and what can be delegated
to GUI libraries?

Excuse me, I am not sure what you mean.
As I think, patched SDL + SDL_imm could provide the handling of

  1. receiving the string and window information of IM client.
  2. controling some behavior of IM client.

Can we reduce the SDL-specific part to just a new
event structure and IM activation/deactivation routines, and let an
outside library handle everything else?

Sure, you could see my project is separated into two parts:
one is SDL-IM and it’s a patch for SDL,
another is SDL_imm that is a optional package based on SDL-IM.
Moving all the interface form SDL-IM into SDL_imm could be possible
(but I need to consider the details if it could be),
and then SDL-specific would not be changed,
besides some platform depending declarations in SDL_wmsys.h
would provide some interfaces to SDL_imm.

But to do this before,
there should be a prerequisite,
SDL should be able to flip IM window in fullscreen mode.
I had explained the reasons before.

In my humble opinion, in any event,
even if SDL-specific would not be changed,
the inner event handling of SDL might be patched.

As you mention providing a new event structure,
I recall a project that support XIM as you mention:
http://morihyphen.hp.infoseek.co.jp/prog/sdl-im.html

I am not sure
if adding a pointer of a string in SDL event structure is a good idea.
Could the memory of pointer be freed two times?
Or have any potential problem?

Also, I think utf-8 is the way to go; most environments and libraries I
know support only utf-8, or use it by default. For example, I would
certainly like to use Pango, to render the text properly.

Sorry, I don’t have experience of Pango,
and I am not sure what you means.

Did you mean I should let SDL-IM just only provide utf-8 output?
If you did, I also think it should be. :slight_smile:

In my humble opinion, utf-8 must be the way to go,
but comparing with UCS-16 or UCS-32,
handling utf-8 string is not as direct as handling UCS-16.
So I prefer to support utf-8 and UCS-16 synchronously, like SDL_ttf.

thanks for your suggestions. :-)> —

Daniel K. O.

12

Scott Harper <lareon comcast.net> writes:

My question about what you’ve got thus far is about what you’re using
for the processing of text.

For instance, if you type characters, where does the key input go,
and how do you know what to display?

I hope I don’t misunderstand what you mean.
SDL-IM is not another IM client application,
it makes SDL to support IM client in server side.

So that in server side,
SDL could just receives the string sent by IM client,
and get some information of IM and control it if possible.

Looking at your website, it seems like you have things working on
Windows and Linux. Unfortunately, I am a Mac user, and while I love
Apple’s IME very much, I don’t know how to interface with it, and
would obviously prefer a portable/cross-platform solution when I need
to do text input.

If you don’t mind I ask you, Which version of Mac you use?
Unfortunately, I don’t have any experience of Mac programming.
If I could have the environment to build and test,
and have enough documents of IM programming in Mac,
Maybe I could do the support soon.

I hear that MacOS X can support Intel based PC.
If it can support my AMD64 PC, I would try.
(Sorry I don’t have money to buy Mac machine,
it is too expensive for me.)

Basically how does your current library work, echoing Daniel K. O.'s
message.

For instance, if you are planning to write a simple text editor with SDL,
using SDL-IM to patch SDL first,
then get the strings that are sent by your IM client
with the API that SDL-IM provided
(to get strings, just use SDL_FlushIMString simply)
in the event loop in the editing area of your editor.
(Sorry for so long sentence.)

After building your own editor,
you can use your favorite IM(MacUIM or OpenVanilla)
to input text in your editor.

13

courage <dr.courage gmail.com> writes:

Sorry, I don’t have experience of Pango,
and I am not sure what you means.

Did you mean I should let SDL-IM just only provide utf-8 output?
If you did, I also think it should be.

In my humble opinion, utf-8 must be the way to go,
but comparing with UCS-16 or UCS-32,
handling utf-8 string is not as direct as handling UCS-16.
So I prefer to support utf-8 and UCS-16 synchronously, like SDL_ttf.

After posting, I recalled the reason
why I didn’t force the output to be the UNICODE encoding originally.

If the platform has IM support but doesn’t support UNICODE natively,
like win95/98, is SDL or the application based on SDL,
who has the responsibility to translate text?

I think that translating is not the responsibility for SDL,
so I let it could output the string that encoding depends on platform.
Honestly, SDL_FlushIMString is not complete,
and I will do some modifications and test more.
(patching is easy and testing is really difficult)

14

courage wrote:

In my humble opinion, utf-8 must be the way to go,
but comparing with UCS-16 or UCS-32,
handling utf-8 string is not as direct as handling UCS-16.
So I prefer to support utf-8 and UCS-16 synchronously, like SDL_ttf.

There is no such such as UCS-16. UCS-2 is considered obsolete because
it only covers the basic multilingual plane, which excludes many Chinese
characters. UFT-16 is really no easier to handle than UTF-8. UCS-4 and
UTF-32 would be a valid options for when UTF-8 is too complicated.–
Rainer Deyke - rainerd at eldwood.com

15

Rainer Deyke <rainerd eldwood.com> writes:

There is no such such as UCS-16. UCS-2 is considered obsolete because
it only covers the basic multilingual plane, which excludes many Chinese

You are definitely right.
I must be tired so that typing wrongly. :slight_smile:
UCS2 is not enough really.

characters. UFT-16 is really no easier to handle than UTF-8. UCS-4 and
UTF-32 would be a valid options for when UTF-8 is too complicated.

As you said, if you don’t mind I ask you,
would the interface TTF_RenderUNICODE_* of SDL_ttf be changed?
It uses Uint16 pointer to receive a wide string now,
and I think I might have to follow it’s interface.

16

courage wrote:

As you said, if you don’t mind I ask you,
would the interface TTF_RenderUNICODE_* of SDL_ttf be changed?
It uses Uint16 pointer to receive a wide string now,
and I think I might have to follow it’s interface.

I think SDL_TTF /should/ be changed to support UTF-8, UTF-16, and
UTF-32/UCS-4. However, it’s not my project, so I’m not the one to
change it. I actually use Freetype directly instead of SDL_TTF, so I
don’t have this problem.–
Rainer Deyke - rainerd at eldwood.com

17

How hard to provide a cross-platform IM solution?
First, it would be a very good design and implementation.
Second, I should canvass developers of both applications and IM clients to
use it.

Honestly, present patch of SDL-IM is not flexible.
Maybe improving SDL-IM to support some kind of IM module to
setup any other IM library, like IIIMF or SCIM(although they both support XIM),
would be more flexible, but it could increase some API in SDL.
I have to research more details.

18

As you said, if you don’t mind I ask you,
would the interface TTF_RenderUNICODE_* of SDL_ttf be changed?
It uses Uint16 pointer to receive a wide string now,
and I think I might have to follow it’s interface.

The problem is that “Unicode” on Windows, the TCHAR type, is 16-bit, as
are all OS interfaces. My understanding is that in Windows XP, this
stopped being UCS-2 and started being UTF-16…I would be amazed if most
applications handled this well, though.

Eventually this should change in SDL and support libraries too, but
mostly that will be from people contributing patches.

–ryan.

19

(sorry for the flood of email on this topic, I’m just catching up…)

what problems should be paid attention to solve when supporting IM,
and let poeple consider the possibility of supporting IM in SDL.

We’re already using XIM in the latest SDL, but that’s just to fill in
the “unicode” field for keypresses. I suspect it’s probably not nearly
as robust as it should be…I’d be surprised if it worked well with,
say, Arabic, but I can’t even start to speak authoritatively about
either XIM or Arabic to know. :slight_smile:

Windows and Mac input methods are probably totally lacking in SDL.

Better keyboard input is something that should go into 1.3. Sam
mentioned he had some ideas that World of Warcraft inspired, but the
revamping the input subsystem is still on the TODO list. Having someone
that understands how IM works would be very helpful.

Did you mean I should let SDL-IM just only provide utf-8 output?
If you did, I also think it should be. :slight_smile:

In my humble opinion, utf-8 must be the way to go,
but comparing with UCS-16 or UCS-32,
handling utf-8 string is not as direct as handling UCS-16.
So I prefer to support utf-8 and UCS-16 synchronously, like SDL_ttf.

I love UTF-8 myself, since it lets us ignorant Americans not think about
Unicode very much. :slight_smile: Plus it Mostly Works with legacy APIs and
doesn’t have byte-ordering issues.

But UCS-4 seems to be the way to go if you don’t have huge string
requirements, since it’s much simpler to process…something like SDL
would probably be tossing around a few characters at a time, coming from
the keyboard, so byte-ordering is less of an issue, too.

–ryan.

20

I hear that MacOS X can support Intel based PC.
If it can support my AMD64 PC, I would try.
(Sorry I don’t have money to buy Mac machine,
it is too expensive for me.)

There are some hacks to coerce Mac OS X to install on a standard PC, but
generally, it’s not like Linux or Windows where you just pop an install
disc in the drive and go. Apple takes measures to prevent this.

Getting something proper into SDL, though, means someone will show up to
fill in the missing Mac OS X functionality.

–ryan.