Hi,
2009/8/27 Andreas Raab andreas.raab@gmx.de
Michal Perutka wrote:
many thanks. I have tried your code (sorry for the delay - I spent two weeks with my family but without my laptop ;) and it works for me (hurray! :-) with these modifications:
Very good.
/Character value: .../ (or /keyValue asCharacter/ in your version of the
next method) doesn't work for characters with unicodes > 255 (e.g. "latin small letter s with caron" $š has unicode 353).
Actually, that was no mistake. I meant to use Character value: xxx since I want us to get away from the leading char stuff in Unicode. What happens when you use Character value: instead of Unicode value:? Does it blow up? Does it display incorrectly? Anything else?
$? for every code > 255. For example Character value: 353 shows $?, Character leadingChar: 14 code: 353 shows $š
UnicodeInputInterpreter>>nextCharFrom: sensor firstEvt: evtBuf
"Compose Unicode character sequences" | peekEvent keyValue composed | "Only try this if the first event is composable and is a character event" ((Unicode isComposable: (keyValue := evtBuf *sixth*)) and:[evtBuf fourth = EventKeyChar]) ifTrue:[ ... ]. "XXXX: Fixme. We should put the skipped event back if we haven't consumed it."
^ *Unicode* value: keyValue
Why evtBuf sixth ? Some keys on a Czech keyboard give me possibility to type Czech characters with diacritical marks directly. Correct codes (unicodes, e.g. 353 for $š) I've found in evtBuf at the sixth position, not at the third. And the sixth position seems to be Ok for all characters.
Yes, that's correct. Mistake on my part. Element three is the old MacRoman value; number six is the UTF32 code point.
And the last thing: When I run Squeak with an option - encoding UTF-8, I
think the UnicodeInputInterpreter should be installed. Otherwise I have to do it manually (World primaryHand keyboardInterpreter: UnicodeInputInterpreter new)
Right. I really dislike it that the Unix VM still doesn't use Unicode by default (as the Windows and Mac VMs do). Perhaps I can convince Ian to change the default.
Today I tested UnicodeInputInterpreter on Win XP and it works as well as on Linux.
Cheers Michal
Michal Perutka wrote:
2009/8/27 Andreas Raab <andreas.raab@gmx.de mailto:andreas.raab@gmx.de> Actually, that was no mistake. I meant to use Character value: xxx since I want us to get away from the leading char stuff in Unicode. What happens when you use Character value: instead of Unicode value:? Does it blow up? Does it display incorrectly? Anything else?
$? for every code > 255. For example Character value: 353 shows $?, Character leadingChar: 14 code: 353 shows $š
That's *extremely* strange. I just tried it and it shows $š in both cases in a current updated trunk image after selecting a suitable font (I used Arial). What image are you using? Which font(s) did you use to try this?
Can someone else try to verify this with a current trunk image? (I'm wondering if I screwed something up with my own experiments here) You should see no difference between printing (Character leadingChar: 14 code: 353) and (Character value: 353) (i.e., they either both display as $? or they both display as $š).
Cheers, - Andreas
2009/8/28 Andreas Raab andreas.raab@gmx.de
Michal Perutka wrote:
2009/8/27 Andreas Raab <andreas.raab@gmx.de mailto:andreas.raab@gmx.de> Actually, that was no mistake. I meant to use Character value: xxx since I want us to get away from the leading char stuff in Unicode. What happens when you use Character value: instead of Unicode value:? Does it blow up? Does it display incorrectly? Anything else?
$? for every code > 255. For example Character value: 353 shows $?, Character leadingChar: 14 code: 353 shows $š
That's *extremely* strange. I just tried it and it shows $š in both cases in a current updated trunk image after selecting a suitable font (I used Arial). What image are you using? Which font(s) did you use to try this?
Can someone else try to verify this with a current trunk image? (I'm
wondering if I screwed something up with my own experiments here) You should see no difference between printing (Character leadingChar: 14 code: 353) and (Character value: 353) (i.e., they either both display as $? or they both display as $š).
Sorry, the problem is with my font - I use a Latin2 bitmap font. When I use some TTF font (installed from Windows), it is OK.
Cheers Michal
Michal Perutka wrote:
2009/8/28 Andreas Raab <andreas.raab@gmx.de mailto:andreas.raab@gmx.de> Can someone else try to verify this with a current trunk image? (I'm wondering if I screwed something up with my own experiments here) You should see no difference between printing (Character leadingChar: 14 code: 353) and (Character value: 353) (i.e., they either both display as $? or they both display as $š).
Sorry, the problem is with my font - I use a Latin2 bitmap font. When I use some TTF font (installed from Windows), it is OK.
Phew! Glad we sorted that out ;-)
Cheers, - Andreas
squeak-dev@lists.squeakfoundation.org