Return to BSD News archive
Received: by minnie.vk1xwt.ampr.org with NNTP
id AA5617 ; Fri, 01 Jan 93 01:51:05 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: Re: INTERNATIONALIZATION: JAPAN, FAR EAST
Message-ID: <1992Dec28.064029.24421@fcom.cc.utah.edu>
Sender: news@fcom.cc.utah.edu
Organization: University of Utah Computer Center
References: <1992Dec18.235809.15484@midway.uchicago.edu> <agp22+#@rpi.edu> <1gvpt0INN8s0@hrd769.brooks.af.mil> <BzIwvu.3BE@demon.co.uk> <CARLTON.92Dec21163548@scws8.harvard.edu> <2565@titccy.cc.titech.ac.jp>
Date: Mon, 28 Dec 92 06:40:29 GMT
Lines: 56
In article <2565@titccy.cc.titech.ac.jp>, mohta@necom830.cc.titech.ac.jp (Masataka Ohta) writes:
|> In article <CARLTON.92Dec21163548@scws8.harvard.edu>
|> carlton@scws8.harvard.edu (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
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
-------------------------------------------------------------------------------