*BSD News Article 9107


Return to BSD News archive

Received: by minnie.vk1xwt.ampr.org with NNTP
	id AA5178 ; Tue, 22 Dec 92 08:00:53 EST
Xref: sserve comp.unix.bsd:9164 comp.os.linux:19862
Newsgroups: comp.unix.bsd,comp.os.linux
Path: sserve!manuel.anu.edu.au!munnari.oz.au!spool.mu.edu!caen!hellgate.utah.edu!fcom.cc.utah.edu!cs.weber.edu!terry
From: terry@cs.weber.edu (A Wizard of Earth C)
Subject: Re: Dumb Americans (was INTERNATIONALIZATION: JAPAN, FAR EAST)
Message-ID: <1992Dec19.083137.4400@fcom.cc.utah.edu>
Keywords: Han Kanji Katakana Hirugana ISO10646 Unicode Codepages
Sender: news@fcom.cc.utah.edu
Organization: Weber State University  (Ogden, UT)
References: <id.M2XV.VTA@ferranti.com> <1992Dec18.043033.14254@midway.uchicago.edu> <1992Dec18.212323.26882@netcom.com>
Date: Sat, 19 Dec 92 08:31:37 GMT
Lines: 95

In article <1992Dec18.212323.26882@netcom.com> messina@netcom.com (Tony Porczyk) writes:
>goer@kimbark.uchicago.edu (Richard L. Goerwitz) writes:
>
>>>> Has anyone in this newsgroup ever heard of the Unicode/ISO10646
>>>> (UCS) standard?
>>>
>>>You know, if 386BSD could be made to support NET-UTF (the Plan 9 version
>>>of the 10646 standard) that would be a major advantage over commercial
>>>Unices...
>
>>One of the big criticism leveled at US Engineers is that they are either
>>too dumb or lazy to build into their software support for non-Western
>>scripts.  Given that Linux originates in Europe, can we look forward to
>>better support for Unicode and ISO10646?  At least for "long" charac-
>>ter definitions?
>
>Yeah, that's probably why NT supports Unicode, it's those dumb US
>Engineers...  Could we lay off idiotic generalizations and stick to
>technical aspects of the software?  It's business that dictates what's
>included in the package.  If it makes economic sense, it will be there.
>Most of the internationalization is done locally anyway, so it has
>nothing to do with dumb engineers.

1)	You have a good point about US Engineer bashing.

2)	"Internationalization done locally" is called localization.

3)	I----------------------------
Bitnet:   UNM409@DBNRHRZ1                              Volker A. Brandt
UUCP:     ...!unido!DBNRHRZ1.bitnet!unm409             Angewandte Mathematik
Internet: volker@sfb256.iam.uni-bonn.de                (Bonn, Germany)

From tessier@bnr.ca (Daniel Tessier) 724988675
Xref: sserve comp.unix.pc-clone.32bit:758 comp.unix.sysv386:26394 comp.unix.bsd:9064 comp.os.linux:19547
Newsgroups: comp.unix.pc-clone.32bit,comp.unix.sysv386,comp.unix.bsd,comp.os.linux
Path: sserve!manuel.anu.edu.au!munnari.oz.au!spool.mu.edu!yale.edu!qt.cs.utexas.edu!cs.utexas.edu!torn!nott!bnrgate!bmerh85!bnr.ca!tessier
From: tessier@bnr.ca (Daniel Tessier)
Subject: Re: ET4000/W32 and VESA VL-Bus
Message-ID: <1992Dec16.191911.9003@bmerh85.bnr.ca>
Sender: news@bmerh85.bnr.ca (Usenet News)
Reply-To: Daniel.Tessier@bnr.ca
Organization: BNR Ottawa, Fibre Systems Development
References: <BzBEI1.CH@aeon.in-berlin.de> <1992Dec16.155355.7416@netcom.com>
Date: Wed, 16 Dec 92 19:19:11 GMT
Lines: 41

In article <1992Dec16.155355.7416@netcom.com>, hasty@netcom.com (Amancio Hasty Jr) writes:
|> In article <BzBEI1.CH@aeon.in-berlin.de> thomas@aeon.in-berlin.de (Thomas Wolfram) writes:
|> >Hi,
|> >does anyone already using the new ET4000/W32 chip, perhaps in an
|> >VESA VL local bus version? How is the performance compared with
|> >ET4000AX and does it work with XFree86 1.1?
|> >
|> >Thank you,
|> >Thomas
|> >-- 
|> >Thomas Wolfram, thomas@aeon.in-berlin.de
|> >EANTC, TU Berlin, wolf@prz.tu-berlin.de, +49 030 31421294
|> 
|> S3 is faster than the et4000 based technology the reason is because
|> of the server and its use of hardware assisted graphics functions.
|> We are about  6 times faster than an ISA et4000. In fact, it is more
|> accurate to say that XS3 can compete against your typical workstations
|> such as suns workstations. Typically an S3 801 costs less than $220(US).
|> XS3 is our X server for S3 chipsets and it runs on 386bsd and Linux.
|> 
|> XS3 has been clocked at 64k xstones onn terms of "economic sense", one wonders why Unicode and ISO10646,
	basically Western standards, are being applied to Far East languages
	like Japanese, Chinese, and Korean, when the XPG4 standard, using
	JIS (an existing Far Eastern standard) as a subset, is being ignored
	by NT?


To deal with the points in order:

US Engineers produce software for the available market; because of the
input difficulties involved in 6000+ glyph sets of symbols, there has been
a marked lack of standardization in Japanese hardware and software.  This
means that the market in Japan consists of mostly "niche" markets, rather
than being a commodity market.  This has changed somewhat with the Nintendo
corporations recent successes in Japan, where standardized hardware is
being used in most homes; this is probably an indicator of where the
Japanese market is heading.  Still, a Nintendo (even with many peripherials
not available in the US) is not a workstation.  Even here, the use of a
custom DMA chip on *each* cartridge instead of *in* the machine, with a
patent on it and a stiff licensing fee outside of Japan tend to imply that
the Japanese software market will not be open any time soon to volume sales
of US originated software.  This combines to make most internationalization
Europe-centric, and therefore limited to 8-bit clean applications/drivers.

It is currently possible to localize anything.  Some of the European work
(and some very particular "8 bit clean" code done in Greece) have been done
for 386BSD.  This is called enabling; in particular, enabling for
localization.  What we want is internationalization of 386BSD; this means
providing tools and native (kernel and file system, and in particular, file
system name space) support for it.  Internationalization goes beyond
localization by providing for multinational use without exectable code
changes.  If we assume booting to X on a VGA (640x480) as a default, and
additional setup of the X to support alternate resoloutions