Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site l5.uucp
Path: utzoo!watmath!clyde!bonnie!akgua!whuxlm!harpo!decvax!decwrl!sun!l5!gnu
From: gnu@l5.uucp (John Gilmore)
Newsgroups: net.internat
Subject: Re: What do we REALLY want?
Message-ID: <224@l5.uucp>
Date: Sun, 27-Oct-85 20:39:47 EST
Article-I.D.: l5.224
Posted: Sun Oct 27 20:39:47 1985
Date-Received: Wed, 30-Oct-85 04:41:29 EST
References: <723@inset.UUCP> <960@erix.UUCP>, <1569@hammer.UUCP> <6066@utzoo.UUCP>
Organization: Nebula Consultants in San Francisco
Lines: 21

In article <6066@utzoo.UUCP>, henry@utzoo.UUCP (Henry Spencer) writes:
> > As far as character sets go, it would seem that 16 bits (65536
> > possible characters) should be more than enough...
> 
> The trouble with this (and the other similar proposals) is it asks the
> Western world to pay a factor of 2 in storage overhead for the sake of
> the Asian character sets.

I think the proposals are that a coding scheme for text be defined which
allows 16-bit characters to be escape-coded into an 8-bit text stream.
The arguments mostly center on what kind of coding scheme would fit both
the needs of few-16-bit-char folks and few-8-bit-char folks without wasting
too much storage for either.

Internally to an international program, characters would be 16 bits,
but stdio routines (printw, fprintw, sscanw, etc) would encode to a
bytestream on the way in and out.  ("w" for "world" or "wide").

(Hmm, the non-Unix-opsys people have been looking for a way to tell when
we Unixoids are reading or writing a text file versus a binary file...now
that we propose encoding our own text files, they will have the clue.)