Japanese Tcl
Ron Natalie
Despite the HYPE on the scriptics web page, there seems to be no real support
for it in 8.1 and I have a feeling that the JP patches for earlier tcl are
incompatible with the new UTF-8 baseline.
Feel free to post or email (r...@sensor.com)
Bill Schongar
>If anybody is using Tcl 8.1 with Kanji, I would really like to talk to them.
Right now we're using 8.1 with almost everything.. including
Japanese, Simplified Chinese, and Traditional Chinese.
Everything works just as expected, though I should quantify it
and say we're using the 8.1 message catalog facility with
Unicode strings.
The only thing that could have made my life easier would have been
a copy of native2ascii shipped with Tcl. ; )
-Bill
Ron Natalie
I found the problem. Tcl expects the source code to be in what it thinks the
system encoding is, which wasn't necessarily UTF-8.
lvi...@cas.org
According to Ron Natalie <r...@sensor.com>:
:I found the problem. Tcl expects the source code to be in what it thinks the
:system encoding is, which wasn't necessarily UTF-8.
Also, I would recommend that you upgrade to Tcl 8.2.1 to avoid rediscovering
the various bugs that have been fixed in the past 6+ months since 8.1
was released.
--
<URL: mailto:lvi...@cas.org> Quote: Save us from the snobs.
<*> O- <URL: http://www.purl.org/NET/lvirden/>
Unless explicitly stated to the contrary, nothing in this posting
should be construed as representing my employer's opinions.
Ron Natalie
lvi...@cas.org wrote:
>
> According to Ron Natalie ?r...@sensor.com?:
> :I found the problem. Tcl expects the source code to be in what it thinks the
> :system encoding is, which wasn't necessarily UTF-8.
>
> Also, I would recommend that you upgrade to Tcl 8.2.1 to avoid rediscovering
> the various bugs that have been fixed in the past 6+ months since 8.1
> was released.
>
Have the i18n and XIM patches that came out for 8.1 been applied to 8.2?
Jeffrey Hobbs
Could you please be more specific as to what the patches referred to?
In our bug/rfe database, I can't find anything with "XIM" or "i18n".
There have been some fixes in that area, but I'm not sure what you are
referring to specifically.
--
Jeffrey Hobbs The Tcl Guy
jeffrey.hobbs at scriptics.com Scriptics Corp.
Victor Wagner
: lvi...@cas.org wrote:
:>
:> According to Ron Natalie ?r...@sensor.com?:
:> :I found the problem. Tcl expects the source code to be in what it thinks the
:> :system encoding is, which wasn't necessarily UTF-8.
:>
:> Also, I would recommend that you upgrade to Tcl 8.2.1 to avoid rediscovering
:> the various bugs that have been fixed in the past 6+ months since 8.1
:> was released.
:>
: Have the i18n and XIM patches that came out for 8.1 been applied to 8.2?
As far as I know (from reading latest plus patch) i18n patch is very
weird thing to use. Tcl 8.2.0 does much better job of setting locale
than i18n patch.
First, i18n patch sets LC_TIME to C. Why? I suppose that using native
date format is a right thing (tm).
Really, clock format should have -locale switch, to be able to produce
both formats, but default should be current locale. Dates with textual
month and weekday names are meant for humans, not for machine reading.
And clock scan would recognize at least one numeric-only format -
mm/dd/yyyy. Second, it does something strange with LC_CTYPE. Of course,
LC_COLLATE is not relevant to tcl 8.1+ at all, becouse it uses Unicode
for sorting, but LC_CTYPE is required by Xkb, which is almost only
"localization" thing which this patch tries to address, but in my
opinion, core does it better now.
Really, I think that good way to go is to have compile-time option to
throw away all the complicated guessing stuff in TclpInitEncoding and
use nl_langinfo(CODESET), if available. It would 100% solve a problem
on XPG4 compliant systems, including glibc 2.1 (and 2.0 if configure
would be clever enough to substitute _NL_CTYPE_CODESET_NAME for CODESET)
Hmm, one more feature suggestion - -locale switch to format command,
which would allow to use local LC_NUMERIC convention.
Having format command to switch locale tempoarily would be enough to
create any human readable output which is needed, without breaking all
existing Tcl code which would still use LC_NUMERIC=C.
--
Victor Wagner @ home = vi...@wagner.rinet.ru
I don't answer questions by private E-Mail from this address.
Ron Natalie
Does 8.2 support the input methods (mods were made to tkUnixKeys plus adding
and additional tkUnixIm.c).
Jeffrey Hobbs
something for that, that the same guys provided. Since we do not
have such systems here to test on, we don't really know how and
when it would/should work.
--
Scott Redman
for Tcl 7.x. If the code isn't working, let us know.
-- Scott
Y. Cheng
> There is some stuff #define'd by TK_USE_INPUT_METHODS that means
> something for that, that the same guys provided. Since we do not
> have such systems here to test on, we don't really know how and
> when it would/should work.
The code in Tk8.2 won't work after some test.
I am working on a patch to make it work
(on my language, traditional chinese, using xcin, see
http://xcin.linux.org.tw/).
I am also testing xim feature in tk8.2.0puls (which you can find it
on http://home.wxs.nl/~nijtmans/plus.html)
Well, I started hacking tk code two weeks ago and are not very good
at it yet. But I also hope that you want to fix the code there.
Do you want to setup a xim server to test tk8.2. I have experience
on how to setup xcin (a xim server for chinese) on both freebsd and
redhat linux. (in face, freebsd 3.3 have xcin port and the document
in xcin is clear enough to help setup xcin on linux). I am very willing
to help if you want to work on this.
Yuan-Chen Cheng
Y. Cheng
> Some changes were made based on the Japanization patches
> for Tcl 7.x. If the code isn't working, let us know.
> -- Scott
Do you mean tk8.2.1 ?
I am sure that the code in tk8.2 won't work with Chinese xim server.
(I think it won't work with japanese xim server also)
Yuan-Chen Cheng
Scott Redman
missing.
You should base your changes off of 8.2.1, there were some other
bug fixes that you might want.
-- Scott
Y. Cheng
> No, I actually meant 8.1+. There might still be something
> missing.
Do you mean tk-8.2.0plus or 8.1plys ?
After I try to use tk-8.2.0plus with xcin2.5.x (A Chinese input server
use XIM protocal), basically I can input big5 (A traditional chinese character
encoding which most people in Taiwan Use) into entry but with some but.
I find that as the mouse is not on the entry widget window, I can not
key in chinese character but I *can* key in English character.
I once modify tk8.2 code to some situation that as the mouse is *not* on the
entry window, I *can* key in Chinese. But as the mouse is on the entry window,
I can *not* key in Chinese character instead.
I am not sure that if this is a bug of xcin. I just want to know whether
using japanese input method with tk-8.2.0plus have similar problem ?
I also find out some way to make the problem in my modification to
tk8.2 works with xcin2.5. There are two key point to my modification:
1. I change the strage of creating XIC from one XIC per window to one XIC
per "wrapper window for a toplevel window" (quotes from tkUnixWm.c, the
comment of CreateWrapper).
2. In order to key in chinese as mouse point in on Entry widget, I remove
KeyPressMask and KeyReleaseMask from ALL_EVENT define in tkWindow.c
and add the two mask to wrapperPtr->atts.event_mask on
static void CreateWrapper(wmPtr)
in file tkUnixWm.c
I don't know if this modificaion will cause other problem or break some
design of event passing mechanism on tk8.2. But it seems work fine.
BTW: now xcin only support XIM "Root" input_style, and my modificaion
to tk8.2 only work with "Root" input_style only (I think).
> You should base your changes off of 8.2.1, there were some other
> bug fixes that you might want.
My previous modificaion to tk is base one tk8. I will switch to tk8.2.1
if you think my direction is not too wrong.
Y. Cheng
Ron Natalie
which was integrated in 8.2.1. There is code that watches the regular X focus
(with some odd checks for mouse position) to switch the XIM focus.
-Ron
Ron Natalie
Jeffrey Hobbs wrote:
>
> There is some stuff #define'd by TK_USE_INPUT_METHODS that means
> something for that, that the same guys provided. Since we do not
> have such systems here to test on, we don't really know how and
> when it would/should work.
The TK_USE_INPUT_METHODS doesn't work at all in 8.2.1 and it appears
to be materially different from that provided in the patch for 8.1.1
from ftp.sra.co.jp. I've just blown the better part of a day verifying
that. I'm going to manually merge the patches to the new code.