[I18n-sig] naming codecs

Tamito KAJIYAMA kajiyama@grad.sccs.chukyo-u.ac.jp
Thu, 7 Dec 2000 15:17:06 +0900

Martin v. Loewis wrote:
| > I consider releasing a version of the JapaneseCodecs package
| > that will include a new codec for a variant of ISO-2022-JP.  The
| > codec is almost the same as the ISO-2022-JP codec, but it can
| > encode and decode Halfwidth Katakana (U+FF61 to U+FF9F) which
| > can not be encoded with ISO-2022-JP as defined in RFC1468.
| So how exactly does it encode them? 
| Is that your own invention, or is there some precedent for that
| encoding (e.g. in an operating system, or text processing system)?

Halfwidth Katakana in Unicode corresponds to the character set
JIS X 0201 Katakana, and this character set can be designated by
the escape sequence "\033(I" in the framework of ISO 2022.  For
example, GNU Emacs and LV (http://www.ff.iij4u.or.jp/~nrt/lv/)
can handle this encoding.  This is not my invention.

| > I believe there is a demand for the codec, but I have no idea on the
| > name of the codec.
| If it is your own invention, I'd be surprised if there was demand. If
| you just follow some existing practice, then I'd assume that this
| practice has a name - which should be used in the name of the codec.

GNU Emacs gives the name "iso-2022-7bit" to the encoding that
can encode JIS X 0201 Katakana.  However, this name is too big
to use for the ISO-2022-JP variant, since iso-2022-7bit can
encode all character sets that GNU Emacs supports.


KAJIYAMA, Tamito <kajiyama@grad.sccs.chukyo-u.ac.jp>