home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!pipex!bnr.co.uk!uknet!mcsun!sunic!nobeltech!ppan
- From: ppan@nobeltech.se (Per Andersson)
- Newsgroups: comp.unix.bsd
- Subject: Re: INTERNATIONALIZATION: JAPAN, FAR EAST
- Keywords: Han Kanji Katakana Hirugana ISO10646 Unicode Codepages
- Message-ID: <1992Dec30.010715.2731@nobeltech.se>
- Date: 30 Dec 92 01:07:15 GMT
- References: <2564@titccy.cc.titech.ac.jp> <1992Dec27.223146.5959@rs6000.cmp.ilstu.edu> <1992Dec28.065540.24637@fcom.cc.utah.edu>
- Organization: NobelTech AB
- Lines: 79
-
- In article <1992Dec28.065540.24637@fcom.cc.utah.edu> terry@cs.weber.edu (A Wizard of Earth C) writes:
- >In article <1992Dec27.223146.5959@rs6000.cmp.ilstu.edu>, jliddle@rs6000.cmp.ilstu.edu (Jean Liddle) writes:
- >|> In article <2564@titccy.cc.titech.ac.jp> mohta@necom830.cc.titech.ac.jp (Masataka Ohta) writes:
- >|> >
- >|> >Do you know that Japan vote AGAINST ISO10646/Unicode, because it's not
- >|> >good for Japanese?
- >|> >
- >|> >>So even if the Unicode standard ignores backward compatability
- >|> >>with Japanese standards (and specific American and European standards),
- >|> >>it better supports true internationalization.
- >|> >
- >|> >The reason of disapproval is not backward compatibility.
- >|> >
- >|> >The reason is that, with Unicode, we can't achieve internationalization.
- >|> >
- >|> >Unicode can not cover both Japanese and Chinese at the same time, because
- >|> >the same code points are shared between similar characters in Japan
- >|> >and in China.
- >|> >
- >|> >Of course, it is possible to LOCALIZE Unicode so that it produces
- >|> >Japanese characters only or Chinese characters only. But don't we
- >|> >need internationalization?
- >|> >
- >|>
- >|> I have been following this discussion for some time, despite the
- >|> (IMHO) obnoxious header :-). I have been surprised that up until
- >|> now the 32-bit proposed standard (I no longer recall the OSI number)
- >|> has not been mentioned. I personally would prefer this, for the
- >|> reasons stated above (japanese/chines collisions in Unicode). Furthermore,
- >|> for research involving ancient egyption texts or other "obscure" languages,
- >|> 16 bits even with some expandability would probably not be sufficient.
- >
- >I would also like to see this (although I believe the 32 bit standard in
- >question is Unicode-32).
- >
- >I wonder at the transcribability of such things as Ancient Egyptian
- >Heiroglyphics, where it seems the art work is intimately involved with the
- >meaning; I can't argue, however, that Aramaeic and other dead written
- >languages should probably be represented. This was the justification for
- >moving to 32 bits suggested in the Unicode Volume II. One wonders at the
- >amount of memory necessary to store such a font.
- >
- >|> I personally would vote for support of 32-bit characters rather than
- >|> Unicode, if anyone is able to scare up the docs on the proposed 32-bit
- >|> character standard. This would allow Linux to avoid the comming
- >|> difficulties with chinese/japanese font collisions, and also keep it
- >|> out on the leading edge, rather than following Microsloth's somewhat ...
- >|> ah ... shall we say, questionable leadership in this area.
- >
- >I believe the "collision problem" has been vastly overstated, unless you mean
- >that there actually exist multiple Unicode fonts with different glyphs at the
- >same lexical locations; I don't believe this is the case.
- >
- >It is a basic assumption that input, if not also output, will require some
- >type of localization; it is equally likely that there will be few mixed
- >language mechanisms, and that such localization will need to be done on the
- >basis of a per tty method, if nothing else, to provide for the message
- >catalog translators. Since we are not directly bound to a graphic
- >environment, I don't think it is possible to designate a widget/device as
- >that mechanism unless we are willing to give up text-only devices entirely.
- >Similarly, the lack of a streams mechanism makes it unlikely that a pure tty
- >environment will suffice for the translation process. If this is accepted,
- >the collision problem, as I see it, is non-existant.
- >
- >
- > Terry Lambert
- > terry@icarus.weber.edu
- > terry_lambert@novell.com
-
- Why, oh, why do we have to have another new unicode, invented by some
- stubborn US companies, when the whole world at last has agreed on
- ISO-10646 ? Not Invented Here ?
-
- /Per
- --
- -----------------------------------------------------------------------------
- Per Andersson - ppan@nobeltech.se (perand@stacken.kth.se on free time)
- Managing networks at, but not speaking for Nobeltech AB, J{rf{lla, Sweden
- -----------------------------------------------------------------------------
-