Re: [tlug] Japanese input in aterm

[Scott <scottro@example.com>]

On Mon, Mar 01, 2004 at 03:28:21PM +0900, Stephen J. Turnbull wrote:
> >>>>> "Scott" == Scott  <scottro@example.com> writes:
> 
>     Scott> Recently, I began using aterm
> 
> What's aterm, I mean, is it part of a group of more or less related
> apps, like the e- series?  Most important, is it dependent on GNUMB or
> KiDding-mE?  If so, there are probably IM-related tweaks I don't know
> about, and all of the below may be irrelevant.

Originally designed for AfterStep users, it's based on rxvt.  Supposedly
its advantage is that it's designed for faster transparency (which I
don't use) and also, supposedly, not tied to AfterStep or (according to
FreeBSD pkg-descr) not tied to any libraries.


>     Scott> Next, I tried building it in Arch Linux.  After reading the
>     Scott> README.config I chose --enable-kanji.  However, when called
>     Scott> it with my langx script, I get a white box towards the
>     Scott> bottom of the screen where I can input the kanji.  However,
>     Scott> after inputting kanji nothing appeared in aterm.
> 
> You might want to publish the langx script (again, if you did it
> before).

My apologies--so many newcomers wind up getting sent to my pages on
inputting Japanese that I got lazy.  (Should add that one of my earliest
mentors got me in the habit of ending script names with an x rather than
.sh)

In Arch 

#!/bin/bash
XMODIFIERS="@example.com=kinput2" LC_CTYPE=ja_JP ${1+"$@"} &

The script varies from distribution (and O/S, eg Net and FreeBSD) but
this works in Arch with rxvt.
> 
> This sounds like it's probably an X Input Method (XIM) issue.  XIM is
> an excessively complex and even so inadequate standard.  :-(  There are
> several possible problems.
> 
> (1) You need to have an input manager (traditionally kinput2 for
> Japanese) and often a backend processor (eg, Wnn or Canna) running _at
> startup_ of the *term.  Recent apps may know how to get them started,
> but it's not part of the XIM standard, and can't work seamlessly in a
> distributed environment, so most apps don't try.


No, both are already running.  (I see I left out various information
that I should have put in the original post, I'll answer them in
line--that is one of things I should have mentioned).
> 
> (2) You need to have the Unix environment set up correctly.  This
> means the LANG, LC_ALL, or (usually) LC_CTYPE variables, which are set
> to implementation-dependent locale strings.  It _may_ matter whether
> you set it to "ja", "ja_JP", or "ja_JP.eucJP" (or other Japanese-
> capable encoding), and I have seen installations where ja_JP worked
> but neither ja nor ja_JP.eucJP worked (notwithstanding that kinput2
> and Canna were configured to generate EUC-JP!)


As mentioned above, ja_JP works in Arch.  (Sidebar--in FreeBSD 4.x it
was ja_JP.EUC in 5.x it's ja_JP.eucJP--that might work in 4.x as well,
but ja_JP.EUC doesn't work in 5.x)
> 
> You must also have the XMODIFIERS variable set correctly.

Heh, did Jonathan tell you about the day I sent a grouchy email about
how it didn't work in Deb, to send an abashed one 20 minutes later
because I'd typed XMODIFIRES?

The langx script works with rxvt.
> 
> (3) You want to have the X environment set up.  One of the
> unnecessarily complex aspects of XIM is the setup of the IM's UI.
> You can do input on the root window, in a dedicated subwindow of the
> app, or "over" the spot, all of which basically create a window for
> XIM to use as a sandbox, or you can do "on" the spot input, in which
> case the app must provide callbacks to XIM to help it draw the text.
> 
> It sounds to me like you need to set a resource in aterm to get it to
> use over-the-spot preediting.  Here's the doc for the corresponding
> resource in KTerm (no guarantee that Aterm will call it the same
> thing, unfortunately---look in the /usr/X11R6/lib/app-defaults/Aterm
> file on the distros that work; nb, capitalization of ATerm may vary).

Ok, that is a start (don't have time to do it at this instant, going to
work, but that is one place I haven't looked)
> 
>    preeditType (class PreeditType)
>        Specifies  the input styles using XIM protocol in the form of a
>        comma separated list.  Currently, ?$B!F!FOverTheSpot?$B!G!G and  ?$B!F!FRoot?$B!G!G
>        are supported.  The default is ?$B!F!FOverTheSpot,Root.?$B!G!G
> 
> 
> I don't think this has anything to do with getting aterm to accept
> input, though.
> 
> 
>     Scott> In general, I usually just set LC_CTYPE to Japanese.
> 
> AFAIK language names are an implementation-dependent extension; try
> the POSIX-style "ja", "ja_JP", and "ja_JP.eucJP" as well.

I will try playing with that as well.  I thought it wouldn't be
relevant, however, as rxvt does give proper input.  (I think that's
something else I neglected to mention in my original post).

> 
> "Of course, since you know it works in Debian, why not just switch?"

Because Arch is a nice new distro with fewer packages and less
stability, so let's throw it on all the mission critical servers.  :)

Because ~everything~ "just works" in Deb, which is boring.  

Thank you, as always.
 
You've given me something to check.  In NetBSD, with rxvt one
has to tweak the app-defaults/Rxvt file to get it to work (though they
tell you this at installation).


-- 

Scott Robbins

PGP keyID EB3467D6
( 1B48 077D 66F6 9DB0 FDC2 A409 FA54 D575 EB34 67D6 )
gpg --keyserver pgp.mit.edu --recv-keys EB3467D6

Willow: The only solution is the final solution.
Xander: Nuke the school? I like that.
Willow: Not quite. Exorcism.
Cordelia: Are you crazy? I saw that movie. Even the priest died.

Attachment: pgp00018.pgp
Description: PGP signature