Re: tlug: Linux and Japanese

["Stephen J. Turnbull" <turnbull@example.com>]

--------------------------------------------------------
tlug note from "Stephen J. Turnbull" <turnbull@example.com>
--------------------------------------------------------
>>>>> "john" == john wood <jyonw@example.com> writes:

    >> All you want is Japanese email with a GUI mailer?  I got the
    >> impression from Craig's mail that you were looking for a
    >> general solution for *all* apps.

    john> well, id like that too.. :) heh.. who wouldn't?  But what I
    john> really want its a Japanese interface to 1) Some kind of word
    john> processor (JVIM is fine, but a GUI one would be even better)

If you're looking for serious officeware, and willing to fork out $$$,
Applixware's Japanese is considering a port of Applixware to Japanese
Linux; right now, it may be possible to run Applixware targeted to a
commercial platform using iBCS.

Free, more general purpose software:  I'm an Emacs/TeX addict (never
would have guessed, huh?) so I can't help much on this.  (That
apparently being not what you want to do.)  Emacs/Mule also solves the 
email problem but it's not GUI.

    john> Well Im not a fan of Pine (the menus drive me nuts) so I
    john> would love to use Elm for Japanese (and all the rest) of my

I forget where I got the patches; Elm itself comes from ftp.uu.net.
Try Elm-j or j-elm in one of the Web searchers or archie.

    john> mail.. I tried to get that small little Xelm to compile but
    john> it wouldnt go.. that would be even better :)

    john> just exactly where? do you know the names of the sites etc?

This is the X11 contrib distribution, available on any complete X11
CD-ROM or by ftp (start by checking out www.x.org to find the mirrors
nearest you...).

    john> is there some kind of daemon that can run on your localhost
    john> that reads all the mail coming in and turns it into encoding
    john> that can be read/edited in say patched-elm? the as it goes
    john> out, change it to whatever the "industry" standard is (S-JIS
    john> right?)

The patched Elm should handle all of the usual encodings.  If not, use 
Ken Lunde's jconv or nkf to do the conversions.  Unfortunately, there
is probably never going to be such a daemon, as it is possible to
write strings in Shift-JIS which cannot be told from EUC until you
look at the content.  By the time computers can understand any human
language that well, we'll all be using Unicode.

There is no "industry standard" as such; there are many.  Shift-JIS
will never be part of such a standard because it's too hard to make it
coexist with other languages.  Shit-JIS (as it is commonly known) is
the defacto standard on DOS/V and Macintrash machines because that was
convenient for Microsoft.  Unix boxes generally use EUC-JP, which was
designed to allow coexistence of several languages in the same UUnet
(not to be confused with uu.net), but has problems of its own.  JIS is
the Japanese national standard encoding, but doesn't deal with
internationalization at all.  ISO-2022-JP is JIS with the addition
of escape sequences so that it can coexist with other languages; most
of the time you can't tell the difference between JIS and ISO-2022-JP.
ISO-2022 is the Internet standard for text email (email in S-JIS is
technically MIME type application/binary, so there, Mr. Gates!) in
Japanese, and its use is mandatory in headers.  Not that anybody at
Niftyserve pays attention to Internet standards.  :-(

Finally, there is Unicode, which will be a standard someday.  (It's a
standard now, but nobody uses it.)  Unicode is based on two
principles: (1) create a single code space in which *all* of the
world's languages can be written without escape sequences in 16-bit
characters or less (considering that all the hanzi ever used in China
run to about 50,000, and that many of the 20,000 kanji used in Japan
have topologically different glyphs from their Chinese ancestors, and
that Hangul adds yet another large character set and the Korean
kanji's are often different from both Japanese and Chinese, this is
not an easy task---somebody has to give up their accustomed glyph
shapes in some cases), and (2) set up a systematic extension process
so that all of those Japanese variants can coexist with their Chinese
and Korean brethren (necessary for linguists, if nobody else).

Someday, the software to make this Babel transparent to end users will 
exist, and you'll be thankful.  In the meantime, it's a major pain in 
the <MEESE!>.

    john> any ideas where I can pickup XIM?

Technically, "/lib/libX11.so" should do the trick.  It's a protocol,
not a program.  Seriously, an optimist would say "kinput2" which
allegedly implements the protocol, and a pessimist would say (wait
for) "kinput3".

    >> Are you sure you were typing Japanese into Xedit?  Or just
    >> displaying it?

    john> both.. im Sure!

OK.

    >> If you actually were typing Japanese into Xedit, then maybe
    >> you've got an FEP running in the background that steals the
    >> keystrokes and remaps them.  If so, that might explain why jvim
    >> is behaving strangely, nothing to do with kterm after all.

    john> like what?? i didn't think there was one (kinput2?). if

To answer that I'd need to run `ps' on your machine :-)

What, were you typing randomly into the screen and getting two ASCII
characters glommed into a random kanji?  You can't type Japanese to
any useful extent without a front end processor of some kind or a
kanji tablet (which is big enough to violate San Francisco zoning
standards, so I doubt you have one at home).

    john> there is I cannot switch modes into Japanese or whatever
    john> when im using Xedit.. 

That's what the XIM and kinput2 protocols are for, so that the app can 
pass requests for character conversion from the user to the conversion 
server.  But the way these work is when you tap the <toggle-fep> key
the app takes that keystroke, recognizes it as the toggle, and does a
complicated dance in which it opens an X, Unix socket, or TCP
connection to the conversion server.  So in the kterm source there's a 
lot of code dealing with that process, it is encapsulated in a
function called "begin-conversion", and in .Xresources I hook into
it with

KTerm*VT100.Translations: #override \
    Ctrl<Key>backslash:begin-conversion(_JAPANESE_CONVERSION)

    john> i think we edited something in the Xedit defaults..

Well, it might be something like that kterm resource.  I can't see
anything in the app-defaults/Xedit that might be useful, though.
Maybe if you add a font resource that points to a JIS font, you could
get Japanese to appear on screen, but as far as I can tell the only
way to input it would be if you know the two-ASCII-character
equivalent of the JIS code value.  Not appealing....  If you know
better, OK, I'm just telling you what I'm seeing the the resource file
and so on.

    >> Or maybe its easier to switch to Emacs/Mule....  The menuing in
    >> recent versions of Emacs is much better than it used to be.
    >> Under X, it's almost GUI :-)

    john> nonoooooooononono... i really really don't want to fool with
    john> Emacs/Mule...  but if thats the last alternative.. :)

Well, that's a matter of taste, of course.  Are you sure you don't
want to head back to the arms of Mama Microsoft?  :-)  Seriously,
you've said that's exactly what you don't want to do, but it most
likely would free up your spare time---I expect that all this will get 
sorted out in the next few months (if I have to do it myself ;-), and
you should be able to just load up Debian-JP and off you go.  (I've
sorta given up on Slackware/JE, maybe prematurely, but there it
is....)

Regards,
Steve

-- 
                            Stephen J. Turnbull
Institute of Policy and Planning Sciences                    Yaseppochi-Gumi
University of Tsukuba                      http://turnbull.sk.tsukuba.ac.jp/
Tel: +81 (298) 53-5091;  Fax: 55-3849              turnbull@example.com
-----------------------------------------------------------------
a word from the sponsor will appear below
-----------------------------------------------------------------
The TLUG mailing list is proudly sponsored by TWICS - Japan's First
Public-Access Internet System.  Now offering 20,000 yen/year flat
rate Internet access with no time charges.  Full line of corporate
Internet and intranet products are available.   info@example.com
Tel: 03-3351-5977   Fax: 03-3353-6096