[zzo38computer]

> But it sounds like you don’t know Japanese.

Actually, I do know a little bit, but not very well. (I still don't like Han unification though. Also, that is not the only problem with Unicode (and some other character sets) anyways. Furthermore, I also think that one character set will not be suitable for all purposes anyways (and that it is not possible to make it so), so I also have interest to allow additional character sets to be available for use.)

> Personally TRON interests me simply because it is an OS API which looks rather different from POSIX, and I’m interested in learning about other ways of doing things - just maybe some of those other ways of doing things contain some good ideas.

I am also interested in it for this reason, too. (I also have interest to learn of some old Japanese computer systems, too.) (As you could see, I did mention stuff other than TRON character code, too)

[skissane]

> Furthermore, I also think that one character set will not be suitable for all purposes anyways (and that it is not possible to make it so), so I also have interest to allow additional character sets to be available for use.)

There are a number of libraries in existence for converting between character sets. ICU is one of the most famous but it is Unicode-centric (it supports many character sets but wants to use Unicode as a lowest common denominator.) But older libraries such as iconv or recode lack ICU’s Unicode-centricity, so might be more appealing to you. Have you thought about doing something like contributing TRON support to recode?

https://github.com/rrthomas/recode - I always called it “GNU recode”, but https://www.gnu.org/software/recode/ says it isn’t a GNU package, even though for a long time the GNU website hosted it. (I think maybe it is “ex-GNU”: the GNU project maintainer retired, and the new maintainer who took over wasn’t willing to abide by the GNU project’s policies.)

[zzo38computer]

I think GNU iconv also internaly uses Unicode although the interface does not require it (so it would be possible to modify the implementation so that a direct conversion (without going through Unicode, unless you are deliberately converting from or to Unicode) will be used if possible, without changing the interface).

A better way to handle conversion of character encoding is: Each character encoding will be a specific character set, and the encoding and decoding function. And then, there can be conversion between character sets. A direct conversion would normally be better (if it is available), although sometimes an indirect conversion would also be possible. (To convert JIS to TRON, an indirect conversion is unlikely to be useful, but a direct conversion is not too difficult (I have implemented it before) and would be much more useful.)

Furthermore, there may be more than one way to convert between character sets, depending on the application and on other things, including what character properties are intended, etc. There are also sometimes other options desired, e.g. how to handle conversion of invalid encodings, invalid code points, ambiguous conversions, multiple ways to encode a sequence of characters (although there may be one "canonical" way), etc.

(There is also the question of if you need to convert the character sets at all (in some cases only the encoding needs to be converted); for example, if you have fonts with the proper character set already, then a conversion may be unnecessary. Nevertheless, the ability to convert is useful, so it is helpful to have programs that do so, for the cases where it is helpful to do the conversion.)

I will look at them more later (I have not had time to look at them thoroughly by now, but I had partially done), to see if I can contribute support for TRON (and possibly other character sets). Depending on how it is implemented, it might be easy or difficult to change it to do such things.