[cxterm-devel] Re: Japanese mapping files in the cxterm (fwd)

[Thomas W. <mi...@to...>]

Dear Hin-Tak Leung,

you wrote to Ziying Sherwin:

> If you could kindly point out where the errors are, we can correct them.

> Indeed, Kya, etc are somewhat like dipthoughs(spelling?) in English.
> A friend of mine (English, but married a Japanese lady) did mention
> something about that when I introduce him to cxterm a very long time
> ago.
> ...
> I have a very elementary understanding of Japanese (and I can always ask
> some
> Japanese friends if in doubt), so if you could tell me what you think
> they the corrections are, we'll consider putting it in.

> The tit files are in the source bundle, so if you can edit them and send
> over your modified version we'll discuss this further.
If my observation and Ziying's confirmation of it are true, the 
fix would probably just be to change
BEGINDICTIONARY into BEGINPHRASE in HIRAGANA.tit, KATAKANA.tit and 
ROMKANA.tit.


> (I am somewhat in the same boat... been using cxterm since about
> 1993/1994
> and thought I might as well keep it going for my own benefit...)
I used to test my first implementatino of CJK encoding support of 
my editor mined (http://towo.net/mined/) with cxterm years ago.
I wanted to install cxterm again as a test environment but I 
cannot get it to run, it always complains about "no available ptys".
Is that a bug you are aware of? Is there any fix?
This is on recent Linux versions. And it doesn't even compile here 
on a recent SunOS version. First it doesn't find ncurses which I 
then replaced with curses in the Makefile. But now it complains 
about lots of missing symbols, apparently of graphics output functions.
The configure script did not complain about any missing libraries.
Could you perhaps provide working binaries for Linux or SunOS?


> In fact I do have two private dictionaries which I haven't included in
> the source - one is basically your idea of hirahana+katakana, plus
> all JIS level 1 kanji's in their Kan? readings in one mapping (I later
> realize On? reading is probably more useful as that's how Japanese
> people pronounce the kanji's); the other's ChangJie (the fastest Chinese
> input method) converted to do japanese Kanji input. They are both
> somewhat strange, and not to everybody's taste, but that's the
> strength of Cxterm's input system - it is extendable.
As I see it, Hiragana and Katakana keyboard mappings cannot be 
merged as they use the same set of mnemonics for different characters.
Of course you could invent new mnemonics to make them unique, but 
that would probably not match the idea of phonetic mapping that seems 
to be the basis of these.


> Ziying Sherwin wrote:
> > 
> > We have been using cxterm on the Unix platform. And We are glad to 
> > see somebody finally volunteering the maintainance work.
> > 
> > Recently, we noticed an error on the Japanese input mapping in files
> > HIRAGANA.cit, KATAKANA.cit and ROMKANA.cit. According to the
> > documentation
> > coming with the cxterm application, the double-character entries they
> > have
> > (like for "kya", "shu" in HIRAGANA.utf) should be multiple-choice
> > mappings.
> > But from my limited Japanese knowledge, they should be a two-character
> > mappings and not choices. The first character is in normal size and
> > the
> > second one in a smaller size located in the left bottom.
> > 
> > I just wonder whether my guess is valid. Do you happen to know where
> > the 
> > Japanese keyboard mapping files come from and whether they have been
> > used by 
> > native Japanese-speakers?