home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.unix.bsd
- Path: sparky!uunet!gatech!usenet.ins.cwru.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
- -------------------------------------------------------------------------------
-