From: Jacob Moody <email@example.com>
Subject: Re: [9front] ctrans - Chinese language input for Plan9
Date: Wed, 20 Jul 2022 06:36:23 -0600 [thread overview]
Message-ID: <firstname.lastname@example.org> (raw)
On 7/19/22 21:19, email@example.com wrote:
> With the recent commit of 'ktrans' to 9front, SDF boot camper 'ldb' as taken the
> idea and created 'ctrans' https://9p.sdf.org/who/ldb
> As Kenji Okamoto has pointed out, 'ktrans' would be difficult to extend to
> Chinese due to the massive number of characters necessary. While Japanese can
> get away with ~2500 daily use characters, Chinese requires quite a bit more.
> The advantage in Japanese is that there are two other writing alphabets which are
> purely phonetic and useful for importing foreign words.
> ldb's 'ctrans' had to take the 'ktrans' idea and optimize it a bit more to support
> 20,000 characters. The result is a mechanism that more or less behaves like ktrans
> but is quick (even over drawterm) to cycle through character lists.
> moody has seen this work and it has been an inspiration to adapt to 'ktrans' for
> even faster Kanji look up which could allow for more esoteric Kanji to be added.
After the discussion I had with ldb on cat-v, it became clear that there would be
some performance issues when using ktrans for considerably larger character sets. My thought
was that this performance stuff was a bug and set off to work to make this better.
I consolidated the dictionary and mapping lookups to use the same base hash map structure
and that seems to have speed up things quite a bit for larger character maps.
With that being said, I did take a stab at Chinese support in ktrans. Currently
it is explicit lookup only; working as ktrans does for Kanji vs
how it handles kana. But I am about the furthest thing away from native
Chinese speaker, so I can't say if what I cooked up is usable by any means.
I would love to learn how to make it more usable, it currently is in the a state
where it works convenient with the existing code but no reason it has to remain that
I would love to keep proper support in the base system, and for that I think I would
prefer that it live in ktrans vs its own program. Lets make ktrans better instead of
duplicating the code elsewhere, is my thoughts mostly.I just want avoid programs
like these become a 'if you know, you know' thing like ktrans did floating out in the
I realize now that my eagerness may have come across like I was trying to step on some toes,
if that is the case I apologize, those were not my intentions.
> In addition a new font 'HanaMinA' has been adapted which beautifully supports both
> Japanese and Chinese characters and it is what we recommend folks use on 9p.sdf.org.
Post a diff, I would love to include this in the base system.
> Thank you ldb for your great work!
Yes, thank you.
prev parent reply other threads:[~2022-07-20 12:38 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-20 3:19 smj
2022-07-20 12:36 ` Jacob Moody [this message]
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).