Crystal Space
Welcome, Guest. Please login or register.
July 23, 2014, 03:12:49 pm

Login with username, password and session length
Search:     Advanced search
9005 Posts in 2043 Topics by 8220 Members
Latest Member: Igymatta
* Home Help Search Login Register
+  Crystal Space
|-+  Crystal Space Development
| |-+  Support
| | |-+  converting Key characters int -> char
« previous next »
Pages: [1] 2 Print
Author Topic: converting Key characters int -> char  (Read 5574 times)
mark
Full Member
***
Posts: 101


View Profile
« on: September 05, 2005, 08:25:52 pm »

I get the keyboards' input with
Code:
utf32_char code = csKeyEventHelper::GetCookedCode(&event);
and want to print the char on the screen.

How do I print the char which is represented by "code" on the screen? In C char can be casted into int and vice versa but with utf8_char -> char some special chars are not printed. How do I do this?
Logged

Gentoo Linux ~x86, kernel 2.6.11-cko9 smp, gcc 3.4.4-r1, binutils 2.16.1, glibc 2.3.5 NPTL
CS+CEL Pseudo Stable 2005.09.03
res
Develazyoper
CS Developer
Full Member
*****
Posts: 206


View Profile Email
« Reply #1 on: September 05, 2005, 10:23:24 pm »

You basically need to encode the character into UTF-8 for output with CS; this can be done with csUnicodeTransform (http://crystalspace3d.org/docs/online/api/classcsUnicodeTransform.php):

Code:
// Buffer that will receive UTF-8 string
utf8_char buf[CS_UC_MAX_UTF8_ENCODED+1];
// Encode
int n = csUnicodeTransform::EncodeUTF8 (code, buf, sizeof(buf)/sizeof(buf[0]));
// Null-terminate
buf[n] = 0;

buf can then be output with any CS function, e.g. csPrintf ("%s\n", buf); or iGraphics2D->Write().
Logged
mark
Full Member
***
Posts: 101


View Profile
« Reply #2 on: September 06, 2005, 01:11:09 pm »

hm, this still does not print the german umlaute: ä,ö,ü (I tried endoding with utf32 too), neither with csPrintf nor with Write. All other ASCII-chars work though.
And it is not usable with csString. I tried to append it to a csString but it appends "1" for every char I type, even the ASCII ones.
How do I do that?
Logged

Gentoo Linux ~x86, kernel 2.6.11-cko9 smp, gcc 3.4.4-r1, binutils 2.16.1, glibc 2.3.5 NPTL
CS+CEL Pseudo Stable 2005.09.03
res
Develazyoper
CS Developer
Full Member
*****
Posts: 206


View Profile Email
« Reply #3 on: September 06, 2005, 01:21:35 pm »

hm, this still does not print the german umlaute: ä,ö,ü (I tried endoding with utf32 too), neither with csPrintf nor with Write.

What platform are you on?
What font do you use with Write()?

Quote
And it is not usable with csString. I tried to append it to a csString but it appends "1" for every char I type, even the ASCII ones.
How do I do that?
Sounds odd? How do you append? You should basically append buf from the example (you may possibly need a char* cast).
Logged
mark
Full Member
***
Posts: 101


View Profile
« Reply #4 on: September 06, 2005, 04:53:29 pm »

The char* cast replaces 1 with the char, so that was a mistake by me.  (-> this works now)
I'm using operator+= to append. (-> works now)
I'm using Linux and the unifont distributed with CS.
CS version: pseudo stable release

I followed the function calls through my code and it ends here:
Main application (csApplicationFramework, csBaseEventHandler), method OnKeyboard (iEvent &e):

Code:
bool wsDemo::OnKeyboard (iEvent &e) {
csPrintf("OnKeyBoard\n");
    return panel->onEvent(e);
}

It doesn't print "OnKeyBoard" when typing an umlaut -> umlaute are not recognized by OnKeyBoard(). Is this a bug in CS?
« Last Edit: September 06, 2005, 05:01:54 pm by mark » Logged

Gentoo Linux ~x86, kernel 2.6.11-cko9 smp, gcc 3.4.4-r1, binutils 2.16.1, glibc 2.3.5 NPTL
CS+CEL Pseudo Stable 2005.09.03
res
Develazyoper
CS Developer
Full Member
*****
Posts: 206


View Profile Email
« Reply #5 on: September 06, 2005, 05:33:47 pm »

It doesn't print "OnKeyBoard" when typing an umlaut -> umlaute are not recognized by OnKeyBoard(). Is this a bug in CS?

I think so... the X keyboard handling is unfortunately highly unfriendly to non-English.
Logged
mark
Full Member
***
Posts: 101


View Profile
« Reply #6 on: September 07, 2005, 10:29:36 am »

Where in the CS code can that be fixed? I searched a little bit in csutil event and inputstuff but didn't find a right place for that (and where do you include X headers?)
Logged

Gentoo Linux ~x86, kernel 2.6.11-cko9 smp, gcc 3.4.4-r1, binutils 2.16.1, glibc 2.3.5 NPTL
CS+CEL Pseudo Stable 2005.09.03
res
Develazyoper
CS Developer
Full Member
*****
Posts: 206


View Profile Email
« Reply #7 on: September 07, 2005, 11:33:50 am »

The X-related code is in plugins; the input handling is essentially in the xwindow plugin.
Logged
mark
Full Member
***
Posts: 101


View Profile
« Reply #8 on: September 07, 2005, 02:20:09 pm »

ok, I made some debug messages in the CS code and found something out. I can't write a patch because I don't have enough understanding of all code correlations but with my info I hope it should be easy enough for someone with this understanding to write a patch.

The X eventhandling is ok until that piece of code:
plugins/video/canvas/xwindow/xwindow.cpp, line 690 - 698:
Code:
          default:           
    {
      if (xKey < sizeof(ScanCodeToChar)/sizeof(ScanCodeToChar[0]))
      {
csKeyRaw = ScanCodeToChar [xKey];
  // @@@ Remove scancodes, if possible
csKeyCooked = charcount == 1 ? charcode[0] : 0;
      }
    }
This is the place where regular keys are handled.
"default" is being entered when I push an umlaut, but the "if" isn't.
This is why:
ä xKey: 228
ö xKey: 246
ü xKey: 252
ß xKey: 223
Ä xKey: 196
Ö xKey: 214
Ü xKey: 220

but include/csplugincommon/canvas/scancode.h, line 32:
extern CS_CRYSTALSPACE_EXPORT unsigned short ScanCodeToChar [128];

-> the xKeys for the special chars are bigger than ScanCodeToChar, that's the reason why they are not handled by CS.
ASCII has 128 chars, Latin-1 has 256, but for unicode this should be 65.536  (UCS-2, 16 Bit) or 1.114.112 (UCS-4, 32 Bit)

Further I noticed that charcount is 0 with Metakeys like Shift..., 1 with regular alphanum keys and 2 with äöüßÄÖÜ.
charcount == 2 isn't used in the code, but maybe has to be used.

I tested with ScanCodeToChar [256] and now my OnKeyBoard is invoked when pushing an umlaut (though it is not yet painted on the screen)
Logged

Gentoo Linux ~x86, kernel 2.6.11-cko9 smp, gcc 3.4.4-r1, binutils 2.16.1, glibc 2.3.5 NPTL
CS+CEL Pseudo Stable 2005.09.03
res
Develazyoper
CS Developer
Full Member
*****
Posts: 206


View Profile Email
« Reply #9 on: September 07, 2005, 03:35:02 pm »

That whole scancode thingie is really ugly; effectively it means that CS uses an hardcoded English keyboard layout. Yuck!
From looking a bit around in the past, it seems there are functions to get Unicode characters (ie what CS wants) from X, but my knowledge about that is unfortunately rather limited as well Tongue

Quote
Further I noticed that charcount is [...] 2 with äöüßÄÖÜ.
That may suggest that charcode actually contains the right character code, encoded in UTF-8. However, I don't know how far you could generally rely on that (e.g. maybe charcode actually contains the character in some system-specific non-Unicode codepage).
Logged
mark
Full Member
***
Posts: 101


View Profile
« Reply #10 on: September 07, 2005, 05:34:22 pm »

so I guess the only necessary patch would be a replacement of the hardcoded english table with a unicode table, right?
Logged

Gentoo Linux ~x86, kernel 2.6.11-cko9 smp, gcc 3.4.4-r1, binutils 2.16.1, glibc 2.3.5 NPTL
CS+CEL Pseudo Stable 2005.09.03
res
Develazyoper
CS Developer
Full Member
*****
Posts: 206


View Profile Email
« Reply #11 on: September 07, 2005, 06:35:47 pm »

Keyboard input is slightly more complicated.

The scancode merely identifies the key that is pressed - just the piece of plastic, the scancode itself has no notion of characters. Characters are obtained by translating the scancode with a keyboard layout - the layout (roughly) maps a scancode to a character; it is pure software.

CS' scancode table is now such a layout - a hardcoded English layout.

The keyboard layout can (obviously) differ from system to system; we cannot possibly put every layout available into CS - not to mention that scancode translation is not CS' job to begin with. Rather, the X keyboard input facilities have to be investigated in order to find out whether there's a function that may do the translation to Unicode for us. Or, less preferably, that translates the key into some non-Unicode charset, from which we possibly again convert into Unicode (e.g. with the libc multibyte-to-wchar_t functions).
Logged
sunshine
Administrator
Sr. Member
*****
Posts: 294


View Profile
« Reply #12 on: September 07, 2005, 09:27:20 pm »

Some links pointing at X documentation:

http://www.x.org/X11R6.8.2/doc/
http://www.xfree86.org/sos/resources.html
Logged
mark
Full Member
***
Posts: 101


View Profile
« Reply #13 on: September 09, 2005, 10:10:41 am »

the X program "xev" does the translation in it's function
Code:
static void
do_KeyPress (XEvent *eventp)

http://cvsweb.xfree86.org/cvsweb/xc/programs/xev/xev.c?rev=1.15&content-type=text/vnd.viewcvs-markup

example output:
Code:
KeyRelease event, serial 31, synthetic NO, window 0x2a00001,
    root 0x116, subw 0x0, time 4849869, (-403,320), root:(355,351),
    state 0x0, keycode 48 (keysym 0xe4, adiaeresis), same_screen YES,
    XLookupString gives 2 bytes: (c3 a4) "ä"
« Last Edit: September 09, 2005, 10:33:25 am by mark » Logged

Gentoo Linux ~x86, kernel 2.6.11-cko9 smp, gcc 3.4.4-r1, binutils 2.16.1, glibc 2.3.5 NPTL
CS+CEL Pseudo Stable 2005.09.03
sunshine
Administrator
Sr. Member
*****
Posts: 294


View Profile
« Reply #14 on: September 09, 2005, 10:27:15 am »

If I read this correctly, perhaps Xutf8LookupString() would be useful for CS since CS would like to have Unicode input.

http://www.x.org/X11R6.8.2/doc/XmbLookupString.3.html

I am a bit concerned, however, that these functions can be used only for key-press, but not key-release.
Logged
Pages: [1] 2 Print 
« previous next »
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.2 | SMF © 2006-2007, Simple Machines LLC Valid XHTML 1.0! Valid CSS!
Page created in 5.204 seconds with 15 queries.