From CCNET-L@uga.cc.uga.edu Sun Feb 17 04:16:17 1991
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.64/5.10) with SMTP id AA11896; Sun, 17 Feb 91 04:16:10 -0500
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 4079; Sat, 16 Feb 91 22:12:38 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 8412;
 Sat, 16 Feb 91 22:12:35 EST
Date:         Sat, 16 Feb 91 22:12:00 EST
Reply-To: Dorothy Day <DAY%IUBACS.BITNET@uga.cc.uga.edu>
Sender: Chinese Computing Network <CCNET-L%UGA.BITNET@uga.cc.uga.edu>
From: Dorothy Day <DAY%IUBACS.BITNET@uga.cc.uga.edu>
Subject:      more on ISO 10646/Unicode debate
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
Status: RO

Since there has been some discussion on this list about the merits of
Unicode, I'm forwarding this critique of Unicode by Harry Gaylord. The
Text Encoding Initiative working committees have struggled with much
broader questions of text markup (including syntactic markings and
much more), but the estabishment of a standard of character coding for
electronic transmission of material in all languages is still
fundamental to all other types of encoding.
        --Dorothy Day

--------------------------------------------------------------------------

Date:         Fri, 15 Feb 91 15:45:20 MET
Reply-To:     Text Encoding Initiative public discussion list
              <TEI-L@UICVM.BITNET>
From:         Harry Gaylord <galiard@LET.RUG.NL>
Subject:      Unicode

I have been asked by several people to say something about the implications
of the arrival of Unicode for TEI. Several useful comments in general have
appeared on Humanist, TEI-L, and 10646 about relevant issues. Yet it is
difficult to say anything succintly at this point.
  One thing is clear. No character set so far has tackled the problem of
the need to encode the lang characteristic in texts. This was already
pointed out in P1 and elsewhere. This, it seems to me, is very important
regardless of which coded character set one uses.
  There are advantages and disadvantages to both Unicode and ISO 10646 as
they are currently formulated. Hopefully they will be merged into one
ISO standard. There is no need for two multi-byte standards to be used in
different systems or even worse in single systems.
  Unicode and 10646 and the 8859 family of coded character sets have a
different understanding of what a character is how it will be used. Unicode
says nothing about the imaging of texts on a screen or printing on paper.
In a Unicode file the Greek letter alpha + IOTA SUBSCRIPT + ROUGH BREATHING
MARK + GRAVE ACCENT would be coded in 4 16-bit bytes. The software used to
image this text would have to recognize this combination of one spacing and
three non-spacing characters and put the image on your screen. ISO 10646
and the 8859 family the approach has been to have each combination as a
different coded character. Therefore this combination would be one byte in
10646. This would be a 32-bit byte if one were using the full 10646 set
or possibly 16 or 8 bits if one were using one of the compression techniques.
The software running the system with Unicode would also have to know that
since there are two accents above they have to be located differently above
the letter than if there is only one.
  On the other hand some languages have so many different combinations that
it is common practice to use "floating accents" or graphic character
combination encoding. An example of this is Hebrew which has 23 consonants
and 5 final forms. Its vowels and other signs are imaged in relation to the
consonants. If one had a coded character for each possible combination, it
would be enormous. Therefore present systems, e.g. Nota Bene SLS, and others
encode these separately. This is also true of Unicode and 10646. It is
uneconomical to do it otherwise.
  Two basic criticisms of the present proposals in 10646 are the very large
number of wasted control character positions in it, and inadequate provision
for graphic character combination encoding. In the latter there is an
appendix referring to they way this can be done under another ISO standard,
but this appendix is not a required part of the standard itself.
  The TG on character sets is in contact with Unicode and ISO with our
concerns for their work.
  We must remember that the final outcome of what is delivered is still very
uncertain. The standards have to be formulated and then hardware manufacturers
have to be convinced of the importance of them and implement them. This all
takes time. It is also important to note that the big players have people
working in the Unicode consortium and the ISO 10646 committee.
  One concern that I have is the need for representing text as it is contained
in older books and manuscripts. Neither standard as far as I can see has the
long s of English printing in earlier books. Yet we need it for many scholarly
purposes. From the standpoint of both of these standards it would be classified
as a "presentational variant" of s and be placed in a completely different
section of the character set. This is even more true of letter shapes as they
appear in manuscripts.
  There is room in each proposal for private use characters which can be used
by agreement of two or more parties. Yet the more that is included in a
standard as standard, the better off we are.
  There are currently attempts to combine the work of the Unicode consortium
and the committee for 10646. Let's hope they are successful and that the
results improve on both.
Harry Gaylord

From CCNET-L@uga.cc.uga.edu Tue Jul  9 13:49:27 1991
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.61/5.10) with SMTP id AA03881; Tue, 9 Jul 91 13:49:16 -0400
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 3897; Tue, 09 Jul 91 13:48:53 EDT
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 8690;
 Tue, 09 Jul 91 13:48:51 EDT
Date:         Tue, 9 Jul 1991 15:26:55 MET
Reply-To: Undetermined origin c/o Postmaster <POSTMASTER%UGA.BITNET@uga.cc.uga.edu>
Sender: Chinese Computing Network <CCNET-L%UGA.BITNET@uga.cc.uga.edu>
Comments:     <Parser> E: Mail origin cannot be determined.
Comments:     <Parser> E: Original tag was -> FROM: Jian Luo
              (Jian@hdetud11.bitnet  +31-15786227)
From: Undetermined origin c/o Postmaster <POSTMASTER%UGA.BITNET@uga.cc.uga.edu>
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
Status: RO

There is an interesting article published on the newest Byte (version of
July 1991) about Unicode and ISO 10646.  The title is "ASCII Goes Global",
authored by K.M. Sheldon, from page 108 through 116.

Actually it's only an introduction and it doesn't require an expert on coding
to understand it.  It also tells the different opinions from the Chinese,
Japanese and Korean sides about the coding standardization proposals.

Isn't this an interesting sentence: "Cultural issues are particularly
sensitive in the Far East; for example, the Japanese standards process is
driven in part by the traditionally conservative Ministry of Culture"?

Good day!

From CCNET-L@uga.cc.uga.edu Tue Jul  9 14:06:57 1991
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.61/5.10) with SMTP id AA04083; Tue, 9 Jul 91 14:06:50 -0400
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 3956; Tue, 09 Jul 91 14:05:49 EDT
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 9129;
 Tue, 09 Jul 91 14:05:47 EDT
Date:         Tue, 9 Jul 1991 14:00:51 EDT
Reply-To: Scott Horne <horne-scott%CS.YALE.EDU@uga.cc.uga.edu>
Sender: Chinese Computing Network <CCNET-L%UGA.BITNET@uga.cc.uga.edu>
From: Scott Horne <horne-scott%CS.YALE.EDU@uga.cc.uga.edu>
Subject:      Unicode
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
Status: RO

It's true.  Japan's Ministry of Education (Monbusho^) is trying to keep the
set of Japanese _kanji_ contiguous within Unicode.  This is wasteful and
 foolish,
of course, but guided by ultra-conservatism.

					--Scott

From CCNET-L@uga.cc.uga.edu Sun Feb 17 04:16:17 1991
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.64/5.10) with SMTP id AA11896; Sun, 17 Feb 91 04:16:10 -0500
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 4079; Sat, 16 Feb 91 22:12:38 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 8412;
 Sat, 16 Feb 91 22:12:35 EST
Date:         Sat, 16 Feb 91 22:12:00 EST
Reply-To: Dorothy Day <DAY%IUBACS.BITNET@uga.cc.uga.edu>
Sender: Chinese Computing Network <CCNET-L%UGA.BITNET@uga.cc.uga.edu>
From: Dorothy Day <DAY%IUBACS.BITNET@uga.cc.uga.edu>
Subject:      more on ISO 10646/Unicode debate
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
Status: RO

Since there has been some discussion on this list about the merits of
Unicode, I'm forwarding this critique of Unicode by Harry Gaylord. The
Text Encoding Initiative working committees have struggled with much
broader questions of text markup (including syntactic markings and
much more), but the estabishment of a standard of character coding for
electronic transmission of material in all languages is still
fundamental to all other types of encoding.
        --Dorothy Day

--------------------------------------------------------------------------

Date:         Fri, 15 Feb 91 15:45:20 MET
Reply-To:     Text Encoding Initiative public discussion list
              <TEI-L@UICVM.BITNET>
From:         Harry Gaylord <galiard@LET.RUG.NL>
Subject:      Unicode

I have been asked by several people to say something about the implications
of the arrival of Unicode for TEI. Several useful comments in general have
appeared on Humanist, TEI-L, and 10646 about relevant issues. Yet it is
difficult to say anything succintly at this point.
  One thing is clear. No character set so far has tackled the problem of
the need to encode the lang characteristic in texts. This was already
pointed out in P1 and elsewhere. This, it seems to me, is very important
regardless of which coded character set one uses.
  There are advantages and disadvantages to both Unicode and ISO 10646 as
they are currently formulated. Hopefully they will be merged into one
ISO standard. There is no need for two multi-byte standards to be used in
different systems or even worse in single systems.
  Unicode and 10646 and the 8859 family of coded character sets have a
different understanding of what a character is how it will be used. Unicode
says nothing about the imaging of texts on a screen or printing on paper.
In a Unicode file the Greek letter alpha + IOTA SUBSCRIPT + ROUGH BREATHING
MARK + GRAVE ACCENT would be coded in 4 16-bit bytes. The software used to
image this text would have to recognize this combination of one spacing and
three non-spacing characters and put the image on your screen. ISO 10646
and the 8859 family the approach has been to have each combination as a
different coded character. Therefore this combination would be one byte in
10646. This would be a 32-bit byte if one were using the full 10646 set
or possibly 16 or 8 bits if one were using one of the compression techniques.
The software running the system with Unicode would also have to know that
since there are two accents above they have to be located differently above
the letter than if there is only one.
  On the other hand some languages have so many different combinations that
it is common practice to use "floating accents" or graphic character
combination encoding. An example of this is Hebrew which has 23 consonants
and 5 final forms. Its vowels and other signs are imaged in relation to the
consonants. If one had a coded character for each possible combination, it
would be enormous. Therefore present systems, e.g. Nota Bene SLS, and others
encode these separately. This is also true of Unicode and 10646. It is
uneconomical to do it otherwise.
  Two basic criticisms of the present proposals in 10646 are the very large
number of wasted control character positions in it, and inadequate provision
for graphic character combination encoding. In the latter there is an
appendix referring to they way this can be done under another ISO standard,
but this appendix is not a required part of the standard itself.
  The TG on character sets is in contact with Unicode and ISO with our
concerns for their work.
  We must remember that the final outcome of what is delivered is still very
uncertain. The standards have to be formulated and then hardware manufacturers
have to be convinced of the importance of them and implement them. This all
takes time. It is also important to note that the big players have people
working in the Unicode consortium and the ISO 10646 committee.
  One concern that I have is the need for representing text as it is contained
in older books and manuscripts. Neither standard as far as I can see has the
long s of English printing in earlier books. Yet we need it for many scholarly
purposes. From the standpoint of both of these standards it would be classified
as a "presentational variant" of s and be placed in a completely different
section of the character set. This is even more true of letter shapes as they
appear in manuscripts.
  There is room in each proposal for private use characters which can be used
by agreement of two or more parties. Yet the more that is included in a
standard as standard, the better off we are.
  There are currently attempts to combine the work of the Unicode consortium
and the committee for 10646. Let's hope they are successful and that the
results improve on both.
Harry Gaylord

>From CCNET-L@uga.cc.uga.edu Tue Jul  9 13:49:27 1991
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.61/5.10) with SMTP id AA03881; Tue, 9 Jul 91 13:49:16 -0400
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 3897; Tue, 09 Jul 91 13:48:53 EDT
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 8690;
 Tue, 09 Jul 91 13:48:51 EDT
Date:         Tue, 9 Jul 1991 15:26:55 MET
Reply-To: Undetermined origin c/o Postmaster <POSTMASTER%UGA.BITNET@uga.cc.uga.edu>
Sender: Chinese Computing Network <CCNET-L%UGA.BITNET@uga.cc.uga.edu>
Comments:     <Parser> E: Mail origin cannot be determined.
Comments:     <Parser> E: Original tag was -> FROM: Jian Luo
              (Jian@hdetud11.bitnet  +31-15786227)
From: Undetermined origin c/o Postmaster <POSTMASTER%UGA.BITNET@uga.cc.uga.edu>
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
Status: RO

There is an interesting article published on the newest Byte (version of
July 1991) about Unicode and ISO 10646.  The title is "ASCII Goes Global",
authored by K.M. Sheldon, from page 108 through 116.

Actually it's only an introduction and it doesn't require an expert on coding
to understand it.  It also tells the different opinions from the Chinese,
Japanese and Korean sides about the coding standardization proposals.

Isn't this an interesting sentence: "Cultural issues are particularly
sensitive in the Far East; for example, the Japanese standards process is
driven in part by the traditionally conservative Ministry of Culture"?

Good day!

>From CCNET-L@uga.cc.uga.edu Tue Jul  9 14:06:57 1991
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.61/5.10) with SMTP id AA04083; Tue, 9 Jul 91 14:06:50 -0400
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 3956; Tue, 09 Jul 91 14:05:49 EDT
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 9129;
 Tue, 09 Jul 91 14:05:47 EDT
Date:         Tue, 9 Jul 1991 14:00:51 EDT
Reply-To: Scott Horne <horne-scott%CS.YALE.EDU@uga.cc.uga.edu>
Sender: Chinese Computing Network <CCNET-L%UGA.BITNET@uga.cc.uga.edu>
From: Scott Horne <horne-scott%CS.YALE.EDU@uga.cc.uga.edu>
Subject:      Unicode
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
Status: RO

It's true.  Japan's Ministry of Education (Monbusho^) is trying to keep the
set of Japanese _kanji_ contiguous within Unicode.  This is wasteful and
 foolish,
of course, but guided by ultra-conservatism.

                                        --Scott


From CCNET-L@uga.cc.uga.edu Tue Dec 24 05:32:32 1991
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.61/5.10) with SMTP id AA25422; Tue, 24 Dec 91 05:32:26 -0500
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 3085; Tue, 24 Dec 91 05:30:38 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 6302;
 Tue, 24 Dec 91 05:30:37 EST
Date:         Tue, 24 Dec 1991 05:28:28 EST
Reply-To: ygz%CS.PURDUE.EDU@uga.cc.uga.edu
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: ygz%CS.PURDUE.EDU@uga.cc.uga.edu
Subject:      End-of-line problem and transmission format
Comments: To: CCNET-L@UGA.CC.UGA.EDU
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
Status: RO

Thanks to CND-CM (HXWZ) and CHPOEM lists and the people who make
them reality to provide wonderful services for Chinese netters.
Chinese computation is also benefited because these two lists
have put many ideas into real test, and provided many experiences
as well as new-found problems.

We had hot discussions on "popular GB + uuencode" vs "pure GB +
escape sequences" early this year.  Both CND-CM and CHPOEM chose
uuencode format.  CND-CM has operated for more than 8 months,
having issued nearly 50 articles, and CHPOEM is also functioned
for over one months.  Now, we can have some retrospect on this
issue.


1. It is pointed out that there is an "end-of-line" problem in
   transferring Chinese text.  I think it is related to the external
   representation (or transmission format) of Chinese text file.

   The end-of-line marker becomes a problem because we transfer
   text file in "binary mode" (uuencoded).  Had we sent the Chinese
   articles as text files (assuming the network was 8-bit clean),
   we wouldn't have this problem.  Do you see people complaining
   that the ENGLISH TEXT received by mail/news has incompatible
   end-of-line markers?  Not likely.  It is because the mail/news
   systems treat each file as a text file and do the necessary
   conversion.  This is part of the job for the software (mail, news,
   kermit, etc) that transfer text file between different architectures.
   The end-users, you and me, posters and readers of CHPOEM-L,
   shouldn't have to worry this.

   Chinese article is line-oriented and should be put in "text mode".
   But uuencode format treats it as pure binary code.


2. Uuencode is more "costly" than escape sequences's approach (e.g zW, HZ).
   I have done some research today and here is the result.

   I chose a large sample of Chinese text files, convert them to
   some common used formats, and compared their sizes.

   Sample:  All CND-CM (HXWZ) articles issued so far (total 48 issues,
		from cm9104a.gb to cm9112c.gb)

   a) Total size:	1211795 bytes.
      Total 14395 line of texts (average 84.2 bytes per line).
      There is a total of 586400 Chinese characters (2 bytes for each
      Chinese character), i.e. 96.78% of the text are Chinese.

   b) The total size after "uuencode": 1670731 bytes.
      The overhead is 37.8% !
      (This is exactly how CND-CM is distributed now.)

      "btoa" is not much better, with total size = 1536579,
      overhead = 26.8%.

   c) The total size in HZ format is 1263055.
      The overhead is only 4.2% !
	(HZ uses "~{", "~}" as escape sequences to quote pure GB code)

   d) The total size in ISO format is 1288685, overhead only 6.3%.
	(ISO format uses "<ESC>$A" to mark the beginning of pure GB
	code, and "<ESC>(B" to mark the beginning of ASCII code)

   e) The total size in HZ+zW format is 1247167.
      The overhead is as little as  2.9% !!
	(zW puts "zW" at the beginning of a line of pure GB codes;
	HZ+zW uses both HZ and zW format in one file and optimizes
	line by line: if one line consist of only GB code and no
	ASCII, "zW" is used, otherwise HZ format is used)

   The conclusion I got is that the extra cost of HZ+zW format
   is about 1/13 of that of the current used uuencode.  The
   conversion between HZ+zW, HZ, zW, GB-code is rather simply.
   (On the other hand, uuencode/uudecode is a lot more complex.)


Then why use "popular GB + uuencode" transmission, when there is
alternative way which 1) has no "end-of-line" problem, 2) produces
smaller file for transmission and saves network bandwidth (plus
many advantages we've gone over in CCNET early this year) ?

Happy Xmas and enjoy the holidays!

Yongguang Zhang
ygz@cs.purdue.edu

From CCNET-L@uga.cc.uga.edu Fri Jan 31 17:29:09 1992
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.67/5.10) with SMTP id AA26927; Fri, 31 Jan 92 17:29:04 -0500
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 4187; Fri, 31 Jan 92 17:28:17 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 0886;
 Fri, 31 Jan 92 17:27:48 EST
Date:         Fri, 31 Jan 1992 16:16:01 EST
Reply-To: yih%BRL.MIL@uga.cc.uga.edu
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
Comments:     Resent-From: yih@BRL.MIL
Comments:     Originally-From: SCHEIN@torolab5.vnet.ibm.com
From: yih%BRL.MIL@uga.cc.uga.edu
Subject:      Unicode Implementer's Workshop announcement
Comments: To: ccnet-l@uga.cc.uga.edu
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
Status: RO

 The Unicode Consortium will sponsor a Unicode Implementer's Workshop.
 --------------------------------------==============================

 Target Audience:
     Technical writers, managers or engineers, developing or considering
     development of software supporting Unicode.

 Date:
     March 12 and 13, 1992

 Location:
     Digital, Merrimack Conference center in New Hampshire, USA
     Hotel information and directions are attached.

 Content:
     March 12 will feature a full day professionally developed lecture
     course covering the Goals and Architecture of the Unicode Standard,
     as well as how its implementation addresses character coding
     problems that exist in todays multi-code page environments or
     tomorrows multi-lingual systems.

     A separate demonstration room will provide a look at working Unicode
     systems and prototypes

     March 13 will feature seminar style talks on implementation aspects
     of Unicode, such as converting existing code, compression, sorting,
     relation of Unicode to other standards, impact on computer languages
     and locales, as well as other topics.

 Course Material:
     A full set of notes will be provided for the course. Also included
     will be the full text of papers accompanying the talks. A special
     updated Implementer's version of the Unicode Standard, including
     diskettes with character code conversion tables, will be
     distributed to registered participants

 Registration:
     A registration form is attached.


 +----------------------------------------------------------------------+
 |  Isai Scheinberg                         A3/979/895/TOR              |
 |                                          IBM Canada, Inc.            |
 |  phone: (416) 448-2260                   895 Don Mills Road          |
 |  fax:   (416) 448-2114                   Noth York, Ontario M3C 1W3  |
 |  email: schein@torolab5.vnet.ibm.com     CANADA                      |
 +----------------------------------------------------------------------+

------------------ Attachment 1 - Agenda --------------------------------

The March 13 tentative agenda and brief introduction for each item:


8:30 - 9:00   Welcome

    Gayn Winters     -        Digital, Technical Director
    Ted Sasala       -        IBM, Director of NLS
    Mark Davis       -        Unicode Inc., President


9:00 - 9:30   Unicode and ISO 10646

    Is there one universal code standard or two? What is the status
    of the ISO standard? Will a product which implements Unicode
    be conformant to the ISO 10646? Isai Scheinberg from IBM Canada will
    address these and similar questions.

9:30 - 10:30  Program Migration to Unicode

    What needs to be done to convert existing C programs to support
    Unicode? Asmus Freytag will describe Microsoft experience with
    conversion of Windows NT programs.

10:30 - 11:30 Non-spacing marks

    Non spacing marks (going also by the name of "floating diacritics")
    is one of the areas which scares implementers of the Unicode
    standard. Mark Davis from Apple will describe the strategies for
    handling of non spacing marks in various types of character
    processing.

11:30 - 12:15 Compression of Unicode data

    Unicode characters are two bytes each. American and European
    developers invariably protest this at first, since this doubles
    the character portion of any text data. Greh Hullender will share
    Go Corporation experience in compressing Unicode text.

12:15 - 13:15 Lunch

13:15 - 14:00 Unicode in PL/I

    PL/I is a programming language widely used on mainframe computers.
    The new version of PL/I which will run on OS/2 plans to support
    Unicode as a new character data type as well as an encoding for the
    program source. J.G. Van Stee from IBM will outline the design
    considerations that PL/I development team is faced with.

14:00 - 14:45 Code Set conversions

    Unicode is the wave of the future. Unfortunately most of our
    operating systems are still committed to supporting the past.
    So until Unicode sweeps the planet there will be a need to convert
    billions of characters from Unicode to current code sets and back.
    Lloyd Honomichl will discuss Novell approach to optimizing the
    memory needed for storing conversion tables.

14:45 - 15:30 Collate in Unicode

    Now that Unicode defines all of the world's characters in one place,
    how do we sort a truly multilingual data? Pamela Ottaviano from
    Microsoft and Catherine Wissink from University of Washington will
    describe their proposal.

15:30 - 16:15 Unicode Model and the XPG/POSIX locale model

    The Locale model developed by various standards and users groups
    (X/Open consortium, Uniforum, and other) is based on the notion of
    code set independence. The *single code* code set assumption is
    central to the Unicode model. Eamon MacDermott from Digital will
    discuss the issues and the directions for the coexistence or
    convergence of these two models.


16:15 - 16:45 Unicode and ISO Font Interchange Model

    The International Organization for Standardization (ISO) has recently
    adopted a standard for font interchange. John McConell from Digital
    will describe the differences between the ISO 9541 font model and
    Unicode, the problems these differences cause application developers
    and practical ways to overcome some of these problems.


16:45 - 17:30 Unicode and OSI standrads

    Unicode is on its way to become an international standard. Other
    ISO standards which are being reviewed to include I18N features
    plan to include support for the universal code. Jurgen Bettels
    and Masami Hasegawa from Digital will discuss the plans for Abstract
    Syntax Notation (ASN.1) the Directory Services (X.500) and the
    Message Handling System (X.400).

------------------ Attachment 2 - Hotel information ---------------------

    The Unicode Workshop has reserved a block of rooms at a special rate of $45
    per night plus 8% tax at the Best Western Merrimack Inn, Merrimack NH. Make
    your reservations directly with the hotel. When making a reservation say
    that you are attending the Unicode Workshop. The block of rooms and the
    special rate is guaranteed until February 20. The Merrimack Inn offers
    complementary transportation to and from Manchester Airport (12 miles) and
    to and from the Digital Conference center (2 miles). Transportation to and
    from Logan Airport in Boston (55 miles) can be arranged for a fee.

    USA Today newspaper delivered to every guest room each weekday morning.

    Complimentary hors d'oeuvres served Mon.- Fri. 5-7 p.m. in Players  Lounge.
    Executive Travel Center Club open Mon. - Thurs. 5-10 p.m.

 MERRIMACK INN (FORMERLY HILTON)
 Exit 11 Everett Turnpike            Tel (603)424-6181 / (800)922-3477
 MERRIMACK, NH 03054                 Fax (603)424-1668
 USA

------------------ Attachment 3 - Directions ----------------------------



 From Logan Airport to Hotel:

    Exit airport, follow signs to Callahan Tunnel I-93 North.

    Proceed through tunnel take second right immediately outside tunnel
    (expressway North I-93).

    Follow I-93 North for approximately 5 miles, take exit for I-95 South (Route
    128 South), signed for Woburn, Waltham.

    Follow I-95 (Route 128 South) for approximately 5 miles, take exit signed
    for Nashua (Route 3 North).

    Follow Route 3 North into New Hampshire all the way to exit 11, Everett
    Turnpike. Exit in lane 1. There is a $0.50 toll. Turn left at the bottom of
    the exit ramp. Proceed to street light, turn right at Burger King. Take next
    right into the hotel parking lot.

    The journey is approximately 55 miles. Driving yourself in rush hour is not
    recommended as it can take an hour to get through the tunnel. Consider
    taking a limo as their drivers know back routes avoiding the tunnel. Limo
    service can be arrange via the hotel.

 From Manchester Airport (NH) to the hotel.

    Take a right out of the airport onto Brown Ave. Take a left at 2nd set of
    lights. Follow signs to 101 East. Take Nashua/Boston exit onto route 3
    South, Everett Turnpike. Go through tolls ($0.75). Take exit 11, go through
    lights, take first right. You will see the Best Western sign.

 From hotel to Digital

    Exit to right from hotel parking lot, at lights take right.  Proceed
    approximately 4 miles to DEC on left.

 From points south to Digital

    Take route 3 (see directions from Logan) to exit 10 ($0.50 toll). Take a
    left at the end of the toll ramp, then a left at the second set of lights.
    You are on Digital Drive. Follow the signs to MKO2.

------------------ Attachment 4 - Registration --------------------------

                     Unicode Workshop Registration
                     _____________________________

 The conference will be held in the Wellington Room, Digital Equipment
 Corporation MKO2, Merrimack, NH.

 Please complete and return this form to Tim Greenwood. There is no
 charge for the workshop but we need to keep track of numbers. You will
 receive a response to the registration.

 Return the form to

 greenwood@i18n.enet.dec.com

 or, if you do not have access to email

 Tim Greenwood
 Digital Equipment Corporation ZKO2-1/O07
 110 Spit Brook Road, Nashua, NH 03062-2698

 Tel: 603-881-0575
 Fax: 603-881-0120

 _____________________________________________________________________________


 Name __________________           email: _____________________________

 Company ________________________  Tel: ____________  Fax: ____________

 Address _______________________
         _______________________
         _______________________

 Attend:   March 12  Y/N
           March 13  Y/N

 _____________________________________________________________________________

From CCNET-L@uga.cc.uga.edu Fri Jan 31 17:31:43 1992
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.67/5.10) with SMTP id AA26949; Fri, 31 Jan 92 17:31:34 -0500
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 4189; Fri, 31 Jan 92 17:30:28 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 0925;
 Fri, 31 Jan 92 17:28:33 EST
Date:         Fri, 31 Jan 1992 16:19:09 EST
Reply-To: yih%BRL.MIL@uga.cc.uga.edu
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
Comments:     Resent-From: yih@BRL.MIL
Comments:     Originally-From: SCHEIN@torolab5.vnet.ibm.com
From: yih%BRL.MIL@uga.cc.uga.edu
Subject:      2nd DIS 10646 4 month ballot started Jan. 30th
Comments: To: ccnet-l@uga.cc.uga.edu
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
Status: RO

Note from Jurgen Bettels, Switzerland is attached:
-----------------------------------------------------------------------

 For those of you who want to know: I received today my official copy of
 the 2nd DIS from the ISO secratariat and it carries Jan. 30th as
 starting date and May 30th as finishing date for the ballot.

 Jurgen.

From CCNET-L@uga.cc.uga.edu Fri Jan 31 17:33:49 1992
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.67/5.10) with SMTP id AA26961; Fri, 31 Jan 92 17:33:45 -0500
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 4190; Fri, 31 Jan 92 17:32:28 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 0960;
 Fri, 31 Jan 92 17:29:10 EST
Date:         Fri, 31 Jan 1992 16:22:24 EST
Reply-To: H u a n g Yolin <yih%BRL.MIL@uga.cc.uga.edu>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: H u a n g Yolin <yih%BRL.MIL@uga.cc.uga.edu>
Subject:      [Erik M. van der Poel:  alternative multilingual character
              encoding]
Comments: To: ccnet-l@uga.cc.uga.edu
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
Status: RO

I just put this file (rfc-intl) up to 'ahkcus.org'.

/yih

----- Forwarded message # 1:

Date:         Fri, 31 Jan 1992 20:46:32 +0900
From:         "Erik M. van der Poel" <erik@sra.co.jp>
Subject:      alternative multilingual character encoding
X-To:         ISO10646%jhuvm.BITNET@jpnkyoto.kyoto-u.ac.jp, Unicode@sun.com,
              i18n@dkuug.dk, ietf-822@dimacs.rutgers.edu
To:           Multiple recipients of list ISO10646 <ISO10646@jhuvm>

For those of you that have not already committed to Unicode, there is
a low-cost alternative (which may be desirable now that the US and
other countries are in a so-called recession). Individuals and
organizations that have already begun to implement Unicode may find it
desirable to continue to do so as it may be expensive to re-design and
re-implement systems now.

I will include the beginning of the document and the section titles
only in the interests of saving disk space. The document can be
obtained by ftp (login: "ftp", password: your email address) from:

	srawgw.sra.co.jp:pub/doc/net-char/doc/rfc-intl

By the way, the IP address of the above host is:

	133.137.4.3

----------------------------
* Internet Draft -- RFC-INTL



          Multilingual Character Encoding for Internet Messages


                       Erik M. van der Poel, SRA
                            January 31, 1992



* Status of this Document

This draft is being submitted to the mailing list at
net-char@sra.co.jp. After discussing changes and additions on this
list, the document will be updated and eventually forwarded to the
IETF Mail Extensions Working Group at ietf-822@dimacs.rutgers.edu, to
be considered as a proposal for an Internet Standard.  Distribution of
this draft is unlimited. Please send comments to net-char@sra.co.jp.
To join (or quit) this list, please send your address and human name
to net-char-request@sra.co.jp.

SRA, Inc. of Tokyo, the author (Erik M. van der Poel), and other
persons and organizations named in this document will take no
responsibility for events that may happen as a result of reading
and/or implementing the specifications described in this document.
This document is provided "as is" without express or implied warranty.


* Abstract

This document describes a multilingual character encoding for use in
Internet messages. This encoding is designed to be highly compatible
with existing electronic mail and network news handling software.


* Introduction
** Current Situation
*** ASCII Languages
*** Japanese
*** Latin Languages
*** Korean
*** Taiwanese
*** Hebrew
** Migration Issues
** Approach Taken
** Known Problems
** Alternatives Considered
*** Unicode 1.0
*** DIS 10646 1.2
*** Full ISO 2022
*** Compound Text
*** Extended UNIX Code (EUC)
*** Other Encodings
* Basic Encoding Methods
** ISO 2022-like Encoding
*** Informal Description of the Method
*** Known Problems with this Method
** Mnemonics
* Specific Encoding Methods
** ASCII Languages
** Latin-1 Languages
** Japanese
** Korean
** Taiwanese
** Hebrew
* Formal Specification of the Encoding
* MIME Headers
* Other MIME-Related Specifications
** Richtext
* Conformance
* Appendix - Communities Contacted
* Appendix - Processing Code
** Four-Octet Processing Code
** Character Uniqueness
* References
* Author's Address

----- End of forwarded messages

From CCNET-L@uga.cc.uga.edu Fri Jan 31 17:36:55 1992
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.67/5.10) with SMTP id AA27004; Fri, 31 Jan 92 17:36:50 -0500
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 4193; Fri, 31 Jan 92 17:35:28 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 0995;
 Fri, 31 Jan 92 17:29:40 EST
Date:         Fri, 31 Jan 1992 16:24:32 EST
Reply-To: H u a n g Yolin <yih%BRL.MIL@uga.cc.uga.edu>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: H u a n g Yolin <yih%BRL.MIL@uga.cc.uga.edu>
Subject:      [Ken Whistler:  Re: Unicode discussion list]
Comments: To: ccnet-l@uga.cc.uga.edu
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
Status: RO

----- Forwarded message # 1:

The general discussion list for Unicode is: unicode@sun.com
You can get added to that list by sending a request to be added to:
unicode-request@sun.com. The list administrator is Bill Tuthill.

--Ken Whistler
Unicode Secretary

----- End of forwarded messages

From CCNET-L@uga.cc.uga.edu Tue Apr  7 20:44:08 1992
Received: from ugav2.cc.uga.edu by sirius.ctr.columbia.edu (5.67/5.10) with SMTP id AA17422; Tue, 7 Apr 92 20:43:55 -0400
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 2694; Tue, 07 Apr 92 20:41:55 EDT
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 7145;
 Tue, 07 Apr 92 20:27:00 EDT
Date:         Tue, 7 Apr 1992 20:13:34 EDT
Reply-To: yih@BRL.MIL
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
Comments:     Resent-From: yih@BRL.MIL
Comments:     Originally-From: asmusf@microsoft.com
From: yih@BRL.MIL
Subject:      Re: implementors workshops
Comments: To: ccnet-l@uga.cc.uga.edu
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
Status: RO

| >From:         "Erik M. van der Poel" <erik@sra.co.jp>
| Subject:      implementors workshops
|
| Asmus, thanks for the info about the Unicode implementors workshop.
| Would it be possible to send some of the info about issues and
| possible solutions to the 10646 and/or Unicode mailing lists? I

Unfortunately, none of the workshop material exist in plain text
softcopy. To obtain hardcopy you can contact the Unicode Consortium
at 415-961-4189 or FAX 415-966-1637. A Unicode E-Mail contact
address is being set up and should be announced on unicode@sun.com
when it comes on-line.

| realize that some of the info may be proprietary to either the company
| itself or the Unicode consortium, but I think it is fair to say that,
| in general, a standard will benefit from discussion of its issues.

None of the workshop information is proprietary, but as with all printed
works, normal copyright applies. We regard the workshops as an opportunity
for people to learn from each other, therefore speakers are encouraged
to present their actual implementation experience in a non-proprietary
fashion.

| Also, some people on these mailing lists may not be able to go to the
| workshops.

The Unicode consortium is working on making it feasible for as many people
as possible to attend future workshops by offering them at various and
widely distributed geographical locations.

In the meantime I notice on the mailing lists that there is certainly a
lively discussion going on; albeit with the usual limitations of E-Mail,
especially its inability to convey non-ASCII characters and/or pictures.

Asmus Freytag
Techical Director
The Unicode Consortium.

From CCNET-L@uga.cc.uga.edu Sun Apr 12 09:49:18 1992
Received: from ugav2.cc.uga.edu by sirius.ctr.columbia.edu (5.67/5.10) with SMTP id AA00674; Sun, 12 Apr 92 09:49:09 -0400
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 3019; Sun, 12 Apr 92 09:46:37 EDT
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 3304;
 Sun, 12 Apr 92 09:46:35 EDT
Date:         Sun, 12 Apr 1992 09:36:47 EDT
Reply-To: yih@BRL.MIL
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
Comments:     Resent-From: yih@BRL.MIL
Comments:     Originally-From: Bill Bill Tuthill <tut@cairo.eng.sun.com>
From: yih@BRL.MIL
Subject:      Re: Whither Unicode?
Comments: To: ccnet-l@uga.cc.uga.edu
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
Status: RO

irving@eskimo.celestial.com (Larry Gilbert) writes:
>
> My questions:  Where is Unicode now?  Is it being used, or indeed
> is there support for it?

Support is coming soon, but is not yet available in the mainstream.
Plan 9 (the follow-on OS after research's Version 8 Unix) implements
Unicode, using UTF (multibyte encoding scheme) for files.  Microsoft's
NT has support for Unicode, and may be available soon.  And Taligent
(formerly Apple's Pink project) also will support Unicode.

> This book, which was printed around September 1991, seems
> to indicate that Unicode would be incorporated into the framework
> of a larger 32-bit international character set ("ISO DIS 10646");
> does anyone know the status of this ISO standard?

DIS2 of 10646 is currently out for review.  Voting takes place this
June, I believe.  Unicode and 10646 have been merged in this DIS2.
A committee just finished unifying and ordering the Han (ideographic)
character repertoire.  This is part of the 10646 work, and will also
appear as volume 2 of the Unicode book.

> (Meta-question:  Is this an appropriate newsgroup for discussing this?)

Probably.  I'm getting mighty sick of troff questions; this seems more
interesting.  An alternative newsgroup would be comp.std.internat, but
that degenerated into a flamefest and people stopped reading it.

From CCNET-L@uga.cc.uga.edu Sun Apr 12 09:49:30 1992
Received: from ugav2.cc.uga.edu by sirius.ctr.columbia.edu (5.67/5.10) with SMTP id AA00686; Sun, 12 Apr 92 09:49:23 -0400
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 3020; Sun, 12 Apr 92 09:47:06 EDT
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 3337;
 Sun, 12 Apr 92 09:47:03 EDT
Date:         Sun, 12 Apr 1992 09:36:59 EDT
Reply-To: yih@BRL.MIL
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
Comments:     Resent-From: yih@BRL.MIL
Comments:     Originally-From: Jonathan Lavigne <jpl@lyra.stanford.edu>
From: yih@BRL.MIL
Subject:      Re: Whither Unicode?
Comments: To: ccnet-l@uga.cc.uga.edu
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
Status: RO

irving@eskimo.celestial.com (Larry Gilbert) writes:

>The other day, I purchased a book entitled _The Unicode Standard: Worldwide
>Character Encoding_ (Version 1.0, Volume 1) by The Unicode Consortium,
>published by Addison-Wesley (ISBN 0-201-56788-1).  I was happy to find it,
>mostly because it does a thorough job of following through with an idea similar
>to one I've had for a while.

>For those unfamiliar with Unicode, it is a standard (not yet officially
>recognized) which attempts to unify most major world character encoding
>standards into one standard which uses 16-bit character codes.

[Original statement of questions omitted]

[24788] FRI 04/10/92 15:22 FROM BR.JMA "Joan Aliprand": The Unicode Standard;
Larry Gilbert asks several questions about Unicode:

1.  Where is Unicode now?  Is it being used, or indeed is there support for it?

2.  "The Unicode Standard" seems to indicate that Unicode would be incorporated
    into the framework of a larger 32-bit international character set ("ISO DIS
    10646"); does anyone know the status of this ISO standard?

3. Meta-question:  Is this an appropriate newsgroup for discussing this?

Answer to Question 1:
The Unicode standard is very much alive.  Vol. 2 of the "The Unicode Standard,"
which covers East Asian ("Han") ideographic characters is being readied for
publication.

The corporations that belong to the Unicode Consortium show their support
for the Unicode standard in three ways:  they pay dues for membership in
the Consortium; their employees participate in various activities
(primarily the Unicode Technical Committee); they host workshops on
implementing the Unicode standard.  And (of course) some of the
corporations that belong to the Unicode Consortium are incorporating
Unicode into future products.

The list of acknowledgements in "The Unicode Standard" identifies the
companies and individuals who contributed to its development.  The July
1991 issue of BYTE includes an article ("ASCII Goes Global" by Kenneth M.
Sheldon) that gives an overview of the Unicode standard and a little
about its history.

Answer to Question 2:
Unicode's character repertoire and encoding have been incorporated into the
latest draft of ISO's Universal Character Set (DIS 10646-1.2).  The DIS is
currently being balloted; the closing date is 5/30/92.

The U.S. position on DIS 10646 is the responsibility of ANSI Subcommittee X3L2.

Comment on Question 3:
You can be added to the Unicode mailing list by sending a note with your e-mail
address to unicode-request@sun.com.  This is the best arena for discussing
Unicode-related topics.

Author's background:
You'll find my name in the list of acknowledgements in "The Unicode Standard."
My employer, The Research Libraries Group, Inc., is a member of the Unicode
Consortium.

-- Joan Aliprand

P.S.

The following press release from Microsoft mentions that the Japanes
version of Windows 3.1 supports Unicode (here spelled "Uni-code").

>  ---------------------------- Text of forwarded message ---------------------
>
>
> TOKYO, JAPAN, 1992 MAR 16 (NB) -- The Japanese office of Microsoft
> will release a Japanese version of Windows 3.1 this summer. This
> will be an upgrade to Windows 3.0.
>
> Microsoft Windows 3.1 has a 32-bit application interface, and is
> compatible with Windows NT. This program also supports
> Truetype outline fonts, the same system supported on Apple's
> Macintosh. Also, Windows 3.1 supports multimedia features and
> object-oriented technology. Microsoft says Windows 3.1 will be
> easier to use in the rewriting of English programs into Japanese
> because all the programs are written in a 2-byte code called
> "Uni-code."
>
> About 200,000 units of Windows 3.0 were shipped in Japan since it
> was released in February 1991. More than 100 kinds of applications
> have been developed for Windows 3.0.
>
> (Masayuki Miyazawa/19920316/Press Contact: Microsoft Tokyo office,
>  +81-3-3363-3419)

From CCNET-L@uga.cc.uga.edu Mon Apr 13 10:18:51 1992
Received: from ugav2.cc.uga.edu by sirius.ctr.columbia.edu (5.67/5.10) with SMTP id AA05886; Mon, 13 Apr 92 10:18:18 -0400
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 7587; Mon, 13 Apr 92 09:41:26 EDT
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 8639;
 Mon, 13 Apr 92 09:41:22 EDT
Date:         Fri, 10 Apr 1992 10:36:12 MSZ
Reply-To: Hartmut Bohn <utrurt!bohn@RELAY.EU.NET>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: Hartmut Bohn <utrurt!bohn@RELAY.EU.NET>
Subject:      Questions about UNICODE
Comments: To: CCNET-L <unido!CCNET-L@relay.EU.net>
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
Status: RO

Hi!

Just a few questions about about UNICODE  (I am aware of the fact
that there is a UNICODE mailing list, but I am already being swamped
with e-mail...):

- When will the UNICODE standard for Hanzi be published?

- Will there be any fonts available? Are there going to be
  any UNICODE coded fonts in the public domain?

Well, I just wondered...

	Hartmut
--
Hartmut Bohn       ,'|_____,    /   ---,  |  Computerlinguistik / Sinologie
Klemensstr. 13    /| |  |  |  -/--- __/_  |        Universitaet Trier
5500 Trier Ruwer   |  / | \    \ /   |    |               Email:
Germany            |   \|      /\   \/    o          bohn@utrurt.uucp

      [Email: also try bohn%utrurt@unido.informatik.uni-dortmund.de]

From CCNET-L@uga.cc.uga.edu Mon Apr 27 13:33:24 1992
Received: from ugav2.cc.uga.edu by sirius.ctr.columbia.edu (5.67/5.10) with SMTP id AA26493; Mon, 27 Apr 92 13:33:15 -0400
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 8815; Mon, 27 Apr 92 13:30:24 EDT
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 1882;
 Mon, 27 Apr 92 11:53:48 EDT
Date:         Mon, 27 Apr 1992 08:53:55 PDT
Reply-To: "K. Smith-Yoshimura" <BL.KSS%RLG.BITNET@uga.cc.uga.edu>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: "K. Smith-Yoshimura" <BL.KSS%RLG.BITNET@uga.cc.uga.edu>
Subject:      Unicode Implementor's Workshop Proceedings Available
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
Status: RO

This is a forwarded message.

To:  CCNET-L@UGA.BITNET

FORWARDED MESSAGE 04/24/92 16:40 FROM KERNAGHAN@HQ.M4.METAPHOR.COM """":
Unicode Implementor's Workshop Proceedings Available

Received: by Forsythe.Stanford.EDU; Fri, 24 Apr 92 16:40:21 PDT
Received: from Eng.Sun.COM (zigzag-bb.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1)
        id AA07537; Fri, 24 Apr 92 16:37:14 PDT
Received: from cairo.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1)
        id AA02883; Fri, 24 Apr 92 16:37:15 PDT
Received: from snail.Sun.COM by cairo.Eng.Sun.COM (4.1/SMI-4.1)
        id AA17527; Fri, 24 Apr 92 16:37:18 PDT
Received: from Sun.COM (sun-barr) by snail.Sun.COM (4.1/SMI-4.1)
        id AA17713; Fri, 24 Apr 92 16:37:02 PDT
Received: from relay.metaphor.com by Sun.COM (4.1/SMI-4.1)
        id AA07518; Fri, 24 Apr 92 16:37:00 PDT
Received: by relay.metaphor.com (4.1/SMI-4.1)
        id AA15285; Fri, 24 Apr 92 16:33:36 PDT
Date: Fri, 24 Apr 92 16:33:36 PDT
From: kernaghan@HQ.M4.Metaphor.COM
Message-Id: <9204242333.AA15285@relay.metaphor.com>
To: Unicode@Sun.COM
Subject: Unicode Implementor's Workshop Proceedings Available

This message is to announce that the proceedings from the second "Unicode
Implementor's Workshop are available.  This workshop was held on March 12th and
13th, 1992, in Boston.

The proceedings consist of copies of papers and transparencies presented at that
workshop covering a variety of Unicode and multilingual implementation topics.

Anyone may order a copy of these proceedings by sending a check or money order
for $15 US to Unicode, Inc., for each copy requested.  This amount covers
materials and shipping costs.  All Unicode corporate and affiliate members will
receive a copy automatically as part of their membership.

Further information on obtaining these proceedings or any Unicode topic  may  be
obtained by calling the Unicode headquarters at (415) 961-4189, or writing to:

      Unicode, Inc.
      c/o Metaphor Inc.
      1965 Charleston Road
      Mountain View, CA.  94043

                  Michael Kernaghan,  V.P., Unicode, Inc.

P.S. Feel free to forward this announcement to whomever might benefit from these
proceedings.

From CCNET-L@uga.cc.uga.edu Thu May  7 13:06:46 1992
Received: from ugav2.cc.uga.edu by sirius.ctr.columbia.edu (5.67/5.10) with SMTP id AA02942; Thu, 7 May 92 13:06:21 -0400
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 8696; Thu, 07 May 92 13:02:53 EDT
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 0560;
 Thu, 07 May 92 13:02:49 EDT
Date:         Thu, 7 May 1992 10:01:28 PDT
Reply-To: "K. Smith-Yoshimura" <BL.KSS%RLG.BITNET@uga.cc.uga.edu>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: "K. Smith-Yoshimura" <BL.KSS%RLG.BITNET@uga.cc.uga.edu>
Subject:      New Membership Categories for Unicode Consortium, fyi
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
Status: RO

For those of you who may be interested.

---------------------------- FORWARDED MESSAGE ------------------------------
Date: 6 May 92 15:08:51 U
From: "Mark Davis" <mark_davis@qm.taligent.com>
Subject: New Membership Categories
To: unicode@Sun.COM

Subject:   New Membership Categories            Time: 15:05      Date: 92.05.06
========================================================================
                       New Membership Categories
========================================================================

As directed by the board, the officers of Unicode Inc. have revised the
affiliate membership, replacing this category with two new categories:
associate membership and individual membership.

If you are interested in becoming a full (corporate) member, associate member
or individual member, please contact:

     Unicode, Inc.
     1965 Charleston Road
     Mountain View, CA 94043, USA
     Phone:    (415) 961-4189
     Fax:      (415) 966-1637
     Internet: unicode-inc@cairo.eng.sun.com

Current affiliate members are unaffected by this revision until their next
annual renewal. However, they may elect to switch to one of the other
categories by meeting the membership requirements. Except for full membership
rights and obligations specified in the bylaws, Unicode Inc. reserves the right
to change the membership features at any time.

The following information summarizes the differences between the three classes
of membership, and their relationship to: Unicode, Inc., the Unicode Technical
Committee (UTC) the UTC subcommittees (SCs), the email distribution lists
(DLs), and the Unicode Implementer's Workshops (UIWs).

========================================================================

Full (Corporate) Membership

1. Eligibility

a. Limited to corporations.
b. Cannot be more than 50% owned by other corporate members.
c. Committed to publicly support Unicode, as phrased in the bylaws of Unicode
Inc.
e. Fees of US$10,000 per year, due on January 1.

2. Benefits

a. Can attend and vote in Unicode Inc. membership meetings, UTC closed caucus
meetings, UTC meetings and SC meetings.
b. Can chair SC meetings.
c. Can subscribe to the restricted, minutes, and general DLs.
d. Eligible for discounts on UIWs.
e. Will receive 5 free copies of editions of the Unicode Standard.
f. Can copy UIW proceedings for no fee as long as they are only for internal
use. (The UIW proceedings are copyrighted by Unicode, Inc.)
g. Acknowledged in various Unicode publications.

========================================================================

Associate Membership

1. Eligibility

a. Open to both corporations and individuals.
b. Can be more than 50% owned by other members.
c. Committed to publicly support Unicode, as phrased in the bylaws of Unicode
Inc.
e. Fees of US$1,200 per year, due on January 1.

2. Benefits

a. Can attend and speak at UTC meetings and SC meetings.
b. Can chair SC meetings.
c. Can subscribe to the restricted, minutes, and general DLs.
d. Eligible for discounts on UIWs.
e. Will receive 1 free copy of editions of the Unicode Standard.
f. Included in a list of associates periodically made available by the Unicode
PR agency.

========================================================================

Individual Membership

1. Eligibility

a. Limited to individuals
b. Fees of US$180 per year, for one year from the date of fee receipt.

2. Meetings and Fees

a. Can observe at UTC meetings, and attend and speak at SC meetings.
b. Can subscribe to the minutes and general DLs.
c. Will receive 1 free copy of editions of the Unicode Standard.

========================================================================

Non-members

a. Can observe at UTC and SC meetings, space permitting.
b. Can subscribe to the general DL.

========================================================================

The Unicode Distribution lists include:

General:             unicode@sun.com
Minutes & Agendas:   unicode-minutes@cairo.eng.sun.com
Restricted:          unicored@sun.com

From CCNET-L@uga.cc.uga.edu Sat Jun  6 11:42:15 1992
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.67/5.10) with SMTP id AA16996; Sat, 6 Jun 92 11:42:11 -0400
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 3330; Sat, 06 Jun 92 11:38:57 EDT
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 1855;
 Sat, 06 Jun 92 11:38:54 EDT
Date:         Sat, 6 Jun 1992 11:26:17 EDT
Reply-To: H u a n g Yolin <yih@BRL.MIL>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: H u a n g Yolin <yih@BRL.MIL>
Subject:      Re:  Chinese OS/2 ??
Comments: To: ccnet-l@uga.cc.uga.edu
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
Status: RO

the following is excerpts from the May 4 issue (May Fourth) of "digital
review": (front page)

----------------------------------------------------------------------
Boston - At DECworld last week, Microsoft and DEC consecrated their
agreement to port the Windows NT operating system to DEC's Alpha RISC
processor.  The 32-bit multitasking operating system is scheduled to
become available at the beginning of next year, when DEC delivers its
first Alpha systems.
...
...
-----------------------------------------------------------------------

Both DEC and Microsoft are underwriters of the Unicode, along with IBM,
Apple, Sun, Next, WordPerfect ... etc. (ref: K. Smith-Yoshimura)

Hope CCNet subscribers in, or closer to, those organizations would bring
forward more details; if not against corporate regulations.

/yih

From @cuvmb.cc.columbia.edu:CCNET-L@UGA.BITNET Sun Feb 18 09:39:20 1990
Received: from CUVMB.COLUMBIA.EDU (cuvmb.cc.columbia.edu) by sirius.ctr.columbia.edu (4.1/5.10) id AA02866; Sun, 18 Feb 90 09:39:16 EST
Received: from CUVMB.COLUMBIA.EDU by CUVMB.COLUMBIA.EDU (IBM VM SMTP R1.2.1) with BSMTP id 1199; Sun, 18 Feb 90 09:39:08 EST
Received: from PUCC.PRINCETON.EDU by CUVMB.COLUMBIA.EDU (Mailer R2.05) with
 BSMTP id 2640; Sun, 18 Feb 90 09:39:06 EST
Received: from PUCC.BITNET by PUCC.PRINCETON.EDU (Mailer R2.06X) with BSMTP id
 6363; Sun, 18 Feb 90 09:38:55 EST
Date:         Sun, 18 Feb 90 04:33:08 +0100
Reply-To: Lars-Erik Fredriksson <mrfung%NADA.KTH.SE@cuvmb.cc.columbia.edu>
Sender: Chinese Computing Network <CCNET-L%UGA@cuvmb.cc.columbia.edu>
From: Lars-Erik Fredriksson <mrfung%NADA.KTH.SE@cuvmb.cc.columbia.edu>
Subject:      Too many characters?
Comments: To: CCNET-L@UGA.UGA.EDU
To: Multiple recipients of list CCNET-L <CCNET-L@uga>
Status: RO

So many characters so little codespace?



Well I realize now that some of you are more than tired of
hearing people telling you that 16-bit still will not be enough!
But to tell you the truth this is the most common objection
from sinologues, researchers of Naxi (moso) Tangut, and
manichaean manuscripts from the Tang and what have you. I
myself have a still gnawing feeling that I need to be able to
forcefully say that the codespace in UNICODE is enough for
a standard, and I think what finally made it easier for me was
some lines by Lee Collins to me ( I hope he doesn't mind me
quoting him here! and I am sorry if everyone else in this group
are too fed up with this topic! but the quest of UNICODE
is worth a rehash of things some of you have hopefully
long ago dealt with)

Lee Collins says:
=>Unicode does provide a potential 50K (including User space)
=>for Han. A quick glance at the Dai Kanwa Jiten should convince
=>you that many of the CCCII characters are so rare (they appear
=>exactly once in some ancient dictionary, without reading or
=>meaning) or obsolete that they should never burden a standard
=>for information interchange. How do you type them. They will
=>simply make most Chinese input methods unuseable.
=>
=>If you need to do work in jiaguwen or zhuanwen, then it
=>seems reasonable to use a font mapped to the more
=>common modern forms. If I wanted to put the Chinese
=>classics into machine readable form, I would use the more
=>common forms, not the rare variants of CCCII. If really
=>needed to record a specific form, then I would just store the
=>entire text as a picture. Also, on the Macintosh we are
=>now developing a mechanism for selecting swash and other
=>variants in Roman fonts that could be applied to Chinese.
=>
=>I admire the work done by CCCII, but frankly, I just
=>don't see the need for encoding every squiggle ever made
=>by semi-literate scribes.

Well for me, that is a reasonable, brief summing up that should
be quite enough for most of us but obviously it will do more
harm than good if we when we argument for Unicode with
people bringing up this argument so here is the ultimate posting
on this topic and I won,t do it again!

If the argumentation we have is that there is not enough space
in the Unicode standard lets look at the real number of characters
someone suggested a humongous figure but really there are not
many more than the supposedly slightly over 49,946 charcters
in the Morohashi : Dai Kan-Wa jiten. (The last character in
the supplement is numbered 49,964, but a small, undetermined
number of characters have been assigned prime rather than
discrete numbers - e.g., 366' follows 366, 13359' follows
13359 - making the exact total uncertain.) The zhonghua da
zidian has approx 42,800 single character entries, and some
of the explanation for the larger figure in Morohashi is of
course the large amount of Japanese Kokuji and an
extraordinary number of unusual and a abbreviated forms.

        someone said that there are *very many* (No I won't repeat
        the amazing figure because it is wrong!) charcters in Kangxi
        zidian but ...

The Kanxi zidian lists 49.030 characters and of these 1995
are variant forms, leaving a total of 47,035 different
characters.

Well if this is not enough to convince you here is some more
quotations this time by mr Joseph Becker

=>*Sigh*, OK, here goes.  Nearly all of the designers of Unicode are
=>themselves Han character junkies, but we also have a responsibility to
=>make Unicode usable in practice.  There is no value whatsoever in going
=>crazy counting characters in Han dictionaries.  Let me explain:
=>
=>The objects encoded in Unicode are the characters in "modern text
=>communication use".  Roughly, this might be approximated as the union
=>of the characters (not glyphs) used in printing the text of all major
=>newspapers and magazines in the world this year.
=>
=>More relevantly, if an object is to be used as an encoded character in
=>text communication, then when you send it to someone else's computer,
=>their computer must have a corresponding picture in its font resources,
=>otherwise they won't see it!  This means that you can divide the world
=>roughly into two kinds of characters:
=>
=>    > Public-use characters:  Characters that will get their pictures into a
=>lot of commonly-purchased fonts, so that thousands or millions of
=>people can use them for communication
=>
=>    > Private-use characters:  Characters that may be used within a very
=>small community, perhaps one or two installations, or even individuals,
=>but will not be worthwhile for font vendors to include in general-market
=>fonts
=>
=>There are MANY types of things that fall into the category of
=>"Private-use characters":  rare Han characters, characters of rare
=>languages, private writing systems (e.g. some professor's personal
=>phonetic symbols for a langauge he/she is working on), technical
=>symbols used by specialists in various fields, corporate logos, a million
=>random dingbats, "graphic" cell fragments of 2-dimensional drawings,
=>personal creations (e.g. my signature), creative treatments of text (e.g.
=>whole English words considered as units), and indeed, in general,
=>ANYTHING.
=>
=>Unicode has no desire at all to forbid any of these objects from being
=>communicated between consenting computers.  The Unicode position is
=>simply to insist that a sensible dividing line be placed between Public-use
=>and Private-use objects.  Public-use characters will be represented as
=>text character codes in the normal way, and be communicable in the
=>normal way because font vendors will sell fonts containing their glyphs
=>and lots of people will buy those fonts.  Private-use characters can be
=>handled by a whole variety of DIFFERENT computer mechanisms, e.g.:
=>
=>    > User Space:  Unicode provides 4096 cells that may be assigned
=>character codes by consenting systems, which presumably will share
=>private fonts for rendering them.
=>
=>    > Composition (character sequences):  All major scripts contain
=>extension mechanisms for creating new characters; e.g. for the
=>Greek/Latin/Cyrillic family the mechanism is diacritical marking.  It is
=>absurd to attempt to pre-encode all possible combinations of characters
=>with diacritical marks (a fact that some folks have taken as a challenge
=>...).  What is useful is to make sure that text-handling facilities
=>themselves contain parallel generative mechanisms.  So, Unicode
=>specifies that diacritically marked characters are to be represented as a
=>SEQUENCE of codes, e.g. the base character followed by the mark
=>character.  It is presumed that software will dynamically parse such
=>sequences and do the proper things when rendering, letter-counting,
=>etc.  Since it is appropriate to represent such objects by sequences of
=>characters, the number of such composites representable in Unicode
=>goes far beyond 65,000 (didn't think of that, ha?).  Now, the so-called
=>"65,000+" Han characters are just extensions built up according to
=>strict compositional principles. At some point, it will make far greater
=>sense to represent the rare ones as a cobbled-together composition of
=>fragments, which they are, rather than as unique general-use characters,
=>which status they do not deserve.
=>
=>    > Gaiji:  "Gaiji" by definition means characters that are outside the
=>set that you have defined at the moment.  Since there will always be
=>gaiji, it makes sense to respond to this fact by providing mechanisms that
=>let a user define, draw, and transmit personally-created characters (e.g.
=>I might make one for my signature).  Notice that this sort of mechanism
=>exists in computer systems, but does NOT treat the new objects via the
=>same data structures as ordinary characters.
=>
=>    > Data structures:  People are free to communicate ANYTHING via
=>computer, but that does not mean that anything has to receive a text
=>character code.  There are other data structures in computing.  Suppose
=>your life's work revolves around bridge girder joints.  Suppose there
=>are 1,024 different types of bridge girder joints that you talk about all
=>the time.  Does this mean that they should receive character codes in
=>Unicode?? No, the bridge girder joint people should get together and
=>design and promulgate their own data structures, software, and systems
=>to enable them to deal with these objects.  Precisely the same is true for
=>people who deal with rare Han characters, which for all I know form a
=>smaller community than the bridge girder joint people (no mail on this,
=>please).  Anyhow, the point is that when it comes to specialized
=>applications of interest to a limited community, including rare Han
=>character fanatics, the answer is simply to define and use their own
=>computer mechanisms to handle their data.
=>
=>
=>
=>Summary:  Unicode addresses only "Public-use characters" which meet
=>the criterion that font vendors will sell fonts containing glyphs for them
=>and the general public will buy those fonts.  There are millions of other
=>objects that can and should be communicated via computer, of which
=>rare Han characters are just one example, but those objects are best
=>handled by mechanisms other than assigning character codes to them.

all the best from mrfung

So many characters so little time!

PS. I can get back to this topic if needed but please think carefully
about this before posting! I will quote some more figures of usage
and frequency as I have built up a input-method for chinese I feel
qualified to discuss this topic and I would rather move this discussion
into talking about algorithms for syntactic analyzis of modern chinese
and vocabulary "cihui" and so on...

BTW some of you may find it amusing that one of the originators
of the Unicode-standard proposal mr  Joseph Becker has suggested
a title to a soon to be a major new USDA pamphlet:  "Chemical
Removal of People Who Tell You There are More Than 65,000
Chinese Characters" :-)


From @cuvmb.cc.columbia.edu:CCNET-L@UGA.BITNET Sun Feb 18 09:36:40 1990
Received: from CUVMB.COLUMBIA.EDU (cuvmb.cc.columbia.edu) by sirius.ctr.columbia.edu (4.1/5.10) id AA02861; Sun, 18 Feb 90 09:36:35 EST
Received: from CUVMB.COLUMBIA.EDU by CUVMB.COLUMBIA.EDU (IBM VM SMTP R1.2.1) with BSMTP id 1198; Sun, 18 Feb 90 09:36:29 EST
Received: from PUCC.PRINCETON.EDU by CUVMB.COLUMBIA.EDU (Mailer R2.05) with
 BSMTP id 2638; Sun, 18 Feb 90 09:36:26 EST
Received: from PUCC.BITNET by PUCC.PRINCETON.EDU (Mailer R2.06X) with BSMTP id
 6202; Sun, 18 Feb 90 09:36:18 EST
Date:         Sun, 18 Feb 90 13:17:35 +0100
Reply-To: Lars-Erik Fredriksson <mrfung%NADA.KTH.SE@cuvmb.cc.columbia.edu>
Sender: Chinese Computing Network <CCNET-L%UGA@cuvmb.cc.columbia.edu>
From: Lars-Erik Fredriksson <mrfung%NADA.KTH.SE@cuvmb.cc.columbia.edu>
Subject:      All these strange charcters...
Comments: To: CCNET-L@UGA.UGA.EDU
To: Multiple recipients of list CCNET-L <CCNET-L@uga>
Status: RO

Well I just thought it was better to amend just one little bit more on the
topic of "so many charchters so little ink" (i.e. code space)

I have had some very interesting pieces of information from the Unicode
designers, most notably mr Joseph Becker but there are several tidbits from
different sources.


...................


It is worth adding only that one of the members of the CCCII group in
Taiwan, which has amassed the largest database of something like 75,000 Han
glyphs, told us succinctly:

    > "Of these 75,000, only 5,000 are real characters; the remaining
70,000 are variant forms of them."

If you pause to reflect on how these variant glyph forms evolved (mistakes
or innovations by scribes, etc.), and on how many different characters the
average person can be expected to actually read (about 5,000), you will see
that this comment is necessarily true.

Chinese characters have a tendency to induce hallucinations in us
Westerners (especially us Midwesterners ...).   There's even a book on the
subject, DeFrancis's "The Chinese Language: Fact and Fantasy".  Listening
to computer scientists telling each other scare stories about Chinese
characters is a lot like listening to kids camping out in a pup tent
telling each other ghost stories on a stormy night ...  Hey, I heard
there's this really big Chinese dictionary that has 200,000 characters!  Oh
yeah, well I heard there's a really REALLY big one that has 300,000!!

Although "Night of the Living JIS Kanji, Part III" is admittedly a fun
scare, please do not actually believe all the fictional nonsense you hear.
The true fax are more along the following lines:

    > In Chinese, 2,000 characters account for about 99.5% of modern text.
The remainder is a tail of very low-frequency usage, adding about 6,000
more characters for a total of around 8,000 used in generic modern
publishing (e.g. newspapers and magazines).  Unfortunately, a few agencies
such as the Taiwan phone company have encouraged creative
micro-distinctions in name characters, nominally adding about 15,000 forms
that have no use in general text communication.  An educated person's
passive reading vocabulary might be in the range of 5,000 characters,
although the active-use vocabulary would still be much closer to 2,000.  So
few characters can still generate zillions of words, since most Chinese
words are two-character compounds.  The linguist Yuan Ren Chao isolated a
set of about 2,100 basic characters, from which he found all others to be
derived as relatively late micro-differentiations.  The Chinese classics
themselves have a small vocabulary (again 2,000 ballpark) because they
predate the elaborations that later took place in character forms.

    > In Japanese, a study determined that around 2,500 characters are used
in modern publishing, EXCEPT for womens' magazines, whose purple prose has
a vocabulary of about 3,500!

    > Korean is often written with no ideographs at all, so usage levels
are similar to but less than in Japanese.

    > The Research Libraries Group, which maintains a database of
publications in Chinese, Japanese, and Korean, uses the (R)EACC code, whose
14,000-odd characters are sufficient to that purpose.  This the same
magnitude as a corpus collected at UC Berkeley with the specific goal of
enumerating all Chinese characters in modern use.

Scholarly compendia of obscure and obsolete characters run in the range of
50,000-70,000.  These are names of long-vanished people and places, terms
for species of bugs and flowers, and an endless number of micro-variations
and writing errors generated by 4,000 years of creative transcription.  Are
these 50,000-odd characters ever used?  No.  Can anyone read them?  No.
But ah, this form turned up in a Tang manuscript, and no-one knows what it
meant, so we'd better stick it in a dictionary so it won't get lost ...

There is no such thing as "the current Chinese computer standard", but
rather many competing collections.  Here are some of the most important
ones:


Taiwan CCCII     4,808  -- Common
                17,032  -- Next most frequent
                11,517  -- Variant forms of 6,699 of the preceding
                ------
                33,357


Taiwan "Big 5"   5,401  -- Common
                 7,652  -- Next most frequent
                ------
                13,053


China GB2312-80  3,755  -- Level 1
                 3,008  -- Level 2
                ------
                 6,763  -- the XinHua news agency adds 694 characters, for a
 total of
7,457 in modern news use

GB simplified sets "2", "4" and traditional sets "1", "3", "5" forthcoming


NISO Z39.64 EACC 9,876  -- Layer 1 (baseforms)
                 3,605  -- Layers 2-12 (variants)
                ------
                13,481


JIS X0208-1983   2,965  -- Level 1
                 3,388  -- Level 2
                ------
                 6,353

                 5,843  -- Level 3 forthcoming


KS C5601-1987    4,888  -- this includes about 250 pairs of duplicates!


We are currently building a table to cross-reference most of the above
enumerations, in order to evaluate the size of their union, which would
define a collection of all CJK characters that are really in general use.
As usual, it seems that the answer will be in the 14,000 ballpark.

------------------------------------------------

As it turned out, the union of JIS Levels 1 & 2, GB2312 Levels 1 & 2, Big 5
Levels 1 & 2, and KS C5601 came out to about 16,300 characters.

It is worth looking at the ones that were UNIQUE to one of those standards:

    JIS-unique:     700  -- around 100 "kokuji", 500 simplified forms, 100
others

    GB-unique:     2160  -- around 2000 simplified forms, 100 others

    Big5-unique:   6260  -- many micro-variants, rarer characters

    KS-unique:      110

Note that "Big 5" extends much farther into rare characters than the other
standards (the ROC national standard CNS 11643 is virtually identical).  If
you subtract off the excess Big 5 forms that are entering the "rare" zone,
and the also the national simplified variants in the other standards, then
the number of true "common-use" Han characters sinks to about 7,500.

By the way, the union of just "Level 1" of each of these standards is about
7,600 before subtracting anything, and at least 2,500 of those are merely
variant forms, so the actual number of "basic" Han characters is, ahem,
about 5,000.


-------------------


So can we get back to some more constructive discussion, like describing
perhaps good searching facilities in chinese text databases (anyone care to
define multicharacter-words, compounds) and the level of smartness in
various inputsystems or related topics.

mrfung


From @cuvmb.cc.columbia.edu:CCNET-L@UGA.BITNET Fri Feb 16 19:40:07 1990
Received: from CUVMB.COLUMBIA.EDU (cuvmb.cc.columbia.edu) by sirius.ctr.columbia.edu (4.1/5.10) id AA26685; Fri, 16 Feb 90 19:40:00 EST
Received: from CUVMB.COLUMBIA.EDU by CUVMB.COLUMBIA.EDU (IBM VM SMTP R1.2.1) with BSMTP id 0282; Fri, 16 Feb 90 19:39:57 EST
Received: from PUCC.PRINCETON.EDU by CUVMB.COLUMBIA.EDU (Mailer R2.05) with
 BSMTP id 9854; Fri, 16 Feb 90 19:39:56 EST
Received: from PUCC.BITNET by PUCC.PRINCETON.EDU (Mailer R2.06X) with BSMTP id
 4843; Fri, 16 Feb 90 19:39:47 EST
Date:         Fri, 16 Feb 90 15:46:00 EST
Reply-To: DAY%IUBACS@cuvmb.cc.columbia.edu
Sender: Chinese Computing Network <CCNET-L%UGA@cuvmb.cc.columbia.edu>
From: DAY%IUBACS.BITNET@cuvmb.cc.columbia.edu
Subject:      useful publications on character sets
To: Multiple recipients of list CCNET-L <CCNET-L@uga>
Status: RO

There are some publications which members of the CCNET-L list
should be aware of:

    1. *Non-Roman Scripts: A Software Directory*, compiled by
Susan MacDougall, 1988. ( available from the compiler, 2 Wirraway
Crescent, Scullin, ACT 2614 Australia)

    2. John Clews, *Language Automation Worldwide: The
Development of Character Set Standards* (Harrogate UK: Sesame
Computer Projects, 1988) (available from the publisher, 8 Avenue
Road, Harrogate, North Yorkshire, HG2 7PG, Great Britain)

    -- p. 128-137 treats character sets for East Asian scripts;
    -- p. 138-149 treats multiple-byte coded character sets for East
Asian scripts, including JIS C 6226-1978 and 1983, Taiwan's CCCII
(volumes 1-3), SICGCC, CNS-11643, "Big 5," GB2312-80 and GB2313,
Korean KS C 5601-1986 and KIPS
    -- p. 150-165 treats international standardization sets REACC
(RLIN East Asian Character Code)/EACC (Eas Asian Character Code),
tape formats for MARC records at the Library of Congress and
JAPAN/MARC, and the issues of ANSI/EBCDIC compatibility and
conversion.

    3. *Sesame  Bulletin*, which deals with the automation of
text in non-Roman scripts (quarterly, same address as above)

From CCNET-L@uga.cc.uga.edu Tue Nov 10 22:52:20 1992
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.67/5.10) with SMTP id AA14594; Tue, 10 Nov 92 22:52:06 -0500
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 5491; Tue, 10 Nov 92 22:49:01 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.08 PTF008) with BSMTP id
 2825; Tue, 10 Nov 92 22:48:59 EST
Date:         Tue, 10 Nov 1992 22:49:59 -0500
Reply-To: Stephen G Simpson <simpson@MATH.PSU.EDU>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: Stephen G Simpson <simpson@MATH.PSU.EDU>
Subject:      Unicode mapping table, Big-5 confusion, etc.
Comments: To: ccnet-l@uga.cc.uga.edu
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
Status: RO

Earlier today Ross Paterson (rap@doc.imperial.ac.uk) posted some
information about the Unicode mapping table cjkxref.fix available for
ftp on unicode.org.  Thanks, Ross!  Prompted by this, I ran downstairs
to look at the Unicode books, which are available in the reference
section of our Mathematics / Computer Science library.  The library
reference is:

> The Unicode standard, worldwide character encoding. / Unicode Consortium.
>   Version 1.0. Reading, Mass., Addison-Wesley Pub. Co., Inc., 1991-1992.
>     2 v. ill. 28 cm.
>     "Volume 1 covers Latin, Cyrillic, Greek, Hebrew, and Arabic alphabets,
>   and other alphabets used in countries across Europe, Africa, and the Indian
>   subcontinent. Volume 2 is devoted to unified character codes for Chinese,
>   Japanese, and Korean ideographs"--P. [4] of cover.
>     Includes bibliographical references and indexes.
>     1. Character sets (Data processing) -- Standards. 2. Coding theory.
>  Call#: QA76.76.C53U6 1991
>     Mathematics Library - Reference, 109 McAllister, v.1-v.2

The file cjkxref.fix is apparently supposed to contain essentially the
same information as pages 169-385 of Volume 2.  It is a table listing
the Unicode Chinese characters in Unicode order, followed by the
corresponding codes in other standard coding systems such as GB, Big
Five, CNS 11643, etc.  Each line in the table has 10 fields.  Fields 1
through 6 are as described by Ross:

1. Unicode (4 hex digits)
2. GB (row/column)
3. Big-5 (4 hex digits)
4. CNS 11643 (4 hex digits)
5. JIS (row/column)
6. KSC (row/column)
     details of KSC: entry is S-rrcc where rr is the row, cc is the column,
     and S = 0 indicates KCS 5601-1987, S = 1 indicates KCS 5657-1991.

Some other fields described are:

 IBM Selected Kanji Set (hex)

 JEF (hex)

 ANSI Z39.64-1989 (hex)

 Xerox Character Set (two octal codes separated by a colon).

The Xerox codes are in field 9 but I am not sure which field the ANSI
and JEF codes are in.

I know it is a topic that has been discussed here before, but I am
still confused about the mapping between Big-5, CNS 11643, and ET
codes.  I know the mapping is for the most part rather simple, and I
thought I understood it, but cjkxref.fix and some remarks in the
Unicode book convinced me that I don't understand it after all.  Could
somebody please explain this again, in light of cjkxref.fix?

Stephen G. Simpson
Department of Mathematics, Pennsylvania State University
333 McAllister Building, University Park, State College, PA 16802
Office phone: +1 814 863-0775      Internet: simpson@math.psu.edu
Home phone: +1 814 238-2274        Bitnet: T20@PSUVM
FAX: +1 814 865-3735

From CCNET-L@uga.cc.uga.edu Wed Nov 11 10:46:26 1992
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.67/5.10) with SMTP id AA20008; Wed, 11 Nov 92 10:46:24 -0500
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 8190; Wed, 11 Nov 92 10:43:08 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.08 PTF008) with BSMTP id
 8869; Wed, 11 Nov 92 10:43:06 EST
Date:         Wed, 11 Nov 1992 16:40:52 +0100
Reply-To: "(Urs Widmer)" <a06g@ALF.ZFN.UNI-BREMEN.DE>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: "(Urs Widmer)" <a06g@ALF.ZFN.UNI-BREMEN.DE>
Comments: To: ccnet-l@uga.bitnet
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
Status: RO

First a word of appology: I sendt a file, where I kept some
unicode-material by mistake to the whole list because it had the
same name as the following file I prepared for sending. Please
disregard that other file with unfortunately is quite long. You
will still read this one???

-----------------------------------------------------------------
As soon as I read about the availability of the machine readable
UNICODE reference list (cjkxref.fix) I ftp'ed this file. It's great
that the authors of UNICODE did put this valuable file in the
public domain for everybody to use it.

The first thing to do was to bring it into DBASE-format so that data
might be accessed easier. Playing around with the data I found some
inconsistencies with the  number of charakters in the standards included
into UNICODE as  indicated on p. 20 of "The Unicode Standard", vol. 2.

I would feel much easier if I could understand these differences;
May be I just make some sort of intellectual mistake I am not aware
of. Within DBASE I counted the fields where there are codes for each
of the standards and it's substandards (if available). In the following
list I put character number in the UNICODE BOOK and those from the
CJKXREF.FIX-file together. Who could give some hints?

Code         UNICODE-book  cjkxref.fix

ANSI (EACC)     13,053       13,226
BIG FIVE        13,481       13,063
CNS 11643       13,051              -------------->  16,469
CNS 11643 USER   3,418              -------------/
  CNS-1                       5,411 ----> 13,061-->  17,258
  CNS-2                       7,650 ---/         /
  CNS-E                       4,197 ------------/
GB 2312 (GB0)    6,763        6,763
GB 12345 (GB1)   2,176        2,355
GB 7589 (GB3)    7,327        4,834      <=======
GB 7590 (GB5)    7,039        2,840      <=======
GB7                 41           42
GB 8565 (GB8)      287          290
JEF              3,149        3,144
JIS X 0208       6,355        6,356
JIS X 0212       5,801        5,801
KSC 5601         4,888        4,888
KSC 5657         2,856        2,856
XEROX            9,776        9,747

UNICODE         21,001       21,204


Some code counts in cjkxref.fix summe up to the same value as given in
the UNICODE-book, but in some cases there are big differences (<======).
The UNICODE-book says that the table refered to above gives the "number
of characters included from each" standard. The BOOK says from GB3 are
included 7,039 characters whereas in CJKXREF.FIX I find only 4,834.
But also for the minor differencies it would be nice to know the reason.

Greetings
Urs


----------------------------------------------------------------------------
Urs Widmer           Tel.:  (0049)421-218-3188      CHINESISCH UND COMPUTER
PC-Labor, MZH        FAX:   (0049)421-218-2720       Journal for Computing
Universitaet Bremen                                  in Oriental Languages
2800 Bremen 33                                             (in German)
Germany              email: <A06G@alf.zfn.uni-bremen.de>
----------------------------------------------------------------------------

From CCNET-L@uga.cc.uga.edu Wed Nov 11 10:50:07 1992
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.67/5.10) with SMTP id AA20035; Wed, 11 Nov 92 10:49:43 -0500
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 8191; Wed, 11 Nov 92 10:46:15 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.08 PTF008) with BSMTP id
 8892; Wed, 11 Nov 92 10:43:19 EST
Date:         Wed, 11 Nov 1992 16:34:59 +0100
Reply-To: "(Urs Widmer)" <a06g@ALF.ZFN.UNI-BREMEN.DE>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: "(Urs Widmer)" <a06g@ALF.ZFN.UNI-BREMEN.DE>
Comments: To: ccnet-l@uga.bitnet
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
Status: RO

Date	11/3/92
Subject	Unicode 1.0.1 Addendum
From	Mark Davis
To	  Unicode

Unicode 1.0.1 Addendum                                      92.11.03   8:52


                         UNICODE 1.0.1

The following document is an ASCII version of the Unicode 1.0.1
addendum, which has been added to Volumes 1 and 2 of The Unicode Standard.
Because the formatting has been lost and the original text contains non-
ASCII characters, a dollar sign is used as a placeholder instead, and
the text has been modified slightly for readability.

Printed copies of the addendum will be sent to Unicode corporate,
associate and individual members. Others may get a printed copy by
sending a stamped, self-addressed envelope to the Unicode Consortium
at the address below, or may get a fax copy on request. Copies of the
ASCII version of this document can also be obtained by anonymous FTP
from Unicode.Org.

________________________________________________________________________

Recipient is granted the right to make copies in any form for internal
distribution and to freely use the information supplied for the purposes of
creating and implementing products that comply with the Unicode Standard.

The authors and publishers have taken care in preparation of this work, but
make no expressed or implied warranty of any kind and assume no responsibility
for errors or omissions. No liability is assumed for incidental or
consequential damages in connection with or arising out of the use of the
information or programs contained herein.

Copyright (c) 1991-1992, Unicode, Inc. All Rights reserved. Unicode (tm) is a
registered trademark of Unicode, Inc.

________________________________________________________________________

1. Introduction

As discussed in Volumes 1 and 2, small changes have been made to Unicode
1.0 in order to incorporate it into the international character encoding
standard, ISO 10646, which was approved by ISO as an International
Standard in June, 1992. The Unicode Consortium plans to issue Unicode
1.1 in early 1993. The character content and encoding will be identical
to that of ISO 10646. To that end, Unicode 1.1 will include
approximately 5,400 additional characters from ISO 10646 that are not
already in Unicode 1.0.

In order to expedite use of Unicode in the interim, the Unicode
Consortium is issuing an intermediate version, Unicode 1.0.1, which
consists of Unicode 1.0 modified by the changes necessary to make the
character codes a proper subset of ISO 10646.

This paper describes the differences between Unicode 1.0.1 and Unicode
1.0 (for more information, see Volume 1, pp. xix-xx and Volume 2, pp.
4-9 and 427-431). Implementations that use Unicode 1.0.1 as thus defined
will be completely compatible with Unicode 1.1, and therefore fully
compatible with ISO 10646.

Mapping of Unicode characters to the national and industry standards
will be finalized in Unicode 1.1 to reflect comments from reviewers and
alignment with ISO 10646. In early 1993 a technical report will be
issued that defines the content of Unicode 1.1, including the complete
revised mapping tables. The mapping tables will be available in soft
form by anonymous FTP. The technical report will be sent to members of
the Unicode Consortium (inc. associates & individuals); others may
obtain copies or information about FTP by contacting:

    The Unicode Consortium
    1965 Charleston Road
    Mountain View, California 94043 USA

    E-mail: unicode-inc@hq.metaphor.com
    Phone: (415) 961-4189
    Fax:   (415) 966-1637


2. Final Zone Allocations

The following zone reallocations do not affect any allocated Unicode 1.0
characters.

A. Unicode Allocation
Range               Cells   Name/Contents
U+0000 => U+4DFF    19,968  A-ZONE Alphabets, syllabaries, symbols
                            (the 65 control codes are excluded)
U+4E00 => U+9FFF    20,992  I-ZONE Ideographs
U+A000 => U+DFFF    16,384  O-ZONE Reserved for future assignment
U+E000 => U+FFFF     8,192  R-ZONE Restricted use
                            (FFFE & FFFF are excluded)
B. R-ZONE Allocation
Range               Cells   Name/Contents
U+E000 => U+F8FF     6,400  Private Use Area
                            (Corporate Use starts at F8FF)
U+F900 => U+FFEF     1,776  Compatibility Zone
                            (including presentation forms)
U+FFF0 => U+FFFF        16  Specials
                            (FFFE & FFFF are not character codes,
                            and are excluded)

3. Characters deleted or withdrawn for further study:

A. Groups of characters deleted
Range               Group Name
U+0E70 => U+0E74    Thai Phonetic Order Vowel signs
U+0EF0 => U+0EF4    Lao Phonetic Order Vowel signs
U+1000 => U+104C    Tibetan script

B. Individual characters deleted
U+03DB          $   GREEK SMALL LETTER STIGMA
U+03DD          $   GREEK SMALL LETTER DIGAMMA
U+03DF          $   GREEK SMALL LETTER KOPPA
U+03E1          $   GREEK SMALL LETTER SAMPI
U+2300          $   APL COMPOSE
U+2301          $   APL OUT

4. Characters unified

>From    With    Image   Old Name
U+0371  U+0314  $   GREEK NON-SPACING DASIA PNEUMATA
U+0372  U+0313  $   GREEK NON-SPACING PSILI PNEUMATA
U+0384  U+030D  $   GREEK NON-SPACING TONOS
U+04C5  U+049A  $   CYRILLIC CAPITAL LETTER KA OGONEK
U+04C6  U+049B  $   CYRILLIC SMALL LETTER KA OGONEK
U+04C9  U+04B2  $   CYRILLIC CAPITAL LETTER KHA OGONEK
U+04CA  U+04B3  $   CYRILLIC SMALL LETTER KHA OGONEK
U+3004  U+4EDD  $   IDEOGRAPHIC DITTO MARK

5. Characters moved

>From    To      Image   Old Name
U+0370  U+0345  $   GREEK NON-SPACING IOTA BELOW
U+0385  U+0344  $   GREEK NON-SPACING DIAERESIS TONOS
U+03D7  U+037E  $   GREEK QUESTION MARK
U+03D8  U+0374  $   GREEK UPPER NUMERAL SIGN
U+03D9  U+0375  $   GREEK LOWER NUMERAL SIGN
U+03F3  U+0384  $   GREEK SPACING TONOS
U+03F4  U+0385  $   GREEK SPACING DIAERESIS TONOS
U+03F5  U+037A  $   GREEK SPACING IOTA BELOW
U+05F5  U+FB1E  $   HEBREW POINT VARIKA
U+32FF  U+3004  $   JAPANESE INDUSTRIAL STANDARD SYMBOL

6. Character blocks rearranged

The explicit list will be in Unicode 1.1.
Range               Group Name
U+32D0 => U+32FE    Circled Katakana: The 1.1 characters will be
                    arranged in modern order:
                    e.g., A, I, U, E, O, KA, KI, ...
U+FE80 => U+FEFC    Basic glyphs for Arabic language: The 1.1
                    character shapes will be arranged in different
                    order: Isolate, Final, Initial, Medial

7. Character semantics changed

A. Zero Width Joining
U+200C          $J  ZERO WIDTH NON-JOINER
U+200D          $J  ZERO WIDTH JOINER

In the merger with ISO 10646, the semantics of these two characters have
been given a narrow interpretation. This brings added precision to the
explanation given in Volume 1, page 77.

The intent of these characters is to address cursive graphical
connection between the glyphs of a script, e.g. in scripts like Arabic
whose printed form emulates handwriting. NON-JOINER and JOINER are best
thought of as behaving like tiny letters that neighboring glyphs may
connect to (JOINER) or avoid connecting to (NON-JOINER). They are thus
processed as ordinary cursive letters rather than as control characters.
NON-JOINER and JOINER affect how the two neighboring glyphs connect to
them, not to each other. As such, they have no direct relationship with
ligature formation; in particular, JOINER does not in any way request
that its two neighbors be ligatured to each other. Indeed, both NON-
JOINER and JOINER may break up ligatures by interrupting the character
sequence required to form the ligature.

The precise relationship between cursive appearance and ligatured
appearance may differ from script to script, and therefore the precise
usage of these characters is script-dependent. In the case of Latin
typography, cursiveness (handwriting emulation) and ligaturing are
independent. Thus the text on Volume 1, page 77, may be clarified as
follows:

f + JOINER + i will not form the ligature fi. Instead, if cursive
versions of the f and i are available in the font, each will
independently connect to the JOINER on the appropriate side (having the
same appearance as f + i).

Usage of optional ligatures such as => is not controlled by any codes
within the Unicode standard, but is determined by protocols or resources
external to the text sequence.

As further illustration, let a hyphen stand for a cursive connection to
a preceeding or following letter. Then in a cursive Latin font we would
get the following results (with N standing for NON-JOINER and J for
JOINER).

Unicodes        Rendering
f i s h         f-  -i-  -s-  -h    (optionally using a fi- ligature)
f J i s h       f-  -i-  -s-  -h
f N i s h       f    i-  -s-  -h
f J N i s h     f-   i-  -s-  -h
f N J i s h     f   -i-  -s-  -h

With regard to the Arabic script, the statements in Volume 1, page 77,
remain correct. In Volume 2, page 390, Arabic rules L2 and L3, the
JOINER can be used to get the appearance in parentheses.

With regard to conjuncts in Indic scripts, the statements in Volume 1,
pp. 53-56, and Volume 2, pp. 399-414, remain correct. However for
clarity, in pp. 399-414 the term ligature should be replaced by the term
conjunct.

B. Byte Order Mark
U+FEFF          $J  ZERO WIDTH NO-BREAK SPACE

In addition to the meaning of BYTE ORDER MARK, as defined in Volume 1 of
the Unicode standard, the code value U+FEFF may now also be used as ZERO
WIDTH NO-BREAK SPACE (ZWNBSP). For convenience in discussion, it can
also be referred to by this name (which is the ISO 10646/Unicode 1.1
name for U+FEFF).

ZWNBSP behaves like a U+00A0 NO-BREAK SPACE in that it indicates the
absence of word boundaries; however, ZWNBSP has no width. For example,
this character can be inserted after the fourth character in the text
"base+delta" to indicate that there should be no line break between the
"e" and the "+" (for more information, see Volume 2, pp. 6-7).

8. Characters added

There are a large number of characters that will be added to Unicode 1.1
that will be included in the technical report, as explained above. These
will include the following characters, which were omitted from Unicode
1.0.

U+0A4D          $   GURMUKHI SIGN VIRAMA
U+0A8D          $   GUJARATI VOWEL CANDRA E
U+0A91          $   GUJARATI VOWEL CANDRA O
U+0AC9          $   GUJARATI VOWEL SIGN CANDRA O
U+0B56          $   ORIYA AI LENGTH MARK
U+25EF          $   LARGE CIRCLE
U+FFE8          $   HALFWIDTH FORMS LIGHT VERTICAL
U+FFE9          $   HALFWIDTH LEFTWARDS ARROW
U+FFEA          $   HALFWIDTH UPWARDS ARROW
U+FFEB          $   HALFWIDTH RIGHTWARDS ARROW
U+FFEC          $   HALFWIDTH DOWNWARDS ARROW
U+FFED          $   HALFWIDTH BLACK SQUARE
U+FFEE          $   HALFWIDTH WHITE CIRCLE

9. Character mapping changed

>From    To      Image   XJIS    Name
U+00AD  U+2010  $   815D    JIS HYPHEN
U+20DD  U+25EF  $   81FC    JIS COMPOSITION CIRCLE




                       Volume 2 Errata

1. Page 6
Change in lines 26, 27: ... ZERO WIDTH SPACE can be used to indicate
word boundaries in scripts like Thai...

2. Page 19
The glyphs in Figures 2-14 and 2-15 were printed incorrectly.  The 4
correct glyphs are:
Figure      Image on Left   Image on Right
2-14        $               $
2-15        $               $

3. Pages 60,66,75,79,91,131,135,140,143,150,264,277,301,311,343
There are are number of glyphs which were printed incorrectly in various
places in Volume 2.  The most serious are:
Code        Image   Pages
U+71F7      $       60, 131, 264
U+773E      $       66, 135, 277
U+809C      $       75, 140, 301
U+8480      $       79, 143, 311
U+908E      $       91, 150, 343

4. Page 401
Change wording and rule in C3: ...The dead consonant RAd changes to a
non-spacing mark RAx when followed by a consonant cluster. The...
    RAn +   VIRAMAn =>  RAx

5. Page 403
Add L1a: The ZERO-WIDTH JOINER can be used to produce the so-called
eyelash-RA (RAh) used in Marathi. RAh is a spacing half-consonant which
is not subject to special ordering of RAx (O2).
    RAn +   ZWJ +   VIRAMAn =>  RAx

6. Page 404
Change O2 to:
    RAx  +  Cluster =>  Cluster  +  RAx
In processing a line of glyphs, this rule is not applied twice to the
same RAx.

7. Page 429
Line 7 has the period misplaced, and should read:
Visual: .KO ,bmw 500 A SI TI

From @UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU Sun Jul 25 19:49:06 1993
Return-Path: <@UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU>
Received: from uga.cc.uga.edu by ifcss.org (4.1/IFCSS-Mailer)
	id AA04253; Sun, 25 Jul 93 19:48:52 CDT
Message-Id: <9307260048.AA04253@ifcss.org>
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 4346; Sun, 25 Jul 93 20:47:47 EDT
Received: from UGA.CC.UGA.EDU (NJE origin LISTSERV@UGA) by UGA.CC.UGA.EDU (LMail V1.1d/1.7f) with BSMTP id 1836; Sun, 25 Jul 1993 20:47:46 -0400
Date:         Mon, 26 Jul 1993 09:46:48 JST
Reply-To: christian wittern <g53150@SAKURA.KUDPC.KYOTO-U.AC.JP>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: christian wittern <g53150@SAKURA.KUDPC.KYOTO-U.AC.JP>
Subject:      Uploaded to ifcss: Unicode Han-Character Properties Database
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
Status: R

Dear Netters,

A couple of weeks ago, I posted a call for contributions for
this database project. Although the answers have not been too
$x enthusiastic, I compiled some material for a first release and uploaded
 {it to ifcss.org, where it can be found in /software/data/unicode-hanchar.

Any comments welcome, especially new contributions or corrections.
I will stay offline from wednesday for three weeks, so please be
patient while waiting for a response :-)

I include some extracts from the file uh-intro.doc, which can be found
on the above location:

This file is part of the Unicode Han-Character Properties Database
Initial Release 23.7.93

Introduction

The Unicode Han-Character Properties Database is an attempt to bring
character property mappings from different coding schemes
used in East-Asia together under the common roof of Unicode.

Some weeks ago, a call for contributions for this database
has been sent to various lists on the network. Although the
response was not enthusiastic (I got two new contributions, one
 {from Hartmut Bohn, Trier, author of ChInDex and one from Carlos McEville,
author of the excellent E-text utility Bamboo Helper, which are gratefully
acknowledged here), I will release some material now and hope that
contributions will continue to come in, encouraged by the success
of this first release. I will continue to support this database
project by adding new contributions as they arrive, and correct errors
as they are pointed out to me.

Although (to my knowledge) applications which fully support Unicode
are not yet available, some advantages can already be taken from
the mapping of the table released by the Unicode corporation
in CJKXREF. I used the release of 1992/12/24 for the mappings in
this databases.

Three tables are included in this initial release:

UHPINYIN.TXT in zipfile UHPINYIN.ZIP

The <tab> separated columns in this file contains the following information:
{_
1. Unicode  (4 hexadezimal digits)
2. - 10. Pinyin readings

UHDICS.TXT in zipfile UHDICS.ZIP

The <tab> separated columns in this file contains the following information:

1. Unicode  (4 hexadezimal characters)
2. Volume and page in Morohashi (2+4 digits)
3. Character Number in Nelson (4 digits)
4. Character Number in Shinjigen (4 digits)
5. Character Number in the Fareast Dictionary Series (4 digits)

UH4C.TXT in zipfile UH4C.TXT

The <tab> separated columns in this file contains the following information:

1. Unicode  (4 hexadezimal digits)
2. Four Corner Code (5 digits)
3. Second Four Corner Code (5 digits) occasional added for convenience

An additional file UH-XTRAC.ZIP contains MS-DOS executables for extracting
the data to BIG5, JIS and GB using the mappings in CJKXREF.FIX (24.12.1992).
Users of Non-MSDOS platforms can not yet be provided with a convenient way
to easily extract the data, some hints on how a program to achieve this
should be constructed are found in UH-XTRAC.DOC.

Unicode Han-Character Properties Database
Compiler:
Christian Wittern g53150@sakura.kudpc.kyoto-u.ac.jp

Please report any mistakes and suggestions to me.

Please credit the contributors if you use material from this database.

From @UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU Wed Aug  4 03:01:33 1993
Return-Path: <@UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU>
Received: from uga.cc.uga.edu by ifcss.org (4.1/IFCSS-Mailer)
	id AA01006; Wed, 4 Aug 93 03:01:18 CDT
Message-Id: <9308040801.AA01006@ifcss.org>
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 6958; Wed, 04 Aug 93 04:00:02 EDT
Received: from UGA.CC.UGA.EDU (NJE origin LISTSERV@UGA) by UGA.CC.UGA.EDU (LMail V1.1d/1.7f) with BSMTP id 4718; Wed, 4 Aug 1993 03:58:28 -0400
Date:         Wed, 4 Aug 1993 09:56:50 +0200
Reply-To: Zhenbing Zeng <zeng@MATHEMATIK.UNI-BIELEFELD.DE>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: Zhenbing Zeng <zeng@MATHEMATIK.UNI-BIELEFELD.DE>
Comments: To: ccnet-l@uga.cc.uga.edu
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
Status: R

Han Unification in UNICODE:
===========================

One major challenge in creating code elements is accommodating the many
thousands of ideographs used in Chinese, Japanese, and Korean text(called
CJK text for short). ... ...
In China, they are called Hanzi; in Korea, Hanja; in Japan, Kanji.

Current national standards for ideographs in Japan, China, Korea, and Taiwan
define a totoal of more than 31,000 ideographs used for written text in theses
countries.

The Unicode standard uses Han unification to consolidate Chinese, Korea, and
Japanese ideographs.

The CJK Joint Research Group has identified and categorized over 11,000
duplicate ideographs in a process call Han unification. By minimizing the
duplication of identical ideographs in separate languages, the Han unified
character set represents all of the standard Han symbols with fewer than
21,000 unique characters.



Chinese characters in GB:
=========================

There exist the following GuoBiao for Chinese characters:
   GB 2312-80 (0)      GB 12345-90 (1)
   GB ??-8?   (2)      GB 7589-87  (3)
   GB ??-8?   (4)      GB 7590-87  (5)
   ?                   ?
   GB 8565-89 (8)      ?

GB.1 contains all characters in GB.0 in traditional form, including those
different characters which have the same simplied form. The same charater
(which has not been simplified) in GB.0 and GB.1 are in same position,
the traditional form and the simplified form of the same are also in same
position if the correspondence is one-to-one.

Each of GB.2 and GB.4 contains more than 6,000 Chinese charaters. GB.3 and
GB.5 are corresponce (like GB.1 and GB.0) of GB.2 and GB.4, respectively.

GB.6 and GB.7? I forgot the exact information.

Simplified and traditional Han characters in UNICODE:
=====================================================


Both of the following simplified character and traditional characters are
contained in Unicode (in different position):

 \    ------
---    _|__
  |   __|__|
  |    ____
  |/  |____|


 \    ------
---    _|__
--    __|__|
---    ____
 __   |    |
|__|  |____|

The following simplified form and traditional form are regarded as the same
one in Unicode:

___|_____|___
   |     |
  __________
 |__________|
 |__________|
      |
______|______
      |
      |


__|__   __|__
  |       |
  __________
 |__________|
 |__________|
      |
______|______
      |
      |



The Unicode Han Characters Cross-Reference:
===========================================

The following file can be obtained by ftp from unicode.org (cjkxref).

# Copyright 1991-1992 Unicode, Inc.
# All Rights reserved.
#
# This file is provided as-is by Unicode, Inc. (The Unicode Consortium). No
# claims are made as to fitness for any particular purpose.  No warranties of
# any kind are expressed or implied.  The recipient agrees to determine
# applicability of information provided.  If this file has been provided on
# magnetic media by Unicode, Inc., the sole remedy for any claim will be
# exchange of defective media within 90 days of receipt.
#
# Recipient is granted the right to make copies in any form for internal
# distribution and to freely use the information supplied in the creation of
# products supporting Unicode.  Unicode, Inc. specifically excludes the right to
# re-distribute this file directly to third parties or other organizations
# whether for profit or not.
#
#
#   Name:               The Unicode Han Character Cross-Reference
#   Unicode version:    1.0.1
#   Table version:      0.0d1
#   Table format:       Format A
#   Date:               24 December 1992
#   Author:             John H. Jenkins (John_Jenkins@taligent.com)
#
#   General notes:
#
#   This table contains the the mappings between the Unicode
#       Han ideographic character set (Unihan) and various
#       national and industrial standards
#
#   Format:
#       There are 10 tab-separated fields, one for each set mapped.
#       These fields are ordered as follows:
#
#       Unicode:
#           4 digit hexadecimal code, beginning at U4E00.
#       GB:
#           5 digit decimal.
#               Digit 1 is the GB subset.
#               Digits 2 to 5 are the code in row/column format.
#           The GB subsets are:
#               0 = GB 2312-80.
#               1 = GB 12345-90.
#               3 = GB 7589-87.
#               5 = GB 7590-87.
#               7 = General Purpose Han Characters for Modern Chinese.
#               8 = GB 8565-89.
#       Big 5:
#           4 digit hexadecimal.
#       CNS:
#           5 digit hexadecimal.
#               Digit 1 indicates a subset of CNS 11643-1986.
#               Digits 2 to 5 are the code in interchange format.
#           The CNS subsets are:
#               1 = Primary.
#               2 = Less frequent characters.
#               E = User characters.
#      JIS:
#          5 digit decimal.
#              Digit 1 is the JIS subset.
#              Digits 2 to 5 are the code in row/column format.
#          The JIS subsets are:
#              0 = JIS X0208-1990.
#              1 = JIS X0212-1990.
#              I = IBM extensions (4 digit hexadecimal).
#      KSC:
#          5 digit decimal.
#              Digit 1 is the KSC subset.
#              Digits 2 to 5 are the code in row/column format.
#          The KSC subsets are:
#              0 = KSC 5601-1987.
#              1 = KSC 5657-1991
#              2 = IBM extensions (4 digit hexadecimal).
#      ANSI Z39.64-1989 (EACC):
#          6 digit hexadecimal.
#      CCCII, level 1:
#          6 digit hexadecimal.
#      Xerox:
#          7 digit octal, with a colon separating each byte.
#      Fujitsu:
#          4 digit hexadecimal JEF code.
#
#      NOTES:
#
#      The mappings in this table between Unicode and GB, CNS, JIS and KSC
#      have been compared to the mapping information provided by the CJK-JRG,
#      which has exhaustively checked and rechecked.  The mappings for these
#      characters may be taken as final and definitive.
#
#      The mappings in this table between Unicode and Big 5, EACC, CCCII, Xerox,
#      IBM and Fujitsu have not been so exhaustively checked.  There may still
#      be errors in these mappings.  Final and authoritative mappings for these
#      character sets will be provided in the near future.  Please notify
#      John_Jenkins@taligent.com of any errors.
#
#      Empty fields contain the single character '*'.
#
#      Any comments or problems, contact John_Jenkins@taligent.com
#
#
4E00    0-5027  A440    1-4421  0-1676  0-7673  213021  213021  241:042 *
4E01    0-2201  A442    1-4423  0-3590  0-7943  213022  213022  250:132 *
4E02    5-1601  *       *       1-1601  *       *       236123  *       *
4E03    0-3863  A443    1-4424  0-2823  0-8650  213023  213023  241:345 *
4E04    *       *       E-2126  1-1602  *       *       2D3026  *       *
4E05    *       *       E-2125  1-1603  *       *       2D3025  *       *
4E06    1-9329  *       *       *       *       *       *       *       *
4E07    0-4582  C945    2-2126  0-4392  0-5618  274F22  216421  *       *
4E08    0-5341  A456    1-4437  0-3070  0-7759  213027  213027  246:341 *
4E09    0-4093  A454    1-4435  0-2716  0-6318  213024  213024  241:113 *
4E0A    0-4147  A457    1-4438  0-3069  0-6330  213026  213026  241:052 *
4E0B    0-4734  A455    1-4436  0-1828  0-8927  213025  213025  241:120 *
4E0C    0-5602  C946    2-2127  1-1604  *       2D332A  216422  316:252 *
4E0D    0-1827  A4A3    1-4462  0-4152  0-6084  21302A  21302A  241:044 *
4E0E    0-5175  C94F    2-212F  0-4531  *       275432  216423  *       *
4E0F    3-1601  C94D    2-212D  *       *       216424  216424  317:164 *
4E10    0-5604  A4A2    1-4461  0-4802  *       213029  213029  253:120 *
4E11    0-1983  A4A1    1-4460  0-1715  0-8568  275D30  213028  253:252 *
4E12    *       *       *       1-1605  *       *       *       *       41A8

......

From @UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU Wed Aug  4 08:02:07 1993
Return-Path: <@UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU>
Received: from uga.cc.uga.edu by ifcss.org (4.1/IFCSS-Mailer)
	id AA02370; Wed, 4 Aug 93 08:02:01 CDT
Message-Id: <9308041302.AA02370@ifcss.org>
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 6919; Wed, 04 Aug 93 09:01:13 EDT
Received: from UGA.CC.UGA.EDU (NJE origin LISTSERV@UGA) by UGA.CC.UGA.EDU (LMail V1.1d/1.7f) with BSMTP id 7659; Wed, 4 Aug 1993 09:01:11 -0400
Date:         Wed, 4 Aug 1993 08:44:22 EDT
Reply-To: Martin Heijdra <MHEIJDRA%PUCC.BITNET@uga.cc.uga.edu>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: Martin Heijdra <MHEIJDRA%PUCC.BITNET@uga.cc.uga.edu>
Subject:      Re: Guo Jin's message
Comments: To: ccnet-l@uga.bitnet
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
Status: RO

Guo Jin talked about characters for names being made up. In this context
it is worth noting that in addition to the 74,000 characters the CCIII
group found in character dictionaries (including variants in
Chinese, Japanese and Korean, but I am not sure about unofficial "shorthand"
characters, dialectic characters, or Japanese and Korean unofficial
variants), also some 9,000 (!) characters were found in Taiwan used in
names which were in NO dictionary; in fact, pronunciation could only be
guessed at! They were compiled for the Taiwanese population registration
bureau, which according to CCIII would have no option but declare these
characters "legal". (I don't know the actual result.) This only means
that while the Unicode is certainly sufficient (hey, how many of you come
across characters not in Kangxi Zidian or newer medium-sized dictionaries?
I know, it happens, but very rarely)
for encoding and even more-than-normal use, ANY word processing system
ALWAYS should give the option for creating private characters, since NO
system will ever be able to encompass them all: characters can be created.
And what with Chinese characters used privately for all those southern
Tai-related languages, as well as Chu Nom etc.?

Martin Heijdra.

From @UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU Tue Aug 10 09:52:51 1993
Return-Path: <@UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU>
Received: from uga.cc.uga.edu by ifcss.org (4.1/IFCSS-Mailer)
	id AA20659; Tue, 10 Aug 93 09:52:36 CDT
Message-Id: <9308101452.AA20659@ifcss.org>
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 0892; Tue, 10 Aug 93 10:51:21 EDT
Received: from UGA.CC.UGA.EDU (NJE origin LISTSERV@UGA) by UGA.CC.UGA.EDU (LMail V1.1d/1.7f) with BSMTP id 6123; Tue, 10 Aug 1993 10:51:19 -0400
Date:         Tue, 10 Aug 1993 15:51:00 BST
Reply-To: Ross Paterson <rap@DOC.IC.AC.UK>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: Ross Paterson <rap@DOC.IC.AC.UK>
Subject:      Han unification in Unicode/ISO-10646
Comments: To: ccnet-l@uga.cc.uga.edu
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
Status: R

Some people have recently been complaining that the above-mentioned
Han unification doesn't go far enough.  I also would have liked it to
go further, but we have to remember that the UniHan range is not just
for Chinese, but also Korean and Japanese (as well as for Vietnamese
Chu Nom).  The primary objective of unification was to cover these
writing systems without blowing out the 16-bit coding space.  It was not
to undo 1200 years of divergence, or even the modern simplifications.
(I'm not connected with either organization; I just scan the relevant
mailing lists.)

Unification of 4 writing systems is not trivial, maybe even impossible.
If you impose a Chinese idea of what characters are identical, you'll mess
things up for the Koreans and Japanese (and if you do that, you've lost
the 16-bit code).  So they went for a less ambitious approach, "they"
being the CJK Joint Research Group of ISO, composed of representatives
of the various governments and of Unicode.  My impression is that the
Unicoders were keener on unification than the various national bodies.

The first principle was the "source separation rule": distinct codepoints
in any reference standard are mapped to distinct codepoints in the
new set.  The reference standards here are GB 2312-80, CNS 11643-1986
(levels 1 and 2: approximately BIG-5), JIS X0208-1990 and X0212-1990
and KSC 5601-1987.  The importance of this is that if you translate text
encoded in a national character set into Unicode and back again, you get
the same text you started with.  This already means, for example, that
the simplified and traditional forms of guo2 (country) need separate
codes, as they are separately encoded in JIS X0208-1990.

The next principle is quoted (via the ISO10646 mailing list) from the
"Explanatory notes for the Unified Ideographic CJK Characters Repertoire
and Ordering [URO], V.1.0," dated November 29, 1991:

   "In this model, three atributes of a written form of a character
    (named X, Y, and Z) are considered, and we suppose a 3-dimensional
    space with these three attributes as its axes.  The X-axis represents
    classes of characters with their meanings or ideographic characters...

    The Y-axis is for variant forms or abstract shape of one ideographic
    character...

    The Z-axis is for type face differences (the actual shape used in
    printing the form) of each variant form....

    Unification is done on the Y-axis, ignoring X-differences (meanings)
    and Z-differences (type faces)."

That is, meanings and fonts don't count, only abstract shapes.  But for
all this Cartesian rationalism, the distinction between a font difference
and a different shape is somewhat subjective.  The application of
this principle has meant that not only do simplified radicals (with a
few exceptions) make for different characters, but such pairs as the
following get different codepoints (514C and 5151 respectively), even
though no source set distinguishes them:

      ;;'   '''';'                        ';,      ;;'
     ;;         ';,                         ;;,   ;'
   ,;'            ';,,                   ,   '  ,'   ,,
,,'',,,,,,,,,,,,,,, ';;'                 ;;'''''''''';;'
    ;;           ;;                      ;;          ;;
    ;;           ;;                      ;;          ;;
    ;;,,,,,,,,,,,;;                      ;''';;'';;'';'
        ;;  ;;   ''                         ,;'  ;;      ,
       ;;   ;;        ,                     ;;   ;;      ;
     ,;'    ;;        ;                   ,;'    ;;      ;,
   ,;'      ;;,,,,,,,,;;               ,,''      ';;;;;;;;'
'''          ''''''''''              ''

Of course the whole process (and not just the Han unification) was
warped by politics.  The result is not perfect, but it is reasonably
comprehensive and consistent, and no other new standard has much
chance now.  It's not nearly bad enough to justify the effort of another
standard -- we may as well make the best of it.

As for the waste of space, this limited unification has probably cost
about 3000 codepoints in comparison with a full Chinese unification (which
would surely have been unacceptable to the Japanese and Koreans) or about
1300 in comparison with a unification of simplified and traditional forms
of radicals.  There is worse waste elsewhere in Unicode/ISO-10646, but
that's a different story.
--
Ross Paterson <rap@doc.ic.ac.uk>
Department of Computing, Imperial College, London SW7

From @UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU Tue Aug 10 12:02:39 1993
Return-Path: <@UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU>
Received: from uga.cc.uga.edu by ifcss.org (4.1/IFCSS-Mailer)
	id AA22537; Tue, 10 Aug 93 12:02:31 CDT
Message-Id: <9308101702.AA22537@ifcss.org>
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 1950; Tue, 10 Aug 93 13:01:14 EDT
Received: from UGA.CC.UGA.EDU (NJE origin LISTSERV@UGA) by UGA.CC.UGA.EDU (LMail V1.1d/1.7f) with BSMTP id 8953; Tue, 10 Aug 1993 13:01:12 -0400
Date:         Tue, 10 Aug 1993 12:56:47 EST
Reply-To: Wang Jianxiong <UGF00023@VM.UOGUELPH.CA>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: Wang Jianxiong <UGF00023@VM.UOGUELPH.CA>
Subject:      UNICODE IN CHINESE?
Comments: To: CCNETTERS <ccnet-l@uga.bitnet>
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
Status: R

Dear Ross and John:

        Here is the first lines of UNIHAN code in the file CJKXREF.FIX
at unicode.org. This file has a size of 1MB. I have a stupid question:
Is it ever possible for the CJK group or any other people to produce
a same table but together with the character SHAPES in the positions of {}
and an additional one at the position [] ONLY IF IT IS different from the
one at {} ?
        This table  can be produced with TwinBridge for example and stored
in the HP LJ print out format or PS format in pages. People can ftp them
and print them. This will be a wonderful reference of UNIHAN.
        I think this will be great for everyone to discuss the UNIHAN business.
Maybe only CJK group can do this because usual persons have no resources
to produce all of them.
        Another question:how did you divide or extend the GB into
GB-1,2,3,4,5,6,7,8?
        Thanks very much.

Jian-X. Wang

UNIHAN GB      Big-5 CNS     JIS     KSC     ANSI    CCCII1  Xerox   Fujitsu
=============================================================================
4E00{} 0-5027[]A440[]1-4421[]0-1676[]0-7673[]213021[]213021[]241:042[]*
4E01{} 0-2201[]A442[]1-4423[]0-3590[]0-7943[]213022[]213022[]250:132[]*
.........
4E12{} *       *     *       1-1605[]*       *       *       *        41A8[]
4E13{} 0-5508[]*     *       *       *       273B3F[]273B3F[]*        *

From @UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU Tue Aug 10 19:12:19 1993
Return-Path: <@UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU>
Received: from uga.cc.uga.edu by ifcss.org (4.1/IFCSS-Mailer)
	id AA29703; Tue, 10 Aug 93 19:12:01 CDT
Message-Id: <9308110012.AA29703@ifcss.org>
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 4135; Tue, 10 Aug 93 20:10:19 EDT
Received: from UGA.CC.UGA.EDU (NJE origin LISTSERV@UGA) by UGA.CC.UGA.EDU (LMail V1.1d/1.7f) with BSMTP id 3121; Tue, 10 Aug 1993 20:10:18 -0400
Date:         Tue, 10 Aug 1993 20:05:54 EDT
Reply-To: John Delacour <100111.3564@COMPUSERVE.COM>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: John Delacour <100111.3564@COMPUSERVE.COM>
Subject:      UniHan
Comments: To: Wang Jianxiong <CCNET-L@uga.cc.uga.edu>
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
Status: R

*** In Reply to Wang Jianxiong's posting of Tue, 10 Aug 1993 12:56:47 EST ***


Jianxiong,

I don't think your question is at all stupid.  And the answer is that it is
certainly possible to include the characters in the file cjkref.fix as I know,
since I have spent as much time as possible in the past two weeks doing exactly
that.

I have been slowed down by a number of things - first of all the file is very
large and to load it into a spreadsheet with my computer takes more than half
an hour.  The problem then is that some of the hexadecimal numbers (eg. 4E10)
are formatted as exponential numbers instead of text and some of the GB numbers
are translated into date format.  I have written to John Jenkins suggesting
that he put an apostrophe before each number in the table in order to save
people a lot of time in sorting the columns in a spreadsheet/database. (I am
using a Macintosh SE/30, which is usually very fast, and Excel)

Now that I have sorted out most of the problems I have begun to create tables
which include the Chinese characters for Unicode, GB and Big-5.  Other factors
which have slowed down this (basically simple) process are the inconvenience of
having to work with an antiquated Mac/Chinese system while Apple refuse to make
available the new system and the file needs to be transferred from spreadsheet
to wordprocessor to text editor etc. etc. in order to produce a good
end-result.  Nevertheless I have done half the task sufficiently well for my
own purposes and will eventually uuencode it and make it available to anyone
who is interested.  I have just acquired a 14400bps modem which will make the
uploading of big files a lot cheaper than before.

Although I am working with a Mac, the end result will be a text file so there
should be no problem.

Christian Wittern in Kyoto I know has recently produced some tables but I can't
access them with the Mac.  I guess you read his announcement about three weeks
ago, but if not I will find the information when I have a little more time if
you would E-mail me.

            John           (jdelacour@cix.compulink.co.uk)

From @UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU Thu Aug 12 00:20:54 1993
Return-Path: <@UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU>
Received: from uga.cc.uga.edu by ifcss.org (4.1/IFCSS-Mailer)
	id AA16577; Thu, 12 Aug 93 00:20:51 CDT
Message-Id: <9308120520.AA16577@ifcss.org>
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 7981; Thu, 12 Aug 93 01:19:50 EDT
Received: from UGA.CC.UGA.EDU (NJE origin LISTSERV@UGA) by UGA.CC.UGA.EDU (LMail V1.1d/1.7f) with BSMTP id 5178; Thu, 12 Aug 1993 01:19:49 -0400
Date:         Thu, 12 Aug 1993 04:28:38 +0100
Reply-To: jerry@candy.nest.nl
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: Jerry Zorge <jerry@CANDY.NEST.NL>
Organization: Clip
Subject:      UNICODE-reference
Comments: To: CCNET-L@uga.cc.uga.edu
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
Status: R

Urs Widmer <a06g@ZFN.UNI-BREMEN.DE> wrote:

> quite a few people seem engaged in producing a UNICODE-reference
> table with CJK-characters. Before you spend too much time in such
> a project remember that "The Unicode Standard, Vol. 2" (US$ 29.95)
> is just such a table with GB, BIG-5, JIS, KIS and some other codes
> as well as the UNICODE-code together with the character shape.

> Besides this book contains a radical/stroke index which allows
> to look up simplified and traditional characters very handy.

Some supplemental info:
1. The book is published by Addison-Wesley, ISBN 0-201-60845-6
2. "Machine readable mapping tables from the Unicode standard to the
major Asian standards are available from Unicode, Inc. (3.5" diskettes,
PC format only)."

Costs: ? Or are they also available somewhere on the net?

Unicode, Inc.
1965 E. Charleston Road
Mountain View, CA 94043
415-961-4189
---
---
| Jerry Zorge            email: jerry@candy.nest.nl |
| Haarlemmerplein 25/2   voice: +31-20-6391020      |
| 1013 HP Amsterdam, NL                             |

From @UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU Thu Oct 21 20:13:54 1993
Return-Path: <@UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU>
Received: from uga.cc.uga.edu by ifcss.org (4.1/IFCSS-Mailer)
	id AA07367; Thu, 21 Oct 93 20:13:51 CDT
Message-Id: <9310220113.AA07367@ifcss.org>
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 3569; Thu, 21 Oct 93 21:12:52 EDT
Received: from UGA.CC.UGA.EDU (NJE origin LISTSERV@UGA) by UGA.CC.UGA.EDU (LMail V1.1d/1.7f) with BSMTP id 2846; Thu, 21 Oct 1993 21:12:50 -0400
Date:         Thu, 21 Oct 1993 20:11:45 -0500
Reply-To: Peter V Henstock <henstock@ECN.PURDUE.EDU>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: Peter V Henstock <henstock@ECN.PURDUE.EDU>
Subject:      Unicode stroke, radical mappings
Comments: To: CCNET-L@UGA.CC.UGA.EDU
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
Status: R

In the Unicode Standard Vol II, there is a table of the radical
and stroke numbers for all the unicode characters which is over
fifty pages long.  I have looked at the unicode.org site, but
have not been able to find an electronic version of this table.
Does anyone know if and where such a table exists for the
Unicode standard?

Thanks in advance,

--Peter Henstock

henstock@ecn.purdue.edu

From @UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU Sun Dec 12 10:50:20 1993
Return-Path: <@UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU>
Received: from uga.cc.uga.edu by ifcss.org (4.1/IFCSS-Mailer)
	id AA20483; Sun, 12 Dec 93 10:50:06 CST
Message-Id: <9312121650.AA20483@ifcss.org>
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 3982; Sun, 12 Dec 93 11:47:53 EST
Received: from UGA.CC.UGA.EDU (NJE origin LISTSERV@UGA) by UGA.CC.UGA.EDU (LMail V1.1d/1.7f) with BSMTP id 4189; Sun, 12 Dec 1993 11:47:52 -0500
Date:         Sun, 12 Dec 1993 11:09:36 -0500
Reply-To: susan lasovick <lasovick@WORLD.STD.COM>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: susan lasovick <lasovick@WORLD.STD.COM>
Subject:      Re: Unicode Info
Comments: To: Doug Schiffer <Doug.Schiffer@F513.N260.Z1.FIDONET.ORG>
Comments: cc: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
In-Reply-To:  <199312121102.AA06299@world.std.com>
Status: R

As an individual member of the Unicode Consortium, I have a printed copy
of the prepubliclation edition of "Unicode 1.1".  Hoever, I believe that
you can find what you need at the ftp site: unicode.org, in
/pub/MappingTables- which includes the 1.1 Tables- You will probably find
ohter pertinent information in the additional subdirectories.  According
to the 1.1 technical report, Only the private use area is affected by
zone reallocations.

Unicode 1.1 also includes a set of precomposed Hangul 'syllable blocks'
and set of conjoining Korean jamos, to allow encoding of modern and
ancient syllable blocks."

The  encoding ranges for the conjoing jamos:

U+1100 - U+1159
U+115F
U+1160
U+1161 - U+11a2
U+11A8 - U+11FA

For more information I recommend joining the Unicode Consortium,

1965 Charleston Road
Mountain View, California 94043

tel: 415-961-4189
fax: 415-966-1637
email: unicode-inc@uncode.org




On Sun, 12

Best Regards,
Susan lasovick
lasovick@world.std.com

> Hello! I have a few questions about Unicode unified han characters,
> and I was wondering if anyone has any of the following information:
>
> 1) Is there a list cross referencing Unicode codepoints to the
> Chinese telegraph code? [Dian Biao Ma]
>
> 2) My Unicode Standard books say the ver 1.1 of the standard will
> include new characters for the unification with ISO 10646.  Have the
> new characters been decided, as well as their placement in the han area?
> Will the old (ver 1.0) characters be rearranged to accomodate them?
>
> 3) Are there any font sets out there for any of the extended
> GuoBiao sets:
>
>       GB1 = GB12345-90
>       GB3 = GB7589-87
>       GB5 = GB7590-87
>
> I'm also curious where I could get my hands on the formal standards
> documents for these character sets.  I found one at the Library of Congress
> for the GB0 = GB2312-80 set.
>
> If I could find the standards documents, I might scan them in and
> MAKE a 24x24 or outline font for these sets...
>
> Thanks!
>

From @UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU Tue Dec 14 09:23:49 1993
Return-Path: <@UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU>
Received: from uga.cc.uga.edu by ifcss.org (4.1/IFCSS-Mailer)
	id AA27474; Tue, 14 Dec 93 09:23:29 CST
Message-Id: <9312141523.AA27474@ifcss.org>
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 4651; Tue, 14 Dec 93 10:20:20 EST
Received: from UGA.CC.UGA.EDU (NJE origin LISTSERV@UGA) by UGA.CC.UGA.EDU (LMail V1.1d/1.7f) with BSMTP id 4701; Tue, 14 Dec 1993 10:20:18 -0500
Date:         Tue, 14 Dec 1993 09:59:12 -0500
Reply-To: susan lasovick <lasovick@WORLD.STD.COM>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: susan lasovick <lasovick@WORLD.STD.COM>
Subject:      Re: Unicode Info
Comments: To: Ross Paterson <rap@DOC.IC.AC.UK>
Comments: cc: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
In-Reply-To:  <199312141137.AA23993@world.std.com>
Status: R

The Unicode Technical Report #4, the prepublication Edition of the
'Unicode Standard 1.1' does  list some of the incorrectly printed glyphs
of "unicode 1.0:

(refers  to 'Unicode 1.0, Vol.2)

Figs 2-14 and 2-15 (correct glyphs printed in Tech report #4)

Character in the following code positions:

U+71F7  (pgs. 60, 131, 264)
U+773E  (pgs. 66, 135, 277)
U+809C  (pgs. 75,140,301)
U+8480  (pgs. 79, 143, 311)
U+908E  (pgs. 91, 150, 343)

The report also indicates that there are additional minor glyph errors,
but does not specify them.  I just received the first edition of a new
quartlerly Unicode newsletter 'Encoding,' which says you can order
Technical Report #4 for $8.00, which includes  new mapping tables.  For
further information I suggest you contact Unicode:

email: unicode-inc.@unicode.org
tel: 415-961-4189

Susan Lasovick
lasovick@world.std.com

On Tue, 14 Dec 1993, Ross Paterson wrote:

> Doug Schiffer <Doug.Schiffer@F513.N260.Z1.FIDONET.ORG> writes:
> > 1) Is there a list cross referencing Unicode codepoints to the
> > Chinese telegraph code? [Dian Biao Ma]
>
> There is a (partial) GB/DBM cross-reference:
>
>         ifcss.org /software/data/telecode.gb
>
> which can be joined with the Unicode mapping tables.  Also, John Jenkins
> <John_Jenkins@taligent.com> has tables relating Unicode and both Mainland
> and Taiwan telegraph codes.
>
> > 2) My Unicode Standard books say the ver 1.1 of the standard will
> > include new characters for the unification with ISO 10646.  Have the
> > new characters been decided, as well as their placement in the han area?
> > Will the old (ver 1.0) characters be rearranged to accomodate them?
>
> Hanzi are unaffected by the upgrade to 1.1, most of which is concerned
> with adding more redundant stuff to effect the merger with ISO 10646.
> However, according to the 1.0.1 Addendum at the Unicode site, 5 hanzi
> are misprinted in the Unicode books.  (The Addendum doesn't contain the
> glyphs, but it says how to get a hardcopy.)  A new edition of the Unicode
> books (covering 1.1) is expected from Addison Wesley "in the first half
> of 1994".
>

From @UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU Sat Feb 19 21:36:51 1994
Return-Path: <@UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU>
Received: from uga.cc.uga.edu by ifcss.org (4.1/IFCSS-Mailer)
	id AB29408; Sat, 19 Feb 94 21:36:48 CST
Message-Id: <9402200336.AB29408@ifcss.org>
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 1524; Sat, 19 Feb 94 22:33:18 EST
Received: from UGA.CC.UGA.EDU (NJE origin LISTSERV@UGA) by UGA.CC.UGA.EDU (LMail V1.1d/1.7f) with BSMTP id 4191; Sat, 19 Feb 1994 22:33:16 -0500
Date:         Sat, 19 Feb 1994 22:31:56 -0500
Reply-To: simpson@math.psu.edu
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: Stephen G Simpson <simpson@MATH.PSU.EDU>
Subject:      Unicode E-mail address
Comments: To: Doug Schiffer <Doug.Schiffer@F513.N260.Z1.FIDONET.ORG>
Comments: cc: ccnet-l@uga.cc.uga.edu
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
In-Reply-To:  <199402200037.TAA02187@leibniz.math.psu.edu>
Status: RO

 > Does anyone know the E-mail addresses of the people at the Unicode
 > Consortium that are responsible for the hanzi portion of the standard?

A guy at Taligent is listed as the author of the Unicode cross
reference table cjkxref.fix, which gives the mappings of GB, Big5,
etc into Unicode.

#   Name:               The Unicode Han Character Cross-Reference
#   Unicode version:    1.0.1
#   Table version:      0.0d1
#   Table format:       Format A
#   Date:               24 December 1992
#   Author:             John H. Jenkins (John_Jenkins@taligent.com)

From @UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU Tue Apr 26 06:56:47 1994
Return-Path: <@UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU>
Received: from uga.cc.uga.edu by ifcss.org (4.1/IFCSS-Mailer)
	id AA19615; Tue, 26 Apr 94 06:56:45 CDT
Message-Id: <9404261156.AA19615@ifcss.org>
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 0806; Tue, 26 Apr 94 07:54:35 EDT
Received: from UGA.CC.UGA.EDU (NJE origin LISTSERV@UGA) by UGA.CC.UGA.EDU (LMail V1.1d/1.7f) with BSMTP id 9340; Tue, 26 Apr 1994 07:54:33 -0400
Date:         Tue, 26 Apr 1994 12:53:00 BST
Reply-To: Ross Paterson <rap@DOC.IC.AC.UK>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: Ross Paterson <rap@DOC.IC.AC.UK>
Subject:      Re: Unicode
Comments: To: ccnet-l@uga.cc.uga.edu
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
Status: R

Stephen G Simpson <simpson@MATH.PSU.EDU> hits the nail on the head:
> The question is, how can internationalized software provide
> mixed-language capability?  Unicode and ISO-2022 are two good answers
> to that question, which GB and Big5 don't address at all.

And the next question is, which of these should we prefer?  I used to be
sure it was Unicode, and still have an instinctive bias that way, but it's
difficult to nominate definite reasons.

For a bit of background, let me describe the Unicode-based environment
I'm using to type this message (I'm only using the ASCII subset, of
course, since anything more wouldn't be readable in most places).
I use an X Windows port of some programs from the Plan 9 experimental
Unix system; see

        ftp://research.att.com/dist/plan9man/09utf.ps.Z

for a fuller description.  Unicode, or the Basic Multilingual Plane
of ISO-10646 with which it has been unified, gives you a single 16-bit
character set that covers just about any language you could wish to write.
For compatability with existing ASCII-based software, in Plan 9 the
non-ASCII characters are externally represented using 2 or 3 bytes with
the high bit set, but this is invisible: they are just characters as
far as the interface is concerned.

In Plan 9, a Unicode font is built out of subfonts (= X fonts in the
X version) covering subranges of the characters.  That way, a subrange
that is not heavily used at some installation may have a single subfont
shared by many fonts, while more locally important subranges may have
a variety of subfonts.

With everything set up that way, one can edit text, name files, etc just
as with ASCII, but with many more characters available.  The system is
rather sparse, however, with poor support in many areas (in particular
input).  There is no inherent reason for this; it's just a matter of
investing time -- think of it as a prototype.

Now for mail and news, I can imagine programs that
(a) take my outgoing messages and recode them as MIME messages with
    charset US-ASCII, ISO-8859-1 or UNICODE-1-1-UTF-7 as appropriate
    (the former two are simple subsets of Unicode),
(b) convert incoming MIME messages in various charsets to my local
    encoding before I see them, since all of those sets are subsets
    of Unicode.
so that the outside world will appear in Unicode.

Now much the same kind of environment could be achieved using ISO-2022
-- take Mule and Mosaic-l10n as prototypes.  For internal processing,
one could use a 32-bit code combining an identifier of a character
set (ASCII, GB, JIS etc) with a code point in that character set.
Incidentally, that's approximately what was initially proposed for ISO
10646 before Unicode derailed it.

John Delacour <JD@EREMITA.DEMON.CO.UK> writes:
> It is quite absurd to suggest that GB and Big5 should coexist with two
> identical characters having different addresses in thousands of cases.

(This is what will happen in an ISO-2022 encoding, with Big5 replaced
by CNS.)  I would instinctively agree, but it's hard to point at definite
advantages, except that 16 bits is smaller than 32.  Clearly unification
of the various ISO Latin sets is a good thing -- one can write German
with either Latin-1 or Latin-2 (depending on which end of Europe
you're in) and the same text would have different ISO-2022 encodings.
Similarly having lots of different versions of Latin, Greek, Cyrillic
and kana would be a nuisance.

With hanzi, it's not so clear.  Han unification gives some of these
advantages: one can search for the pair of characters U+5317 U+4EAC
("Bei3jing1") and find references to the city in mainland, Taiwanese,
Korean and Japanese documents.  But the unification reflects a compromise
-- many simplified characters have distinct code points, as do some
national variants -- so that this won't always work, and you'll need a
character-synonym table (a bit like searching for color/colour in English
documents).  That's a great pity, but I think this state of affairs is
unavoidable: it's not possible to cover all the languages adequately and
provide the differing unifications required by different groups of users.
Still, maybe some unification is better than none.

From @UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU Sat Jul 16 18:30:38 1994
Return-Path: <@UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU>
Received: from uga.cc.uga.edu by ifcss.org (4.1/IFCSS-Mailer)
	id AA00637; Sat, 16 Jul 94 18:30:36 CDT
Message-Id: <9407162330.AA00637@ifcss.org>
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 7123; Sat, 16 Jul 94 19:29:23 EDT
Received: from UGA.CC.UGA.EDU (NJE origin LISTSERV@UGA) by UGA.CC.UGA.EDU (LMail V1.1d/1.7f) with BSMTP id 1575; Sat, 16 Jul 1994 19:29:22 -0400
Date:         Sun, 17 Jul 1994 00:12:54 +0100
Reply-To: John Delacour <JD@EREMITA.DEMON.CO.UK>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: John Delacour <JD@EREMITA.DEMON.CO.UK>
Subject:      Unicode (forwarded info)
Comments: To: CCNET-L@uga.cc.uga.edu
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
Status: R

Asmus Freytag
Vice President Marketing
The Unicode Consortium

    The Unicode(R) Consortium is pleased to announce the availability
    of an implementers tutorial "Introduction to Unicode(tm)" created for
     the Consortium by  the Institute for Advanced Professional Studies.

    This Tutorial has been presented at several recent Unicode
    Implementers Workshops, by its author, Glenn Adams of Metis
    Technology, and is now available separately in print for the first time.

    "Introduction to Unicode" presents an in-depth discussion of the
    architectural features of the Unicode Standard and how they
    relate to the writing systems in use throughout the world.

    The Tutorial starts with a survey of the requirements of different
    scripts and writing systems, continuing with a discussion of
    what character codes represent. The terms Text Element and
    Code Element are introduced and examined. A detailed look
    at individual architectural features of the Unicode Standard
    follows, including the display, processing and interchange model
    underlying the design of the Standard.

    The Tutorial concludes with a focus on implementation issues for
    bi-directional text and Indic Script processing. Helpful appendices
    include a glossary and an extensive bibliography.

    Spiral bound, 207 pages. Price: $40.00 plus shipping and handling.
    Please contact unicode-inc@unicode.org to order.

From owner-ccnet-l@UGA.CC.UGA.EDU Thu Aug 17 12:48:41 1995
Received: from jolt.eng.umd.edu (jolt.eng.umd.edu [129.2.102.5]) by bacchus.eng.umd.edu (8.7.Beta.12/8.6.4) with SMTP id MAA04873 for <yjj@bacchus.eng.umd.edu>; Thu, 17 Aug 1995 12:48:39 -0400 (EDT)
Received: from uga.cc.uga.edu (uga.cc.uga.edu [128.192.1.5]) by jolt.eng.umd.edu (8.6.10/8.6.4) with SMTP id MAA02869 for <yjj@GLUE.UMD.EDU>; Thu, 17 Aug 1995 12:47:52 -0400
X-UIDL: 808679171.012
Message-Id: <199508171647.MAA02869@jolt.eng.umd.edu>
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 4331; Thu, 17 Aug 95 12:45:32 EDT
Received: from UGA.CC.UGA.EDU (NJE origin LISTSERV@UGA) by UGA.CC.UGA.EDU (LMail V1.2a/1.8a) with BSMTP id 4904; Thu, 17 Aug 1995 12:45:29 -0400
Date:         Thu, 17 Aug 1995 09:44:56 PDT
Reply-To: Jimmy Han <jhan@FX.COM>
Sender: Chinese Computing Network <CCNET-L@UGA.CC.UGA.EDU>
From: Jimmy Han <jhan@FX.COM>
Subject:      Re: Encoding systems
Comments: To: eric@XPEDITE.COM
To: Multiple recipients of list CCNET-L <CCNET-L@UGA.CC.UGA.EDU>
Status: R

Unlike NT, Window 95 uses local character set internally. Its encoding
system is same as Window 3.1. But you can develop your Unicode applications
on Window 95 by using Microsoft's library functions, which do conversions
between Unicode and your local character set.

-Jimmy Han (jimmy.han@fx.com)
>
> Does anyone know that what kind of encoding system was used in Windows 95?
> I understand that the Unicode was used in Windows NT.
>


