NetNews Usenet Archive 1992 #31/NN_1992_31.iso/spool/comp/unix/bsd/10679

Text File | 1992-12-28 | 3.3 KB | 68 lines

Newsgroups: comp.unix.bsd
Path: sparky!uunet!spool.mu.edu!agate!dog.ee.lbl.gov!hellgate.utah.edu!fcom.cc.utah.edu!cs.weber.edu!terry
From: [e-mail] (A Wizard of Earth C)
Subject: Re: INTERNATIONALIZATION: JAPAN, FAR EAST
Message-ID: <[e-mail]>
Sender: [e-mail]
Organization: University of Utah Computer Center
References: <[e-mail]> <agp22+#@rpi.edu> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Mon, 28 Dec 92 06:40:29 GMT
Lines: 56

In article <[e-mail]>, [e-mail] (Masataka Ohta) writes:
|> In article <[e-mail]>
|>     [e-mail] (david carlton) writes:
|>
|> >I certainly wouldn't call it an insignificantly larger market.  Huge
|> >numbers of people use Chinese, Japanese, and other languages whose
|> >scripts don't fit in 8 bits, after all.
|>
|> True. But, it should be noted that they don't fit even in 16 bits.

Work is already under way to adapt Unicode to 32 bits.  I would be interested
in any similar work you know of in progress for XPG4/JIS.  I am *not*
interested in proposing or attempting to provide yet another standard, if
that is what you believe is necessary.

|> Even character sets used in a single language can not be represented
|> with 16 bits.
|>
|> While not all characters are used in modern Japanese, Taiwan already have
|> a character encoding standard which contains more than 65536 Han
|> characters.

0-65535 is 65536 characters, and is capable of being contained in an unsigned
short (16 bits).  I agree that this would leave no room for other characters
from other languages, but I doubt that all of these characters are in modern
use in a single dialect of Chinese.  In any case, the 32-bit Unicode should
have no problem handling the symbols.  I am more concerned with ligatures,
and I suspect there isn't a mechanism for doing this (short of an Arabic
or other ligature-bound language terminal).  Certainly our proposed mechanism
of X can not handle this within the bounds of its current font mechanisms,
nor can, I believe, Display Postscript, as on the NeXT.  Postscript is not
an alternative, given the nature of the 386BSD project and the licensing
restrictions glued to Postscript.

|> >Whether it is worth the
|> >effort to you is another matter, though;
|>
|> Sure. But if you do something, do it throughly, so that you don't have
|> to do it twice.

Again, I want to stress that we are about the identification and adoption
of an existing standard rather than the specification and ratification of
a new one.  We may invoke "tricks" to reduce storage requirements or to
retrofit existing input mechanisms, but we are not attempting a new standard.


                    Terry Lambert
                    [e-mail]
                    [e-mail]
---
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
-------------------------------------------------------------------------------