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 WikiSqueak.png (37K) Download Attachment |
Hi Andreas,
On Fri, Jul 31, 2009 at 8:57 AM, Andreas Raab<[hidden email]> wrote: > 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. cool. :-) > 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. Personally, I would prefer #2, as it is very lean. I agree there is a problem with portability. Perhaps #3 is the best solution (most pragmatic). In HTML/CSS, there are font "names" like "sans-serif" that just denote a standard font - whatever it might be. If a concrete font name is given instead ("Arial"), that one is used, otherwise, "sans-serif" just falls back to the default (which might be "Arial" as well). Perhaps something like this would make some sense? Of course, it would imply quite some effort to maintain the required font maps. Anyway. It's just an idea. Best, Michael |
In reply to this post by Andreas.Raab
Hello Andreas and all,
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.
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 <[hidden email]> wrote: Folks - |
Nikolay Suslov wrote:
> 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. 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 ;-) 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 <[hidden email] > <mailto:[hidden email]>> 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 > > > > > > ------------------------------------------------------------------------ > > |
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 On Sat, Aug 1, 2009 at 8:10 AM, Andreas Raab <[hidden email]> wrote:
MacUnicodeInputInterpreter-initialize.st (700 bytes) Download Attachment |
Free forum by Nabble | Edit this page |