danil osipchuk wrote:
> I didn't check this (that thread was about linux). See another mail > about changes I did (they are not so big but inconsistent with linux). Sorry, can you point me to the post you mean? Thanks, - Andreas |
2008/2/7, Andreas Raab <[hidden email]>: danil osipchuk wrote: To be clear: I didn't touch the VM itself. Mouse wheel movings are not reflected in the 6th field (zero there). So one has to also look at the 3th field (and the way one does it is incompatible with linux) cheers, Danil Sorry, can you point me to the post you mean? This one: http://www.nabble.com/Re%3A-3.10---Mac-OS-X-Leopard---accent-chars-and-keyboard-input-p15338354.html Thanks, |
In reply to this post by Petr Fischer-3
If you could try the macintosh version of Sophie we would like to see
if keyboard input for accent (czech) characters is wrong, or not? Yes we know the Linux version is broken, it's just the same VM everyone uses, but we do want to confirm that the windows and macintosh version work properly. That includes typing of course, but also should include unicode characters in book names and media files. http://www.sophieproject.org/download/ Actually try the latest developer version at http://www.geeksrus.com/sophie_builds/Sophie08020601.zip Please let us know if it does not work for you. In the macintosh carbon VM to set different features refer to http://www.smalltalkconsulting.com/html/squeakinfoplist.html I traditionally ship the VM with MacRoman because otherwise the Squeak file system tools get broken. However Squeak based systems like Plopp, Sophie, Scratch, flip the system to UTF-8. Perhaps I should set the next release to UTF-8 and let people fix the file system tools... On Feb 7, 2008, at 3:52 AM, Petr Fischer wrote: > Hi, > > what is wrong with keyboard support of accent characters under > "Squeak 3.8.18beta1U" mac VM? > There is no support for VM parameters "-encoding", "-textenc", "- > eventenc" (is UTF-8 default on Mac?). > Keyboard input for accent (czech) characters is wrong. I am using > 3.1O image and WAKomEncoded39. > All accent characters entered by keyboard are treated as "Character > value: 0". > > I am really confused about international keyboard support for about > year (on linux before, on a mac now) :( > > Any tricks? Thanks, pf > > > -- = = = ======================================================================== John M. McIntosh <[hidden email]> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ======================================================================== |
In reply to this post by Petr Fischer-3
El 2/7/08 11:55 AM, "Petr Fischer" <[hidden email]> escribió: > I did the test of unix vm "Squeak-3.9-8". > > 1) If I drag&drop image on vm application bundle icon -> it hangs (and > eats 100% of cpu forever) I have 3.7b-5 and 3.7-7 of Unix VM and don't have this problem. Of the John VM I have: 3.8.8beta2, 3.8.8beta3, 3.8.10beta12 and a couple older. In Apple dealer I test drive the Mac 24" with Leopard downloading all from www.squeak.org. Don't remember which John VM , but no problem Edgar |
2008/2/7, Edgar J. De Cleene <[hidden email]>:
In 3.7-7 UTF-8 is not considered. Problems appeared after 3.9-8 in svn development (3.9-8 still worked when UTF-8 was not used in the locale machines) José L. |
In reply to this post by johnmci
2008/2/7, John M McIntosh <[hidden email]>: If you could try the macintosh version of Sophie we would like to see Tested that Sophie zip file on linux with spanish locales: - Using the default locales (LANG=es_ES.UTF-8 & LC_ALL=es_ES.UTF-8) all I get when typing "ñ", "á", "é", etc. is a "|" symbol - Changing to not utf-8 (LANG=es_ES & LC_ALL=es_ES) , I get "|" for "ñ", and "¬a", "¬e","¬i", etc. for "á", "é", "í", etc. Regards. José L. |
In reply to this post by johnmci
I tested Sophie (latest dev) bundle on Mac OS X Leopard and czech
characters. If I change font in sophie text area to Helvetica or Verdana, all czech characters are ok (keyboard input and even characters display is ok) - look at attached screenshot. This works only with Sophie.image - standard 3.9 or 3.10 image doesn't work (input & display). pf On 7.2.2008, at 19:06, John M McIntosh wrote: > If you could try the macintosh version of Sophie we would like to > see if keyboard input for accent (czech) characters is wrong, or not? > > Yes we know the Linux version is broken, it's just the same VM > everyone uses, but we do want to confirm that the windows and > macintosh version > work properly. That includes typing of course, but also should > include unicode characters in book names and media files. > > http://www.sophieproject.org/download/ > > Actually try the latest developer version at > > http://www.geeksrus.com/sophie_builds/Sophie08020601.zip > > Please let us know if it does not work for you. > > In the macintosh carbon VM to set different features refer to > http://www.smalltalkconsulting.com/html/squeakinfoplist.html > > I traditionally ship the VM with MacRoman because otherwise the > Squeak file system tools get broken. > > However Squeak based systems like Plopp, Sophie, Scratch, flip the > system to UTF-8. > > Perhaps I should set the next release to UTF-8 and let people fix > the file system tools... > > On Feb 7, 2008, at 3:52 AM, Petr Fischer wrote: > >> Hi, >> >> what is wrong with keyboard support of accent characters under >> "Squeak 3.8.18beta1U" mac VM? >> There is no support for VM parameters "-encoding", "-textenc", "- >> eventenc" (is UTF-8 default on Mac?). >> Keyboard input for accent (czech) characters is wrong. I am using >> 3.1O image and WAKomEncoded39. >> All accent characters entered by keyboard are treated as "Character >> value: 0". >> >> I am really confused about international keyboard support for about >> year (on linux before, on a mac now) :( >> >> Any tricks? Thanks, pf >> >> >> > > -- > = > = > = > = > = > ====================================================================== > John M. McIntosh <[hidden email]> > Corporate Smalltalk Consulting Ltd. http:// > www.smalltalkconsulting.com > = > = > = > = > = > ====================================================================== > > > > |
In reply to this post by José Luis Redrejo
As mentioned for Linux we use the current Unix VM source, if that
doesn't work, well then it doesn't work, if someone can point to a source tree that works for Linux we'll use it. On Feb 7, 2008, at 12:31 PM, José Luis Redrejo wrote: > Tested that Sophie zip file on linux with spanish locales: > - Using the default locales (LANG=es_ES.UTF-8 & LC_ALL=es_ES.UTF-8) > all I get when typing "ñ", "á", "é", etc. is a "|" symbol > - Changing to not utf-8 (LANG=es_ES & LC_ALL=es_ES) , I get "|" for > "ñ", and "¬a", "¬e","¬i", etc. for "á", "é", "í", etc. > > Regards. > José L. > -- = = = ======================================================================== John M. McIntosh <[hidden email]> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ======================================================================== |
In reply to this post by Petr Fischer-3
On Feb 7, 2008, at 12:53 PM, Petr Fischer wrote: > I tested Sophie (latest dev) bundle on Mac OS X Leopard and czech > characters. > > If I change font in sophie text area to Helvetica or Verdana, all > czech characters are ok (keyboard input and even characters display > is ok) - look at attached screenshot. This works only with > Sophie.image - standard 3.9 or 3.10 image doesn't work (input & > display). > > pf To clarify the Sophie.app uses a 3.8.18beta2U VM. Which is the same as the 3.8.18beta1U VM (with a change to the locale plugin). So the fact it does not work properly with a 3.9 or 3.10 image is not a VM issue, it's an issue in the image code. One has to pull the data from the unicode event field, and use a font that will display unicode characters. I cannot speak for 3.10 but older images would pull the keyboard data from the macroman event field and display that using fonts mapping to the macroman character set. If you try to use characters that do not map into that limited set, then it won't work. Technically the macintosh carbon VM works with unicode data from keyboard entry services. After the user had entered one or more keystrokes to make a character you end up with one or more unicode characters we take each unicode character and translate to MacRoman then pass in the event record the unicode value and the MacRoman character. If there is not a unicode to macroman mapping the macroman character will be zero. PS For those few still using the OS-9 (or earlier) version of the macintosh squeak VM we get the macroman character from os-9 and use a static internal table to map the macroman to unicode, this table was generated from os- x translation services. = = = ======================================================================== John M. McIntosh <[hidden email]> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ======================================================================== |
In reply to this post by José Luis Redrejo
José, danil and everybody,
I was looking into the issue but got side-tracked. I'm not ignoring it but just taking long time. On XO, a composition character comes in as a separated character code (the Unicode code point), and the semantics is that the application composes the composition character to the character in front of it. The ParagraphEditor in the Etoys image is modified so that as long as the resulting character has a valid code point, these two characters are replaced with the resulting accented character. In the other words, it is a postfix manner. On typical Linux installation, however, the accent is prefixed. The keys are interpreted by scim or something but the Squeak VM doesn't handle it. There is a proposed patch for Japanese as well, and I'd like to merge it and along the line, I'd like to fix the accented character cases. -- Yoshiki |
In reply to this post by johnmci
>>>>> "John" == John M McIntosh <[hidden email]> writes:
John> I cannot speak for 3.10 but older images would pull the keyboard data John> from the macroman event field [...] I can't believe the number of times I had to re-read that before I didn't parse it as "macro-man". And then wondered what this macro "man" stuff was all about. :) -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <[hidden email]> <URL:http://www.stonehenge.com/merlyn/> Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training! |
In reply to this post by johnmci
On Feb 7, 2008, at 22:44 , John M McIntosh wrote: > > On Feb 7, 2008, at 12:53 PM, Petr Fischer wrote: > >> I tested Sophie (latest dev) bundle on Mac OS X Leopard and czech >> characters. >> >> If I change font in sophie text area to Helvetica or Verdana, all >> czech characters are ok (keyboard input and even characters >> display is ok) - look at attached screenshot. This works only with >> Sophie.image - standard 3.9 or 3.10 image doesn't work (input & >> display). >> >> pf > > > To clarify the Sophie.app uses a 3.8.18beta2U VM. Which is the same > as the 3.8.18beta1U VM (with a change to the locale plugin). > So the fact it does not work properly with a 3.9 or 3.10 image is > not a VM issue, it's an issue in the image code. > > One has to pull the data from the unicode event field, and use a > font that will display unicode characters. > I cannot speak for 3.10 but older images would pull the keyboard > data from the macroman event field > and display that using fonts mapping to the macroman character set. > > If you try to use characters that do not map into that limited set, > then it won't work. This is only half the story why it does work. The other half is that Sophie uses the Freetype plugin for rendering system fonts. The fonts shipped in Squeak are only 8 bit and thus do not cover the Unicode range. - Bert - |
Yes, it's long story... definitely...
Is there any plan to make necessary changes in Squeak (3.11, 3.12... 4.0)? Thanks to all for informations, pf On 8.2.2008, at 9:41, Bert Freudenberg wrote: > > This is only half the story why it does work. The other half is that > Sophie uses the Freetype plugin for rendering system fonts. The > fonts shipped in Squeak are only 8 bit and thus do not cover the > Unicode range. > > - Bert - > > smime.p7s (3K) Download Attachment |
Petr Fischer a écrit :
> Yes, it's long story... definitely... > Is there any plan to make necessary changes in Squeak (3.11, 3.12... 4.0)? Yes, i think this should be the only task of the 3.11 version. Nothing fancy, but definitely needed ... We only need the ressources : people who can test the different keyboards and people who can patch all the VMs, some documentation to show how to adapt Squeak to your specific keyboard input. I think we need to have short time between releases, something like 6 months with a few selected tasks for each releases. I vote for complete Unicode support (including UTF-8 keyboard input) for next version. I just found that Ruby will only include full Unicode support in the next version ... No more big plans or revolutionary stuff than can't be achieved. Best regards, -- Serge Stinckwich http://doesnotunderstand.free.fr/ |
2008/2/8, Serge Stinckwich <[hidden email]>: Petr Fischer a écrit : Sorry, but I still can not understand why the images 3.6, 3.7, 3.8,3 .9 & 3.10 work with accents on the windows vm and they don't do it using current unix vm, but work (without using utf-8) using older unix-vm. After all this long thread I still can not see why it has to be fixed in the image, thus condemning all the previous squeak images on unix, and not fixed in the vm as windows vm has done, letting windows users choose any image and work with it without most problems. It does not sound logical. Why the unix vm can not do what Andreas did: "The Windows VM should not report dead keys itself but rather the composed character" ? That would solve everything and all the past & present images would work. Cheers. José L. |
The original idea of i18n (is it now correct? :)) for squeak seemed to sound as "let's accept the imperfect world of VM differences and handle everything on the smalltalk side". That was the origin for LanguageEnvironment logic, when the instance tries to detect the system it is running upon and then installs custom handlers for keyboard/clipboard/filesystem. It worked for knowledgeable and persistent folks. But. I looked at the accent input on linux yesterday again and now I'm sure that it can not be cleanly handled in terms of current LanguageEnvironment infrastructure. That is, one has to patch event processing outside of InputInterpeter. A changeset for the image if provided will be a definite hack. The VM has to be fixed (assuming that the image side internationalization is considered to be stable).
Yes it would be great. No standard existed for the protocol of keyboard events between the VM and the image. To me, it would be much, much nicer if it was something well-defined and shared between platforms like ucs4 pointcode. The major move happened but we still not there. cheers, Danil
|
In reply to this post by SergeStinckwich
I strongly agree with that! Let we solve Unicode support ones for ever!
There are more and more people coming to Squeak from all parts of the world and making Squeak truly international is therefore a must. Otherwise will go elsewhere. Janko Serge Stinckwich wrote: > Petr Fischer a écrit : >> Yes, it's long story... definitely... >> Is there any plan to make necessary changes in Squeak (3.11, 3.12... >> 4.0)? > > > Yes, i think this should be the only task of the 3.11 version. Nothing > fancy, but definitely needed ... We only need the ressources : people > who can test the different keyboards and people who can patch all the > VMs, some documentation to show how to adapt Squeak to your specific > keyboard input. > > I think we need to have short time between releases, something like 6 > months with a few selected tasks for each releases. I vote for complete > Unicode support (including UTF-8 keyboard input) for next version. > I just found that Ruby will only include full Unicode support in the > next version ... > > No more big plans or revolutionary stuff than can't be achieved. > > Best regards, > -- > Serge Stinckwich > http://doesnotunderstand.free.fr/ > > > -- Janko Mivšek AIDA/Web Smalltalk Web Application Server http://www.aidaweb.si |
In reply to this post by José Luis Redrejo
José Luis Redrejo wrote:
> Sorry, but I still can not understand why the images 3.6, 3.7, 3.8,3 .9 > & 3.10 work with accents on the windows vm and they don't do it using > current unix vm, but work (without using utf-8) using older unix-vm. Because that was not done via unicode but as part of the MacRoman-ish interpretation of keyboard input. What we would need to not break backward compatibility is some extra VM parameters that would let the image know, if the VM supports Unicode. (Don't we already do that for the unicode file path handling?) Then updated images on an updated VM could make use of the unicode values in slot 6 of input event without breaking the older ones. That would allow us to make older images 3.8.x, 3.9.x etc work for unicode. Michael |
In reply to this post by Danil Osipchuk-2
> The VM has to be fixed (assuming that the image side
> internationalization is considered to be stable). Yes on Unix, and even on "Unix" there are different convensions. The VM should take care of them. -- Yoshiki |
Free forum by Nabble | Edit this page |