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.)