From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, NICE_REPLY_A autolearn=no autolearn_force=no version=3.4.4 Received: (qmail 26681 invoked from network); 20 Jul 2022 12:38:47 -0000 Received: from 9front.inri.net (168.235.81.73) by inbox.vuxu.org with ESMTPUTF8; 20 Jul 2022 12:38:47 -0000 Received: from mail.posixcafe.org ([45.76.19.58]) by 9front; Wed Jul 20 08:36:43 -0400 2022 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=posixcafe.org; s=20200506; t=1658320599; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=fDG37VsxQD4ckEA7jwLF7bqjYKSr22lIVNWVwyLTdVo=; b=mL9IULSb6/rRkWB5ZuX/tbYIIJnZ+F1ut+VadWQkMJQydZp+Ahg97d0BqnA5YgX5QPhNSw sP6udQ/fPnjU7EmeyfQKYy/fBJJ8LRuhoOjKFnOMDKBVH7RyLALBrPjaZu/ccTS9VupEIr d2CYIaplyGOx09neMKaEgNO925RSKPc= Received: from [192.168.168.200] (161-97-228-135.lpcnextlight.net [161.97.228.135]) by mail.posixcafe.org (OpenSMTPD) with ESMTPSA id 3c49417c (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO) for <9front@9front.org>; Wed, 20 Jul 2022 07:36:38 -0500 (CDT) Message-ID: <19d746a6-84cb-889c-0145-eda898f5aa62@posixcafe.org> Date: Wed, 20 Jul 2022 06:36:23 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.10.0 Content-Language: en-US To: 9front@9front.org References: From: Jacob Moody In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: basic encrypted configuration metadata-scale high-performance-aware controller Subject: Re: [9front] ctrans - Chinese language input for Plan9 Reply-To: 9front@9front.org Precedence: bulk On 7/19/22 21:19, smj@9p.sdf.org 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 way. 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 ether. 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. -- moody