Andreas,
Yes, on Windows it works as it should be!
For Mac users I attached the corrected MacUnicodeInputInterpreter initialize method.
There was wrong MacVM Unicode support checking, and so unicode did not work correctly at 4 versions. But it is like "win32vmSupportsUnicode", may be just use (evtBuf at: 6) explicitly.
Regards,
Nikolay
Nikolay Suslov wrote:Thanks, this is great. It's now in the trunk, could you update and verify everything is working at it should? I made one change that is taking out the test for win32vmSupportsUnicode - since I don't expect to go back to not supporting it I think it's fair that going forward we expect the VMs to support Unicode ;-)
I have tried to manage multilanguagual keyboard input to work also.
The needed changes are taken from the current EToys image.
So, the Multilingual-Support-FromEToys package is in the http://source.squeak.org/inbox/, for now it includes just Russian language environment.
Cheers,
- Andreas
To have the Russian keyboard input working you need:
1. Update the image from trunk with the latest Andreas changes for fonts, install font Arial, for example:
TTFileDescription installFamilyNamed: 'Arial'.
2. Load Multilingual-Support-FromEToys.mcz from the Inbox, like:
MczInstaller installStream:
(HTTPSocket httpGet: 'http://source.squeak.org/inbox/Multilingual-Support-FromEToys-sn.2.mcz' ).
3. Execute in the workspace:
EncodedCharSet initialize.
LanguageEnvironment resetKnownEnvironments.
Locale switchToID: (LocaleID isoLanguage: 'ru').
Thanks,
Nikolay Suslov
------------------------------------------------------------------------On Fri, Jul 31, 2009 at 10:57 AM, Andreas Raab <andreas.raab@gmx.de <mailto:andreas.raab@gmx.de>> wrote:
Folks -
I just finished a bit of work for supporting Truetype fonts directly
from disk which will make it quite a bit easier to support non-latin
languages. If you update your 3.10.2-trunk image, you will get
support for TTFileDescription which is polymorphic with
TTFontDescription but leaves the files on disk instead of reading
them into memory and wasting tons of space. The attached picture
shows a couple of Squeak Wikipedia entries rendered in Batang (a
standard font on Windows which is 16MB on disk and would be, oh, I
don't know, *big* if loaded into memory ;-)
One of the nice effects is that because the files are left on disk,
you can access your native platform fonts virtually for free (except
that it affects portability of the image). The font menu in text
morphs (Cmd-k/Alt-k) has consequently been extended to include a
"More (non-portable) Fonts..." entry which now gives you access to
all of the TTFs that we can find. The current list of search paths
for fonts is hardcoded in TTFontDescription>>fontPathsDo: - if we're
missing some, please add them in (this was mostly guesswork).
An open question at this point to me is what the right combination
of fonts for the next release might be. As far as I can tell, we
have three basic choices:
1) Ship all the fonts with the image. Either Vera and friends
in-memory, or Dejavu on disk. Nice and self-contained, but eats space.
2) Use all the fonts on the platform. Drop Vera and instead give
people access to local fonts. Compact, but makes images less portable.
3) Do some combo of having a certain set of fonts in the image, for
example Vera for basic LGC coverage and use platform fonts for the
rest. Compact and portable unless you need the extended fonts.
Any preferences? Opinions? Also, I'm interested in finding fonts
that don't work. Those of you who have "interesting" fonts /
scripts, if you could run a
TTFileDescription loadAllFontFiles.
to see if any of them blow up, that would be greatly appreciated.
And of course any other comments, questions, and suggestions are
welcome.
Cheers,
- Andreas