Unicode test II

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
39 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Unicode test II

Michael Rueger-6
Hi all,

after some interesting adventures in Unicode land here's a second
version of the unicode test image/app:

http://impara.de/~michael/unicode-test.zip

Things that I think should work:
- unicode text input on all platforms including support of composing
character sequences (.eg. US international keyboards)
- unicode clipboard handling
- text editor shortcuts on non Latin1 keyboards (e.g. Russian) (thinking
about it, only tested on Windows so far)

Mostly untested:
- unicode filename handling

Known not to work:
- keyboard shortcuts in lists (e.g. browsers) on non Latin1 keyboards.
That would take another major refactoring of handling shortcuts.

Once I know this version works reasonable well I'll package everything
up for inclusion in the updates. Right now it is pretty much a mess.


Happy testing

Michael

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Unicode test II

Damien Cassou
Hi Michael,

On Tue, Mar 3, 2009 at 8:11 AM, Michael Rueger <[hidden email]> wrote:
> after some interesting adventures in Unicode land here's a second
> version of the unicode test image/app:
>
> http://impara.de/~michael/unicode-test.zip

this one works very well for me. I'm able to type "éàôç" in Pharo
directly and copy-paste "àóøœüœáßðfµéë" from a text editor into Pharo.
The following two characters are not well displayed in the workspace,
but that could easily be a missing glyph in the font: $œ and $ð.


Thank you very much

--
Damien Cassou
http://damiencassou.seasidehosting.st

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Unicode test II

Alexis Parseghian
> On Tue, Mar 3, 2009 at 8:11 AM, Michael Rueger <[hidden email]> wrote:
>> after some interesting adventures in Unicode land here's a second
>> version of the unicode test image/app:
>>
>> http://impara.de/~michael/unicode-test.zip
>
> this one works very well for me. I'm able to type "éàôç" in Pharo
> directly and copy-paste "àóøœüœáßðfµéë" from a text editor into Pharo.
> The following two characters are not well displayed in the workspace,
> but that could easily be a missing glyph in the font: $œ and $ð.

Works for me as well. Tested on debian squeeze in all-UTF8 setup, with
a text that has most french accents (not tested: combined chars as
shown by Damien, northern or central european diacritics). Direct
typing works, so does cut&paste from system to squeak. The same test
file viewed in or imported to a workspace from Filelist doesn't,
though (I guess it's not directly related).

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Unicode test II

Damien Cassou
In reply to this post by Damien Cassou
On Tue, Mar 3, 2009 at 10:10 AM, Damien Cassou <[hidden email]> wrote:
> this one works very well for me. I'm able to type "éàôç" in Pharo
> directly and copy-paste "àóøœüœáßðfµéë" from a text editor into Pharo.
> The following two characters are not well displayed in the workspace,
> but that could easily be a missing glyph in the font: $œ and $ð.

my configuration is:

GNU/Linux Ubuntu 8.04 32bits
Keyboard layout: USA international with Alt-Gr dead key

--
Damien Cassou
http://damiencassou.seasidehosting.st

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Unicode test II

Alexis Parseghian
> my configuration is:
>
> GNU/Linux Ubuntu 8.04 32bits
> Keyboard layout: USA international with Alt-Gr dead key

Since you mention it... :)

Layout here is canadian french (traditional I think... it's a '94
vintage keyboard), QWERTY with accents and AltCar (AltGr). "É" and
altCar-accute accent (dead key) next to the right shift.

Using any font other than the default Accuny, the characters displayed
perfectly match keyboard markings. (With Accuny the differences are
minor, and only on a few rarely used symbols on the first row.)

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Unicode test II

Yoshiki Ohshima-2
In reply to this post by Michael Rueger-6
At Mon, 02 Mar 2009 23:11:00 -0800,
Michael Rueger wrote:

>
> Hi all,
>
> after some interesting adventures in Unicode land here's a second
> version of the unicode test image/app:
>
> http://impara.de/~michael/unicode-test.zip
>
> Things that I think should work:
> - unicode text input on all platforms including support of composing
> character sequences (.eg. US international keyboards)
> - unicode clipboard handling
> - text editor shortcuts on non Latin1 keyboards (e.g. Russian) (thinking
> about it, only tested on Windows so far)
>
> Mostly untested:
> - unicode filename handling
>
> Known not to work:
> - keyboard shortcuts in lists (e.g. browsers) on non Latin1 keyboards.
> That would take another major refactoring of handling shortcuts.
>
> Once I know this version works reasonable well I'll package everything
> up for inclusion in the updates. Right now it is pretty much a mess.

  On Windows Vista in Japanese, the system seems to get the unicode
values from keyboard but doesn't display them correctly.  For short
cut keys, when MS IME is enabled and in the Roma-ji input mode, it
does work.

-- Yoshiki

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Unicode test II

Michael Rueger-6
Yoshiki Ohshima wrote:

>   On Windows Vista in Japanese, the system seems to get the unicode
> values from keyboard but doesn't display them correctly.  For short

Any idea why? I'm pretty sure I'm going through the correct process for
the leading char. Is there any glyph translation needed for the
rendering or the font import?

Michael


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Unicode test II

Mariano Martinez Peck
In reply to this post by Yoshiki Ohshima-2
It doesn't work for me. I am using Ubuntu 8.04 with latin american distribution. I am trying yo type "é", "ú", and so on, but with no luck.

The problem is: I open a workspace. I type "á" and works fine. I try to type "á" again and I have this error: "'subscript is out of bounds: -60'"

It is very strange because only the first time work.

Cheers,

Mariano



On Tue, Mar 3, 2009 at 9:17 PM, Yoshiki Ohshima <[hidden email]> wrote:
At Mon, 02 Mar 2009 23:11:00 -0800,
Michael Rueger wrote:
>
> Hi all,
>
> after some interesting adventures in Unicode land here's a second
> version of the unicode test image/app:
>
> http://impara.de/~michael/unicode-test.zip
>
> Things that I think should work:
> - unicode text input on all platforms including support of composing
> character sequences (.eg. US international keyboards)
> - unicode clipboard handling
> - text editor shortcuts on non Latin1 keyboards (e.g. Russian) (thinking
> about it, only tested on Windows so far)
>
> Mostly untested:
> - unicode filename handling
>
> Known not to work:
> - keyboard shortcuts in lists (e.g. browsers) on non Latin1 keyboards.
> That would take another major refactoring of handling shortcuts.
>
> Once I know this version works reasonable well I'll package everything
> up for inclusion in the updates. Right now it is pretty much a mess.

 On Windows Vista in Japanese, the system seems to get the unicode
values from keyboard but doesn't display them correctly.  For short
cut keys, when MS IME is enabled and in the Roma-ji input mode, it
does work.

-- Yoshiki

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Unicode test II

Michael Rueger-6
Mariano Martinez Peck wrote:
> It doesn't work for me. I am using Ubuntu 8.04 with latin american
> distribution. I am trying yo type "é", "ú", and so on, but with no luck.
>
> The problem is: I open a workspace. I type "á" and works fine. I try to
> type "á" again and I have this error: "'subscript is out of bounds: -60'"
>
> It is very strange because only the first time work.

What kind of keyboard are you using?

I had to do an incredibly ugly hack because of the way the Linux VM
deals with composing key sequences, so it could be that I messed up the
normal keyboard input. Sigh...

Michael

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Unicode test II

Mariano Martinez Peck


On Tue, Mar 3, 2009 at 10:24 PM, Michael Rueger <[hidden email]> wrote:
Mariano Martinez Peck wrote:
> It doesn't work for me. I am using Ubuntu 8.04 with latin american
> distribution. I am trying yo type "é", "ú", and so on, but with no luck.
>
> The problem is: I open a workspace. I type "á" and works fine. I try to
> type "á" again and I have this error: "'subscript is out of bounds: -60'"
>
> It is very strange because only the first time work.

What kind of keyboard are you using?

I had to do an incredibly ugly hack because of the way the Linux VM
deals with composing key sequences, so it could be that I messed up the
normal keyboard input. Sigh...

Dell 101-key PC with Latin American Layout.

cheers
 

Michael

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Unicode test II

Rob Rothwell
Long ago when I thought I was going to be writing Operating Systems in Assembly Language, I had a raw keyboard driver interpreting the key codes from various keyboards.

TERRIBLE to debug (though not as bad as debugging a display driver).

Is that what all this is like?

Ugh...

Do you use lookup tables for all the various keyboard types and operating systems?

It seems like you almost need a matrix of all the supported systems vs. all the possible keyboards, with a table for each one...it could just be a file in the image directory and get loaded at startup.

Then, if someone has some weird keyboard, they could just edit the file...

But then, I probably have no idea what I'm talking about!!!

Rob

On Tue, Mar 3, 2009 at 7:27 PM, Mariano Martinez Peck <[hidden email]> wrote:


On Tue, Mar 3, 2009 at 10:24 PM, Michael Rueger <[hidden email]> wrote:
Mariano Martinez Peck wrote:
> It doesn't work for me. I am using Ubuntu 8.04 with latin american
> distribution. I am trying yo type "é", "ú", and so on, but with no luck.
>
> The problem is: I open a workspace. I type "á" and works fine. I try to
> type "á" again and I have this error: "'subscript is out of bounds: -60'"
>
> It is very strange because only the first time work.

What kind of keyboard are you using?

I had to do an incredibly ugly hack because of the way the Linux VM
deals with composing key sequences, so it could be that I messed up the
normal keyboard input. Sigh...

Dell 101-key PC with Latin American Layout.

cheers
 

Michael

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Unicode test II

Igor Stasenko
In reply to this post by Michael Rueger-6
Great, keyboard shortcuts now is working under russian keyboard layout
in windoze!

2009/3/3 Michael Rueger <[hidden email]>:

> Hi all,
>
> after some interesting adventures in Unicode land here's a second
> version of the unicode test image/app:
>
> http://impara.de/~michael/unicode-test.zip
>
> Things that I think should work:
> - unicode text input on all platforms including support of composing
> character sequences (.eg. US international keyboards)
> - unicode clipboard handling
> - text editor shortcuts on non Latin1 keyboards (e.g. Russian) (thinking
> about it, only tested on Windows so far)
>
> Mostly untested:
> - unicode filename handling
>
> Known not to work:
> - keyboard shortcuts in lists (e.g. browsers) on non Latin1 keyboards.
> That would take another major refactoring of handling shortcuts.
>
> Once I know this version works reasonable well I'll package everything
> up for inclusion in the updates. Right now it is pretty much a mess.
>
>
> Happy testing
>
> Michael
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>



--
Best regards,
Igor Stasenko AKA sig.

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Unicode test II

Michael Rueger-6
In reply to this post by Rob Rothwell
Rob Rothwell wrote:

> Long ago when I thought I was going to be writing Operating Systems in
> Assembly Language, I had a raw keyboard driver interpreting the key
> codes from various keyboards.
>
> TERRIBLE to debug (though not as bad as debugging a display driver).
>
> Is that what all this is like?
>
> Ugh...
>
> Do you use lookup tables for all the various keyboard types and
> operating systems?
>
> It seems like you almost need a matrix of all the supported systems vs.
> all the possible keyboards, with a table for each one...it could just be
> a file in the image directory and get loaded at startup.
>
> Then, if someone has some weird keyboard, they could just edit the file...
>
> But then, I probably have no idea what I'm talking about!!!

Well, at some level that is what the OS is doing. Fortunately the VMs
can work on a slightly higher level.
But...

Although all VMs now deliver unicode values in slot 6 of the input
event, getting composing keyboards and latin1 based shortcut keys to
work is still tricky. And I still haven't tested all the important
combinations of OS and keyboard layouts yet.

The Windows VM does a good job delivering composed sequences, you get
all the intermediate keys (e.g. " and u), but only one keystroke event
for the composed character.
The Linux VM however delivers keystrokes for the intermediate keys, so I
need to figure out, if there is a single key or a composing sequence
coming up. That's where the ugly hack comes in, peeking for the next
event etc.

Supporting Latin1 based shortcut keys (x c v cut copy paste etc) is so
far only tested and probably only there working on Windows. It works by
looking at the scancode of the key, which is only delivered on the key
down and up events. Then, in dispatch, I need to look at the unicode
value delivered, but also at the scan code and if a modifier is pressed.
The problem is that dispatching of key commands is implemented
differently all over the system and in no place used the event, but
simply the character. I refactored it for paragraph editor, but not all
the other places.

In Sophie we got around that by hacking the Tweak widgets to use
factored out lookup tables, so there was only one place to deal with that.

Michael

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Unicode test II

Igor Stasenko
Michael, i got an in MultiCompositionScanner.

I can't mail out a bug report, because when doing it, i again get the
same error.

Can i send an image.zip to you, so you can take a look at it?

2009/3/4 Michael Rueger <[hidden email]>:

> Rob Rothwell wrote:
>> Long ago when I thought I was going to be writing Operating Systems in
>> Assembly Language, I had a raw keyboard driver interpreting the key
>> codes from various keyboards.
>>
>> TERRIBLE to debug (though not as bad as debugging a display driver).
>>
>> Is that what all this is like?
>>
>> Ugh...
>>
>> Do you use lookup tables for all the various keyboard types and
>> operating systems?
>>
>> It seems like you almost need a matrix of all the supported systems vs.
>> all the possible keyboards, with a table for each one...it could just be
>> a file in the image directory and get loaded at startup.
>>
>> Then, if someone has some weird keyboard, they could just edit the file...
>>
>> But then, I probably have no idea what I'm talking about!!!
>
> Well, at some level that is what the OS is doing. Fortunately the VMs
> can work on a slightly higher level.
> But...
>
> Although all VMs now deliver unicode values in slot 6 of the input
> event, getting composing keyboards and latin1 based shortcut keys to
> work is still tricky. And I still haven't tested all the important
> combinations of OS and keyboard layouts yet.
>
> The Windows VM does a good job delivering composed sequences, you get
> all the intermediate keys (e.g. " and u), but only one keystroke event
> for the composed character.
> The Linux VM however delivers keystrokes for the intermediate keys, so I
> need to figure out, if there is a single key or a composing sequence
> coming up. That's where the ugly hack comes in, peeking for the next
> event etc.
>
> Supporting Latin1 based shortcut keys (x c v cut copy paste etc) is so
> far only tested and probably only there working on Windows. It works by
> looking at the scancode of the key, which is only delivered on the key
> down and up events. Then, in dispatch, I need to look at the unicode
> value delivered, but also at the scan code and if a modifier is pressed.
> The problem is that dispatching of key commands is implemented
> differently all over the system and in no place used the event, but
> simply the character. I refactored it for paragraph editor, but not all
> the other places.
>
> In Sophie we got around that by hacking the Tweak widgets to use
> factored out lookup tables, so there was only one place to deal with that.
> - Show quoted text -
> Michael
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>



--
Best regards,
Igor Stasenko AKA sig.

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Unicode test II

Igor Stasenko
2009/3/4 Igor Stasenko <[hidden email]>:
> Michael, i got an in MultiCompositionScanner.
i mean error... :)

>
> I can't mail out a bug report, because when doing it, i again get the
> same error.
>
> Can i send an image.zip to you, so you can take a look at it?
>
> 2009/3/4 Michael Rueger <[hidden email]>:
> - Show quoted text -
>> Rob Rothwell wrote:
>>> Long ago when I thought I was going to be writing Operating Systems in
>>> Assembly Language, I had a raw keyboard driver interpreting the key
>>> codes from various keyboards.
>>>
>>> TERRIBLE to debug (though not as bad as debugging a display driver).
>>>
>>> Is that what all this is like?
>>>
>>> Ugh...
>>>
>>> Do you use lookup tables for all the various keyboard types and
>>> operating systems?
>>>
>>> It seems like you almost need a matrix of all the supported systems vs.
>>> all the possible keyboards, with a table for each one...it could just be
>>> a file in the image directory and get loaded at startup.
>>>
>>> Then, if someone has some weird keyboard, they could just edit the file...
>>>
>>> But then, I probably have no idea what I'm talking about!!!
>>
>> Well, at some level that is what the OS is doing. Fortunately the VMs
>> can work on a slightly higher level.
>> But...
>>
>> Although all VMs now deliver unicode values in slot 6 of the input
>> event, getting composing keyboards and latin1 based shortcut keys to
>> work is still tricky. And I still haven't tested all the important
>> combinations of OS and keyboard layouts yet.
>>
>> The Windows VM does a good job delivering composed sequences, you get
>> all the intermediate keys (e.g. " and u), but only one keystroke event
>> for the composed character.
>> The Linux VM however delivers keystrokes for the intermediate keys, so I
>> need to figure out, if there is a single key or a composing sequence
>> coming up. That's where the ugly hack comes in, peeking for the next
>> event etc.
>>
>> Supporting Latin1 based shortcut keys (x c v cut copy paste etc) is so
>> far only tested and probably only there working on Windows. It works by
>> looking at the scancode of the key, which is only delivered on the key
>> down and up events. Then, in dispatch, I need to look at the unicode
>> value delivered, but also at the scan code and if a modifier is pressed.
>> The problem is that dispatching of key commands is implemented
>> differently all over the system and in no place used the event, but
>> simply the character. I refactored it for paragraph editor, but not all
>> the other places.
>>
>> In Sophie we got around that by hacking the Tweak widgets to use
>> factored out lookup tables, so there was only one place to deal with that.
>> - Show quoted text -
>> Michael
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
>
>
> - Show quoted text -
> --
> Best regards,
> Igor Stasenko AKA sig.
>



--
Best regards,
Igor Stasenko AKA sig.

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Unicode test II

Michael Rueger-6
Igor Stasenko wrote:
> 2009/3/4 Igor Stasenko <[hidden email]>:
>> Michael, i got an in MultiCompositionScanner.
> i mean error... :)
>
>> I can't mail out a bug report, because when doing it, i again get the
>> same error.

bummer
Hmm, shouldn't there be a SqueakDebug.log file though?

at least the method in question and a brief description of what you did
would help :-)

Michael

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Unicode test II

Igor Stasenko
2009/3/4 Michael Rueger <[hidden email]>:

> Igor Stasenko wrote:
>> 2009/3/4 Igor Stasenko <[hidden email]>:
>>> Michael, i got an in MultiCompositionScanner.
>> i mean error... :)
>>
>>> I can't mail out a bug report, because when doing it, i again get the
>>> same error.
>
> bummer
> Hmm, shouldn't there be a SqueakDebug.log file though?
>
> at least the method in question and a brief description of what you did
> would help :-)

i changed default font to Arial , to see russian letters while i typing..
then i typed some of them in transcript window..

then i tried to copy/paste text - it works well..
but then at some point it throws me an error

subscript out of bounds: 1075

in

scanMultiCharactersCombiningFrom: startIndex to: stopIndex in:
sourceString rightX: rightX stopConditions: stops kern: kernDelta

method near following statement:
(encoding = 0 and: [(stopConditions at: charCode + 1) ~~ nil]) ifTrue: [

more precisely (stopConditions at: charCode + 1)

okay, i closed debugger, closed transcript, opened a fresh new one,
and tried again.. and was unable to reproduce the error.
Then i decided to go to preferences and change the freetype hinting
options.. once i clicked on it i got the same error.
a transcript window contains following chars:

ыфвыф вфы вфы вфы йщ
фыошйвщшцовщ
ошоошйв
йцошощшцовщцвйцовшйцошйцовцвйцовшйв



> - Show quoted text -
> Michael
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>



--
Best regards,
Igor Stasenko AKA sig.

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Unicode test II

Michael Rueger-6
Igor Stasenko wrote:
> 2009/3/4 Michael Rueger <[hidden email]>:


> scanMultiCharactersCombiningFrom: startIndex to: stopIndex in:
> sourceString rightX: rightX stopConditions: stops kern: kernDelta
>
> method near following statement:
> (encoding = 0 and: [(stopConditions at: charCode + 1) ~~ nil]) ifTrue: [

hmm, could be that the encoding gets lost somewhere and so allows the
code to enter the block.
I think we rather need to test for charCode < 256 as the stopConditions
are only of that size for any encoding AFAIK.

Michael

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Unicode test II

SergeStinckwich
In reply to this post by Michael Rueger-6
On Tue, Mar 3, 2009 at 2:11 PM, Michael Rueger <[hidden email]> wrote:

> Hi all,
>
> after some interesting adventures in Unicode land here's a second
> version of the unicode test image/app:
>
> http://impara.de/~michael/unicode-test.zip
>
> Things that I think should work:
> - unicode text input on all platforms including support of composing
> character sequences (.eg. US international keyboards)
> - unicode clipboard handling
> - text editor shortcuts on non Latin1 keyboards (e.g. Russian) (thinking
> about it, only tested on Windows so far)

It seems to work with a french keyboard on Mac OS X.
I try with a vietnamese keyboard but i think i need a vietnamese font.

--
Serge Stinckwich
UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam
Smalltalkers do: [:it | All with: Class, (And love: it)]
http://doesnotunderstand.org/

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Unicode test II

Yoshiki Ohshima-2
In reply to this post by Michael Rueger-6
At Tue, 03 Mar 2009 15:50:47 -0800,
Michael Rueger wrote:
>
> Yoshiki Ohshima wrote:
>
> >   On Windows Vista in Japanese, the system seems to get the unicode
> > values from keyboard but doesn't display them correctly.  For short
>
> Any idea why? I'm pretty sure I'm going through the correct process for
> the leading char. Is there any glyph translation needed for the
> rendering or the font import?

  - The char typed into the workspace doesn't have the leading char.

  - If I open the browser and go to JapaneseEnvironment
    class>>isBreakableAt:in: (possibly the only method with Japanese
    characters), it doesn't display characters, even though the result
    from #sourceCodeAt: does contain strings with leading chars.

  So I loaded the good old FontForJapaneseEnvironment.sar and the
latter case it does display characters properly.

-- Yoshiki

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
12