XIM is working very well with the CSI (code-set independent) version of xterm
provided by Li18nux.org (patches from IBM). It works equally well in our UTF-8
locales and our non-UTF-8 locales. Because of this (CSI), Sun will be adopting
this version of xterm, rather than the utf-8 hardwired one, for a future release
of Solaris. We are working with the patch developers to enhance and extend this
implementation to make it a fully functional, code-set independent,
internationalized terminal emulator. We will, obviously, be providing these
enhancements back to the community, and Sun will be promoting this xterm at
X.Org as well. I also encourage the Xfree86 community to strongly consider the
value of a code-set independent version of xterm, since there are many Linux
platforms with non-utf8 international locales which will benefit from an
implementation which works cleanly with both the encoding and the input methods
of those locales.
-steve
P.S. I agree with Owen's sentiments about XIM, and Sun strongly encourages the
use of IIIM as an alternative. On our platform, and in the X11 I18n code we
have and continue to provide to the open source community, the two are
intermingled, to try to get the best of both worlds.
>X-Authentication-Warning: engmail2.Eng.Sun.COM: noaccess owned process doing
-bs
>X-Authentication-Warning: engmail2.Eng.Sun.COM: noaccess@localhost didn't use
HELO protocol
>To: [EMAIL PROTECTED]
>Subject: Re: [I18n]xterm-158, XIM and UTF-8
>From: Owen Taylor <[EMAIL PROTECTED]>
>Date: 12 Sep 2001 12:58:47 -0400
>User-Agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/20.7
>MIME-Version: 1.0
>X-BeenThere: [EMAIL PROTECTED]
>X-Mailman-Version: 2.0beta2
>List-Id: XFree86 Internationalization <i18n.XFree86.Org>
>
>
>Juliusz Chroboczek <[EMAIL PROTECTED]> writes:
>
>> >> However, XIM support imposes that we use font sets, thus pulling in
>> >> a whole new range of bugs.
>>
>> TK> Are you saying that nothing should be added to XTerm?
>>
>> No. I am not objecting to the use of fontsets. I am objecting to the
>> facts that XIM (i) imposes the use of a specific output mechanism, and
>> (ii) makes it visible to the application. (Either of those alone
>> would be an issue, but XIM has both.)
>>
>> Think of a client that never sees core fonts or fontsets, but only
>> uses RENDER client-side fonts, or DPS fonts, or GL pseudo-fonts, or
>> whatever. It should be possible to write such a client with no
>> reference to core fonts or fontsets; but XIM precludes this. In other
>> words, your choice of input mechanism imposes that you must use a
>> given output mechanism. I consider this a design flaw in XIM.
>
>Only for the over-the-spot input style. You can use on-the-spot
>and root-window input styles with XIM without encountering this
>problem, and that's what GTK+-2.0 does.
>
>(XIM has other issues, and hopefully we'll see a move to something
>better, perhaps IIIMF, someday. But certainly its possible to
>use XIM without using over-the-spot rendering.)
>
>Regards,
> Owen
>_______________________________________________
>I18n mailing list
>[EMAIL PROTECTED]
>http://XFree86.Org/mailman/listinfo/i18n
Steve Swales
Senior Manager, Platform Globalization Engineering
X.Org Chairperson and Sun Representative
Sun Microsystems, Inc.
901 San Antonio Road, MS USJC07-201
Palo Alto, CA 94303-4900
408 635-0623 Direct
[EMAIL PROTECTED]
_______________________________________________
I18n mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/i18n
