Return to BSD News archive
Received: by minnie.vk1xwt.ampr.org with NNTP
id AA5728 ; Fri, 01 Jan 93 01:53:50 EST
Path: sserve!manuel.anu.edu.au!munnari.oz.au!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
-----------------------------------------------------------------------------