[zzo38computer]

> The ITRON specs can be downloaded from the TRON website

I had seen that, but many things (including many of the older stuff) seems to be missing.

However, some stuff I had found elsewhere (not from TRON website), and I had been able to partially figure out from the Japanese documentation and had been able to write a program that can partially parse the TRON Application Databus format. However, many things I could not figure out very well.

I had also found what seems to be some document of TRON instruction set (I have some interest in the instruction sets of some older computers, not only TRON), but is Japanese and also seems that some files are missing, anyways. So, I don't know its working anyways. (I also found some English documentation but it does not actually explain much, although there is a few minor explanation of them.)

> CTRON appears to have been based on OSI-I see references to FTAM and MOTIS (the X.400 mail transport protocol)

However, I think X.400 uses ASN.1, and ASN.1 does not have a TRON string data type (I had once also wanted to use this in something else (unrelated to X.400 mail and CTRON), so I used the octet string type instead).

> I can’t find any references to actual specs for MTRON. I am wondering if it was ever actually specified, or if it was just vapourware

That was my guess as well, but I don't know either.

> You don’t need a whole operating system for that. It could just be a library which supported converting TRON code to other character sets, displaying text in TRON code, etc.

You are right, I do not need a whole operating system for that (see below). But, the operating system design is helpful for many other things. The use of TRON character code is only one of its features; it also has many other features, many of which are difference from POSIX and other systems (although some things are similar to other systems). (I had written elsewhere about my ideas of operating system designs, too.)

I had done some of the other stuff relating to TRON code in Linux too (although it is incomplete). I have written some programs that can display text, I had made fonts with TRON character set (although not all planes are implemented), and some programs that can convert some character codes (including e.g. EUC-JP, EUC-CN, EUC-KR). I had also been able to write partial English documentation from what I could figure out (which I documented on Just Solve The File Format Problem Wiki), although much of it is difficult.

(One of the problems I have is the way the GT fonts are coded; they are several TrueType fonts, that use an improper Unicode mapping that does not seem to have anything to do with the actual Unicode characters that those numbers are supposed to correspond to (except font 1, which does correspond correctly to Unicode), and the mapping of improper Unicode into TRON code is given in a large PDF file, and the mapping seems to not have any sort of reasonable order, and that I could not figure out how to handle automatically. If I could figure out how to handle it properly then I could implement a file that can use them with the TRON code directly; someone who is Japanese and is able to compare the characters to figure out how to make up your own bitmap fonts with the GT character set, could do that too, I suppose.)

[skissane]

The main selling point of the TRON character code, from what I understand, is CJKV speakers who disagree with Han unification.

But it sounds like you don’t know Japanese. Do you know another CJKV language? If not, what makes the TRON character code attractive to you?

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. But the TRON character code doesn’t really, since as a non-CJKV speaker, the debate about Han unification has no practical relevance, but rejecting that is the main selling point of the TRON encoding.

[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.