Return to BSD News archive
Received: by minnie.vk1xwt.ampr.org with NNTP
id AA5618 ; Fri, 01 Jan 93 01:51:08 EST
Newsgroups: comp.unix.bsd
Path: sserve!manuel.anu.edu.au!munnari.oz.au!spool.mu.edu!agate!dog.ee.lbl.gov!hellgate.utah.edu!fcom.cc.utah.edu!cs.weber.edu!terry
From: terry@cs.weber.edu (A Wizard of Earth C)
Subject: INTERNATIONALIZATION: JAPAN, FAR EAST
Message-ID: <1992Dec28.065540.24637@fcom.cc.utah.edu>
Keywords: Han Kanji Katakana Hirugana ISO10646 Unicode Codepages
Sender: news@fcom.cc.utah.edu
Organization: University of Utah Computer Center
References: <1992Dec18.212323.26882@netcom.com> <1992Dec19.083137.4400@fcom.cc.utah.edu> <2564@titccy.cc.titech.ac.jp> <1992Dec27.223146.5959@rs6000.cmp.ilstu.edu>
Date: Mon, 28 Dec 92 06:55:40 GMT
Lines: 74
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
---
Any opinions in this posting are my own and not those of my present
or previous employers.
-------------------------------------------------------------------------------
"I have an 8 user poetic license" - me
Get the 386bsd FAQ from agate.berkeley.edu:/pub/386BSD/386bsd-0.1/unofficial
-------------------------------------------------------------------------------