Multilingual and Asian input methods

On Sat, Oct 22, 2005 at 04:23:04PM -0400, Edward H. Trager wrote:
> 
> If C++ is a double-edged sword, then I have to say that C is also a
> double-edged sword, perhaps even more so than C++ itself.  I was just trying
> to point out that the code and the API of SCIM are nice and clean, which
> should be a benefit to developers who want to add new input methods to
> SCIM's already impressive collection.  And it does appear that one of the
> reasons for SCIM's popularity is that it is easy for developers to add new
> Input Methods to SCIM.

Yes I completely agree that one good thing about SCIM is its
extensibility.  Besides writing new input method engines, others can
also write a simple based input method table (used by scim-tables or
scim-m17n), or write a simple bridge module to connect scim to a already
existent input method program (e.g.  scim-uim, scim-anthy, scim-fcitx,
etc.)

> But I was not aware of the problem with segfaults that you mention.
> However, I wonder what the true origin of those segfaults is?  Is it
> really a SCIM problem, or a GTK problem, or is the real problem having
> two different versions of libstdc++ installed at the same time?  

I'm by no means experts on this, but from what I read in the discussion
(linked from the bug report I mentioned), the problem is quite
complicated.  GTK+ applications can load plugins at runtime, so it can
pull in two plugins written in C++, even two plugins link to different
libstdc++ (.5 and .6).  In principle, versioned symbols in libstdc++
should make this possible without problems (both libstdc++5 and
libstdc++6 in Debian are compiled with versioned symbols), but somehow
GCC leaked some unversioned symbols into the libstdc++ library, so now
if you link to different versions of libstdc++, you are likely to go
into trouble.  It may be less a problem in Ubuntu, but you still face
it with third-party softwares (Adobe reader, Realplayer, Firefox from
mozilla.org, etc.).

> I actually don't know!  I just discovered this functionality last week on
> a new installation of SuSE 10.0 on a workstation at work.  So I assume it is
> a fairly recent version.  I'll have to check next week at work.

Then it is most likely the new zh_CN <-> zh_TW conversion feature in
scim 1.4.  The main upstream scim author works for SuSE, after all. :-)

(I am subscribed to this list, so please don't cc: me, thanks.)

Ming
2005.10.22