multilingual support and external glyph

ohshima at is.titech.ac.jp ohshima at is.titech.ac.jp
Sun Dec 5 13:31:59 UTC 1999


  Hi John (Duncan),

  I think we need two different implementations for
multilingual support.  One is that similar to current
tactics, to keep the dependency to the external resources
minimum as possible.  Another is to use the external
resources when applicable.

  The former preserves the portability and the
dot-by-dot-identity across the platforms, while the latter
enables to write the platform dependent application in
efficient way.

> Speaking of multilingual support, Microsoft has released the input
> method editor for the web for CJK.  I wonder what it would take to
> associate this with the VM.  It would make multilingual testing much
> easier and much less problematic than building an IME for Squeak at
> this time.  Does Apple have a similar global IME?  I'm not sure if the
> Windows one is documented yet.  Perhaps I will look into it this
> weekend.

  It sounds interesting.  Writing IME in Squeak could be
done in several way.  One is writing it completly in Squeak,
and another is implementing the network protocols for
converting characters such as XIM (X Input Method) or KKCP
(Kana-Kanji Conversion Protocol) by using Squeak Socket.  In
the latter case, we can share the "kana-kanji dictionary"
with other applications (or even other people) and we don't
have to carry big (?) dictionary within the image.

# we could write the conversion server in Squeak, of course.

  I don't know the Microsoft one (what does "for the web"
means?) you mentioned, but if it can be used from Squeak
(probably by adding primitives), it is possible to share the
dictionary with other applications on Windows, and the user
might want to do so.

> Also, I think the multilingual support will be easier to handle if we
> develop a way to access external fonts seamlessly.  Currently, one
> must do it the hard way, importing large bitmaps into Squeak as fonts.
> However, Postscript and TrueType CJK and Unicode fonts do exist, as
> well as local hard fonts on certain platforms, such as Zaurus, etc.
> If I can work out my font cache, it should make it a lot easier to
> rasterize these fonts and display them very quickly with a minimum of
> space req.  In the case of the palmtops, it would be better to use the
> display support from the operating system, in order to conserve space.
> There should be some interesting problems to look into.

  I agree.  Getting glyphs from OS or other place will help
a lot when we write a platform specific application (or
framework to write a platform specific application).

  Using the OS function for text display seems too
aggressive and not to save much memory (is it possible to
remove 'form' instance variable from DisplayText?), but
combining hardware glyph and font cache is difinitely
promising for writing Zaurus application in Squeak.

  -- Yoshiki

P.S.
  Thank you for mentioning the multilingual support in
c.l.s!





More information about the Squeak-dev mailing list