From CCNET-L@uga.cc.uga.edu Fri Oct  4 11:59:53 1991
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.61/5.10) with SMTP id AA03348; Fri, 4 Oct 91 11:59:38 -0400
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 7592; Fri, 04 Oct 91 11:58:17 EDT
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 4115;
 Fri, 04 Oct 91 11:58:15 EDT
Date:         Fri, 4 Oct 1991 16:57:51 MET
Reply-To: Valk v/d M <mvdvalk%CS.VU.NL@uga.cc.uga.edu>
Sender: Chinese Computing Network <CCNET-L%UGA.BITNET@uga.cc.uga.edu>
From: Valk v/d M <mvdvalk%CS.VU.NL@uga.cc.uga.edu>
Subject:      [Ned Walsh:  Re: coding standards]
Comments: To: CCNET-L@uga.cc.uga.edu
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
Status: RO


In his original message Martijn van der Valk <mvdvalk@cs.vu.nl> wrote:

> GB
> BIG5
> Unicode
> JIS 1st and 2nd level
>
> What I'd like to know is: what order is used to assign codes to characters.

While several people have replied explaining what the codes are,
nobody has said what order is used in each.  I'll give it a stab, and
hope others will correct my mistakes.  I'm lifting most of this info
from J. and T. Huang's "An Introduction to Chinese, Japanese and
Korean Computing" (World Scientific, 1989; a kind of flaky book, I
know, but it's what I've got :).

The Japanese Industrial Standard includes 6,353 characters, divided
into two levels:  (1) 2,965 in the first level, arranged by a "repre-
sentative on-kun reading," which appears to be a somewhat arbitrary
selection and pairing of a character's assorted on and kun readings (I
assume they chose the most common readings).  (2) 3,388 characters,
arranged by radical, then stroke count, then representative on
reading.  Parent characters precede variants.  This code also includes
147 special characters (space, parentheses, scientific symbols, etc.);
the numerals 0-9; the 52 letters of the Roman alphabet; 83 hiragana;
86 katakana; 48 Greek letters; 66 Russian letters; and 32 "ruled line
elements" (assorted symbols for drawing lines).  I'm not certain, but
I think all except the ruled line elements precede the characters in
the order I've listed; the ruled line elements come last in the code.
I could easily be mistaken.

The Guo Biao code includes 6,763 simplified characters, also divded
into two levels:  (1) 3,755 more frequently used characters, arranged
in order by pinyin (I don't know how they decided among multiple
readings); (2) 3,008 arranged by the PRC's radical system, then
presumably by stroke count.  I don't know what order is used for
characters with the same pronunciation, or the same
radical/stroke-count.  The code also includes 202 general characters
(space, punctuation marks, etc.); 60 serial numbers (e.g. 1-20 with
periods after them, 1-20 in circles, etc.); the Roman alphabet;
Japanese kana; the Cyrillic alphabet; pinyin symbols with tone marks;
and the bopomofo syllabary.  I'm not sure where they all fit in.

The Big 5 code (essentially developed and promoted by the ROC
government) includes 13,051 traditional characters divded into two
sets:  (1) 5,401 most frequently used characters and (2) 7,650 next
frequently used characters, both arranged in order by stroke count
then by radical.  Again, I'm not sure how they ordered characters with
the same stroke/radical index, but it seems to follow the order they
appear in the Zhongwen da zidian.  It includes all the extras that
come with Guo Biao, except for pinyin with tone marks.

I suppose having most frequently used characters appear first in these
codes speeds up character searches.  But the ordering of characters
used in all three codes is absolutely useless when it comes to sorting
a list of characters.  For one thing, all divide the character set in
two, so that characters seem to appear in a set order until halfway
through a list when the ordering seems to start afresh.  JIS and Guo
Biao even change ordering systems on you in the second set.  Their
reliance on phonetic readings to order the most frequently used set of
charcters isn't terribly helpful, since so many characters have
multiple readings.  Big 5's use of a stroke/radical index seems pretty
ass-backwards to me; most people can tell a character's radical at a
glance, then estimate the remaining stroke count fairly accurately;
going the other way around leaves most people counting from the
outset.

Has anyone come up with a weighted table for sorting JIS/Big5/GuoBiao
characters by radical/stroke count?

Maybe Unicode or one of the other new international coding standards
being debated will solve all this.  Mr. Feng would know, but he's off
fermenting in China.:)

/Ned

----- End of forwarded messages

From CCNET-L@uga.cc.uga.edu Wed Sep 18 20:09:50 1991
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.61/5.10) with SMTP id AA28250; Wed, 18 Sep 91 20:09:39 -0400
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 3947; Wed, 18 Sep 91 20:08:59 EDT
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 1996;
 Wed, 18 Sep 91 20:08:53 EDT
Date:         Wed, 18 Sep 1991 20:07:51 TZONE
Reply-To: xiangjun%MICROSOFT.COM@uga.cc.uga.edu
Sender: Chinese Computing Network <CCNET-L%UGA.BITNET@uga.cc.uga.edu>
From: xiangjun%MICROSOFT.COM@uga.cc.uga.edu
Subject:      Pinyin input table for big-5
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
Status: RO

The tables that are valiable for ftp are mostly for GB and HKU-big5.
And it says that HKU-big5 and Eten big5 are different.

Can anyone tell what the difference is?  And has anyone got
a Pinyin table for Eten big5 for ftp?

-xiangjun

From CCNET-L@uga.cc.uga.edu Wed Sep 18 20:25:39 1991
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.61/5.10) with SMTP id AA28374; Wed, 18 Sep 91 20:25:23 -0400
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 4012; Wed, 18 Sep 91 20:24:30 EDT
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 2550;
 Wed, 18 Sep 91 20:24:25 EDT
Date:         Wed, 18 Sep 1991 20:20:11 -0400
Reply-To: Stephen G Simpson <simpson%MATH.PSU.EDU@uga.cc.uga.edu>
Sender: Chinese Computing Network <CCNET-L%UGA.BITNET@uga.cc.uga.edu>
From: Stephen G Simpson <simpson%MATH.PSU.EDU@uga.cc.uga.edu>
Subject:      Pinyin input table for big-5
Comments: To: xiangjun@MICROSOFT.COM
Comments: cc: ccnet-l@uga.cc.uga.edu
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
In-Reply-To:  <9109190009.AA08157@leibniz.math.psu.edu>
Status: RO

> The tables that are valiable for ftp are mostly for GB and HKU-big5.
> And it says that HKU-big5 and Eten big5 are different.
> Can anyone tell what the difference is?  And has anyone got
> a Pinyin table for Eten big5 for ftp?

I constructed such a table from the ETEN phonetic input table.  My
table is available for ftp as
ftp.math.psu.edu:/pub/simpson/chinese/py2big.tab.

Yonguang Zhang used my table to construct an input method for cxterm.
It is available in cs.purdue.edu:/pub/ygz.  He also wrote a utility to
convert between HKU BIG-5 and ET BIG-5, the difference is explained in
the documentation.  Mark Leisher tells me that ET BIG-5 is the same as
CNS-11643, a Taiwan government approved standard.  So far as I know,
HKU BIG-5 is not an accepted standard.

From CCNET-L@uga.cc.uga.edu Thu Sep 19 07:44:15 1991
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.61/5.10) with SMTP id AA01679; Thu, 19 Sep 91 07:44:07 -0400
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 6477; Thu, 19 Sep 91 07:43:42 EDT
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 6907;
 Thu, 19 Sep 91 07:43:40 EDT
Date:         Thu, 19 Sep 1991 07:43:18 TZONE
Reply-To: Lee Sun Pin <walt!omcp.omron!sunpin%UUNET.UU.NET@uga.cc.uga.edu>
Sender: Chinese Computing Network <CCNET-L%UGA.BITNET@uga.cc.uga.edu>
From: Lee Sun Pin <walt!omcp.omron!sunpin%UUNET.UU.NET@uga.cc.uga.edu>
Comments: To: ccnet-l@uga.cc.uga.edu.uunet
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
Status: RO

Can someone tell me what are the differences between the different types of
BIG-5 (for example, HKU BIG-5 and ET BIG-5)?  Also, what is the relationship
between BIG-5 and CNS?

Are there any recommended books on the internal code of Chinese characters used
in Taiwan?

Thank You.


Lee Sun Pin

From CCNET-L@uga.cc.uga.edu Fri Sep 20 05:59:51 1991
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.61/5.10) with SMTP id AA10226; Fri, 20 Sep 91 05:59:42 -0400
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 3416; Fri, 20 Sep 91 05:59:47 EDT
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 2850;
 Fri, 20 Sep 91 05:59:45 EDT
Date:         Fri, 20 Sep 1991 05:59:27 TZONE
Reply-To: Valk v/d Martijn <mvdvalk%CS.VU.NL@uga.cc.uga.edu>
Sender: Chinese Computing Network <CCNET-L%UGA.BITNET@uga.cc.uga.edu>
From: Valk v/d Martijn <mvdvalk%CS.VU.NL@uga.cc.uga.edu>
Subject:      coding standards
Comments: To: ccnet-l@uga.cc.uga.edu
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
Status: RO

Hello everybody!

I'm currently working on a pattern recognition system which should recognize
handwritten Chinese. One of the issues I have to resolve is which coding
standard to choose to code the result.

Could some kind soul please tell me more about the following standards:

GB
BIG5
Unicode
JIS 1st and 2nd level

What I'd like to know is: what order is used to assign codes to characters.

Maybe this question has been answered many times before or is considered out of
place here but I've never posted anything on ccnet before, so I am terribly
sorry if this is the case.

Thanks in advance,

Martijn van der Valk
Vrije Universiteit Amsterdam
The Netherlands

<mvdvalk@cs.vu.nl>

From CCNET-L@uga.cc.uga.edu Fri Sep 20 06:34:19 1991
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.61/5.10) with SMTP id AA10423; Fri, 20 Sep 91 06:34:13 -0400
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 3465; Fri, 20 Sep 91 06:33:50 EDT
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 3171;
 Fri, 20 Sep 91 06:33:49 EDT
Date:         Fri, 20 Sep 1991 03:24:56 PDT
Reply-To: terryk%MICROSOFT.COM@uga.cc.uga.edu
Sender: Chinese Computing Network <CCNET-L%UGA.BITNET@uga.cc.uga.edu>
From: terryk%MICROSOFT.COM@uga.cc.uga.edu
Subject:      Unicode book
Comments: To: ccnet-l@uga.cc.uga.edu
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
Status: RO

This is a forwarded message.
----------------------------

I have been asked where one can get copies of the Unicode book, that is
now available in a pre-publication edition.

The Unicode 1.0 book is currently under production at Addison Wesley, and
is expected to be available in bookstores by mid-October 1991.  Those
interested in the pre-publication versions should write Unicode Inc., 1965
Charleston Road, Mountain View, CA 94043.

The price is $75.00, and includes a diskette of mapping tables.
The price of the A/W book will be $32.95

A brochure and informational material < 50p are also available from
Unicode, Inc.  This material might be useful for ISVs, OEMs and other
interested 3rd parties to get them started.

Unicode Inc's FAX number is (415)-966-1637.

Please forward this mail to other interested parties.

A.

From CCNET-L@uga.cc.uga.edu Fri Sep 20 11:01:07 1991
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.61/5.10) with SMTP id AA11563; Fri, 20 Sep 91 11:00:46 -0400
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 4765; Fri, 20 Sep 91 10:59:55 EDT
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 4030;
 Fri, 20 Sep 91 10:57:11 EDT
Date:         Fri, 20 Sep 1991 10:53:58 -0400
Reply-To: Stephen G Simpson <simpson%MATH.PSU.EDU@uga.cc.uga.edu>
Sender: Chinese Computing Network <CCNET-L%UGA.BITNET@uga.cc.uga.edu>
From: Stephen G Simpson <simpson%MATH.PSU.EDU@uga.cc.uga.edu>
Subject:      coding standards
Comments: To: Valk v/d Martijn <mvdvalk%CS.VU.NL@uga.cc.uga.edu>
Comments: cc: ccnet-l@uga.cc.uga.edu
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
In-Reply-To:  <9109201000.AA12718@leibniz.math.psu.edu>
Status: RO

Valk v/d Martijn writes:

 > I'm currently working on a pattern recognition system which should recognize
 > handwritten Chinese. One of the issues I have to resolve is which coding
 > standard to choose to code the result.
 >
 > Could some kind soul please tell me more about the following standards:
 >
 > GB
 > BIG5
 > Unicode
 > JIS 1st and 2nd level

GB is the official standard in mainland China, and an unofficial
standard in places where simplified Chinese characters are used, such
as Singapore and among mainland Chinese resident abroad.  Don't use it
unless your system is geared exclusively toward simplified characters.
GB does not distinguish between traditional characters that correspond
to the same simplified character (such as mian4 ("face") and mian4
("noodle, wheat")).

BIG5 is the official standard in Taiwan and an unofficial standard in
other places where traditional characters are used, e.g. Hong Kong.
It has codes for almost twice as many characters as GB.

JIS is the official standard in Japan for Japanese.  Although it
includes Japanese kanji, I believe it excludes even some commonly used
Chinese characters.

Unicode is a proposed international standard that many people are
hoping will succeed.  It incorporates codes for simplified Chinese
characters, traditional Chinese characters, Japanese, Korean, and
virtually all alphabets used anywhere in the world.  But the code
order is not necessarily related to GB, BIG5, or JIS.

Maybe "Mr Fung", a Unicode expert, could give you more details.  Try
sending your question to the zhongwen discussion group,
zhongwen@nada.kth.se, moderated by "Mr Fung".

From CCNET-L@uga.cc.uga.edu Thu Sep 26 21:40:34 1991
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.61/5.10) with SMTP id AA03864; Thu, 26 Sep 91 21:40:11 -0400
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 1097; Thu, 26 Sep 91 21:39:36 EDT
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 0320;
 Thu, 26 Sep 91 21:39:35 EDT
Date:         Thu, 26 Sep 1991 21:38:06 -0400
Reply-To: Stephen G Simpson <simpson%MATH.PSU.EDU@uga.cc.uga.edu>
Sender: Chinese Computing Network <CCNET-L%UGA.BITNET@uga.cc.uga.edu>
From: Stephen G Simpson <simpson%MATH.PSU.EDU@uga.cc.uga.edu>
Subject:      Needed: TeX guru
Comments: To: ccnet-l@uga.cc.uga.edu
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
Status: RO

TEX GURU NEEDED !!!

I wonder if any TeX guru out there would volunteer to help with a
special project.  We need a few lines of extremely clever TeX code to
make the Poor Man macros work with BIG-5 coded Chinese characters.
This has come to a head because, as a result of Mark Leisher's
efforts, there is now a way to generate Poor Man BIG-5 traditional
character fonts, similar in quality to the Poor Man GB simplified
character fonts.

A little background.  The Poor Man macros are the creation of Thomas
Ridgeway (rigeway@blackbox.hacc.washington.edu).  Their purpose is to
allow inclusion of GB coded Chinese characters in TeX documents.  They
work very well.  Now we want to modify them to work with BIG-5 codes.
Problems arise because the second byte of a BIG-5 code can be in the
ASCII range.

The logical person to tackle this would be Thomas Ridgeway himself,
but he is very busy, and he has already contributed so much.  So, if
you are a TeXpert and would be willing to donate a few hours, please
let me know and I will send you the details.  But don't even try this
unless you have a thorough knowledge of TeX internals, at the level of
Dirty Tricks (Appendix 4 of The TeXbook).

Stephen G. Simpson               simpson@math.psu.edu
Department of Mathematics        +1 814 863-0775
Pennsylvania State University    home: +1 814 238-2274
University Park, PA 16802

From CCNET-L@uga.cc.uga.edu Sun Oct 20 18:43:22 1991
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.61/5.10) with SMTP id AA08287; Sun, 20 Oct 91 18:43:05 -0400
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 7170; Sun, 20 Oct 91 18:42:32 EDT
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 0880;
 Sun, 20 Oct 91 18:42:31 EDT
Date:         Sun, 20 Oct 1991 18:41:00 -0400
Reply-To: Rupert Zhu <rzhu%WATMATH.WATERLOO.EDU@uga.cc.uga.edu>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: Rupert Zhu <rzhu%WATMATH.WATERLOO.EDU@uga.cc.uga.edu>
Subject:      Follow-up:  Chinese Telegram Code
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
Status: RO

Hi, Friends:

      Thanks to all of you.  After posting the message "Codebook for Chinese
Telegram", I have received about ten replies.  The suggestions are summarized
as follows, (I simply list them here).

(1) The Qu1-Wei4-Ma3 of GuoBiao is identical with telegraph code;

(2) Some version of CCDOS provides "input with telegram code".  So one
    can simply enter the numbers in that mode and see what will be shown
    on the screen;

(3) A software maintained by Ed Lai also has a "input with telegram code" mode
    and may supposedly do the same thing.

(4) Several warm hearted netters in Ottawa, Los Angeles, etc.. offerred
    help to translate the telegram or clue to related information.


      After receiving these messages, I called Liu Jintao and got the
un-decoded telegram.  The contents is:  3018   2399.   I then checked
the Qu1-Wei4-Ma3 of GuoBiao.  The first number corresponds to  Jing4
(quiet), while the second number is not a valid one in GuoBiao table.
This translation does not make sense.

      Meanwhile, Liu Jintao made an overseas telephone call to China
and asked an operator in China to help.  Finally, the operator found
out the two words:   Mu3  Gu4    (Mom passed away).   I am very sorry
to hear this.

      Now the question is still open.  Does anyone has a table (as an
electronic file) to map between GuoBiao code and telegram code ?

      Thank you all !

-- Ruopeng Zhu

From CCNET-L@uga.cc.uga.edu Mon Oct 21 20:09:20 1991
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.61/5.10) with SMTP id AA05467; Mon, 21 Oct 91 20:09:08 -0400
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 4652; Mon, 21 Oct 91 20:08:02 EDT
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 6836;
 Mon, 21 Oct 91 20:08:01 EDT
Date:         Mon, 21 Oct 1991 18:06:22 MDT
Reply-To: mleisher%NMSU.EDU@uga.cc.uga.edu
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: mleisher%NMSU.EDU@uga.cc.uga.edu
Subject:      Re: Chinese Telegram Code Table (uuencoded & zipped)
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
Status: RO

I've made the Chinese Telegram Code Table from Hongbo Ni available for
anonymous ftp in two forms:

crl.nmsu.edu:pub/chinese/telecode.zip  [128.123.1.14]
             pub/chinese/telecode.gb.Z
-----------------------------------------------------------------------------
mleisher@nmsu.edu                      "I laughed.
Mark Leisher                                I cried.
Computing Research Lab                          I fell down.
New Mexico State University                        It changed my life."
Box 3CRL, Las Cruces, NM  88003    - Rich [Cowboy Feng's Space Bar and Grille]

From CCNET-L@uga.cc.uga.edu Sat Oct 26 18:52:18 1991
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.61/5.10) with SMTP id AA22688; Sat, 26 Oct 91 18:52:08 -0400
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 2045; Sat, 26 Oct 91 18:50:31 EDT
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 4905;
 Sat, 26 Oct 91 18:50:30 EDT
Date:         Sat, 26 Oct 1991 18:48:28 -0400
Reply-To: Rupert Zhu <rzhu%WATMATH.WATERLOO.EDU@uga.cc.uga.edu>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: Rupert Zhu <rzhu%WATMATH.WATERLOO.EDU@uga.cc.uga.edu>
Subject:      Forward:  VI Limit, BIG5 Table
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
Status: RO

The following message from Yongguang Zhang is quite informative.
The first part contains information about size limit of VI and CELVIS.
The second part is a shell script to produce BIG5 Table.

Thank you, Yongguang!

-- Rupert Zhu

--------------------- Start of Forwarded Message ----------------------

>From ygz@cs.purdue.edu Sat Oct 26 17:38 EDT 1991
To: Rupert Zhu <rzhu%WATMATH.WATERLOO.EDU@uga.cc.uga.edu>
Subject: Re: Open Question 1: GB Viewer for Large Files on PC
From: ygz@cs.purdue.edu

> d)  What is the size limit for editors on MacIntosh and X-Window systems?
>     (I guess celvis has unlimited capacity because VI does.)

VI also has a limit, as well as celvis.  However, you can change the limit
in compile time.  In celvis, the default block size is 1024 and the maximum
number of block is the block size divided by 2.  The practical maximum file
length is about 400K (theoretically 512K).  By giving a compiler option
-DBLKSIZE=2048 when you compile celvis, you can increase the block size
by the 2, hence increase maximum file length by 4.  You may define BLKSIZE
to be any number from 512 to 2**16, as long as it is the power of 2, but
remember that the larger BLKSIZE is, the faster the temporary file grows.

2. about BIG5 codetable, I wonder what do you mean.  If you want a mapping
of HEX representation of a HZ to the binary representation (2-byte code),
that is quite trivial.  Here is one:  save it and type "sh allb5.sh -l"

------------- BEGIN OF allb5.sh --------------------
#!/bin/sh
#
# List all the HKU BIG5 coding hanzi, one in a line.
# Option "-l" => long listing.
#
l='printf "%c%c\n", q, w;'
s=164
while [ $# -gt 0 ]; do
	case "$1" in
	  -l )
		l='printf "%c%c\t%x%x %d\n", q, w, q, w, q*256+w;'
		shift;;
	  -s )
		s=161			# start from the symbol, 0xa0
		shift;;
	  * )
		echo "Usage: $0 [ -l ] [ -s ]" 1>&2
		exit 1
	esac
done
echo "" | awk '
BEGIN {
	for ( q = '"$s"'; q <= 246; q++ ) {		# 0xa4 -- 0xf6
		for ( w =  64; w <= 126; w++ ) { '"$l"' }	# 0x40 -- 0x7e
		for ( w = 161; w <= 254; w++ ) { '"$l"' }	# 0xa1 -- 0xfe
	}
	q = 247; {				# 0xf7
		for ( w =  64; w <=  85; w++ ) { '"$l"' }	# 0x40 -- 0x55
	}
}'
#------------- END OF allb5.sh --------------------

-ygz

From CCNET-L@uga.cc.uga.edu Mon Oct 28 10:44:33 1991
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.61/5.10) with SMTP id AA12006; Mon, 28 Oct 91 10:44:08 -0500
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 9398; Mon, 28 Oct 91 10:43:55 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 7385;
 Mon, 28 Oct 91 10:38:44 EST
Date:         Mon, 28 Oct 1991 15:21:00 GMT
Reply-To: Wind In His Hair <DANNY%LEVA.ICF.LEEDS.AC.UK%VTVM2.CC.VT.EDU@uga.cc.uga.edu>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: Wind In His Hair <DANNY%LEVA.ICF.LEEDS.AC.UK%VTVM2.CC.VT.EDU@uga.cc.uga.edu>
Subject:      GB BIG5 Unicode
Comments: To: CCNET-L%UGA.BITNET@VM1.NODAK.EDU
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
Status: RO

Dear all,

   Thankyou for all help given in helping me get files back from the
ahkus.org site.  I now understand clearly what my problems were.

   Can anyone give me any information as to where I can obtain the
specifications for GB BIG5 Unicode and any other standards which may
exist in the Chinese computing arena.

   Thankyou

Danny Cox

.____________________________________________.____________________________.
| Danny Cox                                  |    171 Woodhouse Lane      |
| Internet :                                 |    Leeds                   |
|   DANNY%LEVA.LEEDS.AC.UK@NSFNET-RELAY.AC.UK|    LS2 3AR                 |
| Bitnet :                                   |    UK                      |
|   DANNY%LEVA.ICF.LEEDS.AC.UK@UKACRL.BITNET |    0532 334452             |
#____________________________________________+    (010-532) 334452        |
                                             #____________________________#

From CCNET-L@uga.cc.uga.edu Sat Nov  2 15:28:57 1991
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.61/5.10) with SMTP id AA03574; Sat, 2 Nov 91 15:28:46 -0500
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 1628; Sat, 02 Nov 91 15:07:06 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 3716;
 Sat, 02 Nov 91 15:07:04 EST
Date:         Sat, 2 Nov 1991 15:03:12 EST
Reply-To: XiaoFei Wang <xiaofei%ACSU.BUFFALO.EDU@uga.cc.uga.edu>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: XiaoFei Wang <xiaofei%ACSU.BUFFALO.EDU@uga.cc.uga.edu>
Subject:      GB versus KangXi CiDian
Comments: To: ccnet-l@UGA.BITNET, xiaoyu@grumpy.ssc.gov
Comments: cc: horne-scott@cs.yale.edu
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
Status: RO

It has be known that some valid Chinese Characters [_sc._ in KangXi
CiDian ] can not be found in GB. And I don't know a solution of this.

I am worried about this because there is a cooperated project to input
Chinese Literature, for example, DaoDeJing, into computer as discussed
in scc [ Xiaoyu Li will posted on this forum for details ].

Knowlegeable readers please shed light on this.

By the way, I think that simplification of Chinese characters create
more problems than it solves.

From CCNET-L@uga.cc.uga.edu Sat Nov  2 16:24:47 1991
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.61/5.10) with SMTP id AA03783; Sat, 2 Nov 91 16:24:34 -0500
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 1701; Sat, 02 Nov 91 15:41:19 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 4730;
 Sat, 02 Nov 91 15:41:17 EST
Date:         Sat, 2 Nov 1991 15:37:50 EST
Reply-To: Scott Horne <horne-scott%CS.YALE.EDU@uga.cc.uga.edu>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: Scott Horne <horne-scott%CS.YALE.EDU@uga.cc.uga.edu>
Subject:      Re:  GB versus KangXi CiDian
Comments: To: ccnet-l@uga.BITNET, xiaofei@acsu.buffalo.edu,
              xiaoyu@grumpy.ssc.gov
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
Status: RO

There will always be a problem with _hapax legomena_ (characters which occur
only once in all of literature).  You may regard as "valid" every character
in _Kang1 Xi1 zi4dian3_, but what if I go out tomorrow and publish a best-
selling novel which contains a character of my invention?  Will that character
be "valid"?

Obviously no encoding will represent all characters which will ever have been
written.  As a scholar, I need systems which provide rare characters, but
most people can get by with something like GB.  GB was designed for sending
telegrams, and few people quote ancient texts in telegrams.  It certainly
does not meet the arcane needs of scholars, but it wasn't intended to.

In short, you're using the wrong tool.

					--Scott

From CCNET-L@uga.cc.uga.edu Sat Nov  2 17:59:21 1991
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.61/5.10) with SMTP id AA04135; Sat, 2 Nov 91 17:59:07 -0500
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 1980; Sat, 02 Nov 91 17:58:39 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 7071;
 Sat, 02 Nov 91 17:58:38 EST
Date:         Sat, 2 Nov 1991 17:56:13 EST
Reply-To: XiaoFei Wang <xiaofei%ACSU.BUFFALO.EDU@uga.cc.uga.edu>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: XiaoFei Wang <xiaofei%ACSU.BUFFALO.EDU@uga.cc.uga.edu>
Subject:      GB and GangXi ZiDian
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
Status: RO

Scott Horne has expressed his opinion in a scholarly manner.
As a non-scholar, I do not think GB is designed for sending
telegrams.

True that few people cite ancient literature in telegram. But a lot of
people have names which  uses ancient characters. in BYX 1.* Yang
YongXin typed an open letter and he could not find several characters
in GB for people's names. I don't know how the post service handle the
problem if someone's name is not in the GB or telecode if they are not
the same.

I hope to see more scholars express their opinions.

From CCNET-L@uga.cc.uga.edu Sat Nov  2 20:35:09 1991
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.61/5.10) with SMTP id AA04550; Sat, 2 Nov 91 20:35:00 -0500
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 2039; Sat, 02 Nov 91 18:28:39 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 7444;
 Sat, 02 Nov 91 18:28:35 EST
Date:         Sat, 2 Nov 1991 18:30:38 EST
Reply-To: Huangxin Wang <wang%PENNMESS.PHYSICS.UPENN.EDU@uga.cc.uga.edu>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: Huangxin Wang <wang%PENNMESS.PHYSICS.UPENN.EDU@uga.cc.uga.edu>
Subject:      Re:  GB and GangXi ZiDian
Comments: To: xiaofei%ACSU.BUFFALO.EDU@uga.cc.uga.edu
Comments: cc: CCNET-L@uga.cc.uga.edu
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
Status: RO

I think BYX1.* uses a smaller set of character (that the regular GB).
For example, it cannot find the characters of my name (xin), but no
such problem with Mac (containing all the GB characters, about 7000).

But you problem will definitely occur if you start working on this
project.  Since the crucial point is that we start this project first
then iron out this details, what I suggest is whenever you encounter
these difficult characters, use pinyin instead.  This will also help
because very often when we are reading classics, we encounter this
kind of character that we cannot even pronounce.

Just as a long shoot, by using both pinyin and characters, this can make
Chinese getting more and more flexible.  Some of the difficult characters
will slowly phase out replaced by pinyin.  This will be a more pratical
scheme of chinese romanization, than the radical way of total abandon
chinese characters.

In any way, our first goal is to get this project (collecting chinese
classics) rolling first.

Huangxin Wang ~{Muh+vN~}, University of Pennsylvania

From CCNET-L@uga.cc.uga.edu Sat Nov  2 23:18:10 1991
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.61/5.10) with SMTP id AA04988; Sat, 2 Nov 91 23:18:02 -0500
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 2448; Sat, 02 Nov 91 22:56:29 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 0948;
 Sat, 02 Nov 91 22:56:28 EST
Date:         Sat, 2 Nov 1991 22:54:42 EST
Reply-To: YA-GUI WEI <YAWEI%UCS.INDIANA.EDU@uga.cc.uga.edu>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: YA-GUI WEI <YAWEI%UCS.INDIANA.EDU@uga.cc.uga.edu>
Subject:      Re:  GB and GangXi ZiDian
Comments: To: ccnet-l@uga.cc.uga.edu,
              wang%PENNMESS.PHYSICS.UPENN.EDU@uga.cc.uga.edu
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
Status: RO

It is quite true that it is impossible to represent all possible
Chinese characters that ever existed or will come into existence.
What is needed is a standard language to describe characters
that cannot be found in a standard character set.  Since most
Chinese characters are construted with a few rules, it is possible
to describe most if not all charcters with a set of simple rules.

For example, we can, for a character with left->right construction,
say \zhao4 lin2 (character, character, ...), etc.

A program for producing hard or soft copies of the character can
then interpret the descriptions and construct the image of the
characters as needed.

Let me elaborate my proposed rules in Chinese (zW):

zWHgR;DQWVN*WsSR=a99#,SC#:
zW  #\TlAV#(WVAP#)
zW@}#:  TlAV#(TB#)  #=  Es
zW      TlAV#(:ZRt#)#=  wv
zW      5H!#

zWHgR;DQWVN*IOOB=a99#,SC#:
zW  #\TlB@#(WVAP#)
zW@}#:
zW      TlB@#(P!4sP!#)  #=  fY
zW      5H!#

zWFdK|=a99#:
zW  #\TlV.#(8f#)#=Tl  5H
zW  #\Tl9z#(An#)#=`r  5H

Using these rules recursively one can specify most Chinese characters:

zW  #\TlB@#(?Z#\TlAV#(?Z?Z#)#)  #=  F7
zW  5H!#

We can also specify some derived rules as short hands:

zW  #\TlF7#(HK#)  #=  VZ      5H

Using these rules, even if your software is unable to interpret the
rules and construct the correct characters, it is easy for the
user to guess the intended character.

  Ya-Gui

Correction: I guess the pinyin for zWTl should be "zao4" instead.

From CCNET-L@uga.cc.uga.edu Fri Oct 26 14:58:14 1990
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.64/5.10) with SMTP id AA29218; Fri, 26 Oct 90 14:57:19 -0400
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 2935; Fri, 26 Oct 90 14:55:36 EDT
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 6326;
 Fri, 26 Oct 90 14:53:29 EDT
Date:         Fri, 26 Oct 90 14:49:00 EDT
Reply-To: "J.B. WANG" <SPO_JWANG2%STEVENS.BITNET@uga.cc.uga.edu>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: "J.B. WANG" <SPO_JWANG2%STEVENS.BITNET@uga.cc.uga.edu>
Subject:      Re:  The future of Chinese Computing
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
Status: RO

I think Jiang has the point. Many things are just not up to
the personal likings or dislikings. Although I also believe
we are all smart guys, sometimes I just don't see things
eye to eye with friends like Dr. Yan who tends to believe
that we are world's master.

For 2-D things including the computer, PostScript has already
become the de facto output standard, and it is a waste of time
to debate on that. This is just like to doubt if ASCII is the
best for plain text.

Encoding standards were once a hot topic on Usernet, and  we
(including Ed Lai , myself and other people) had actually
worked out 8-bit <-> 7-bit converter for GB and Big5 for
mailing.
We also had UNICODE 16-bit encoding discussion at one time.

I agree that we should not pretend that we could create a
GB2 and make it an industry standard. This will create a
same mess as it is in Taiwan. UNICODE wants to include all
JIS, GB, KS and others, and make 1 to 1 convertion possible.
And that does not have to comply with a governmental
standard, but can include all.

The input method, too, have the same tendency, be it Tianma,
FeiMa, ch-series, Byx, Toshiba's Japanese WP, and mainland
China's new products. Pure single PinYin input will never
become acceptable. So, let's forget about those CCDOS.


JB Wang

From CCNET-L@uga.cc.uga.edu Tue Jun 25 13:26:41 1991
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.61/5.10) with SMTP id AA23894; Tue, 25 Jun 91 13:26:12 -0400
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 1652; Tue, 25 Jun 91 13:24:33 EDT
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 6193;
 Tue, 25 Jun 91 13:21:25 EDT
Date:         Sun, 23 Jun 1991 22:49:39 -0400
Reply-To: Stephen G Simpson <simpson%MATH.PSU.EDU@uga.cc.uga.edu>
Sender: Chinese Computing Network <CCNET-L%UGA.BITNET@uga.cc.uga.edu>
From: Stephen G Simpson <simpson%MATH.PSU.EDU@uga.cc.uga.edu>
Subject:      PINYIN --> BIG-5 (ETEN) table
Comments: To: ccnet-l@uga.cc.uga.edu, nada.kth.se@math.psu.edu
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
Status: RO

Hi Everybody,

I have constructed a PINYIN --> BIG-5 table based on the PHONETIC.TAB
file in the current version of the ETEN Chinese word processing
system, version 2.03.  The character coding in my table is the same as
in ETEN, i.e. a version of BIG-5.  The table appears to cover all of
the "more frequent" and "less frequent" BIG-5 characters.  To generate
the Pinyins, I used Ed Lai's PINYIN --> GB table, plus Fung F. Lee's
GB <--> BIG-5 conversion routines, plus some other routines I wrote
myself, plus some hand editing.

My table is available for anonymous ftp as
pub/simpson/chinese/py2big.tab on math.psu.edu [128.118.24.21].

My table cannot be more accurate than PHONETIC.TAB, but within that
limitation it should be pretty accurate.  I tried hard to find all the
errors.  If you find any more, please let me know.  I will incorporate
all corrections.

Steve

Stephen G. Simpson               simpson@math.psu.edu
Department of Mathematics        +1 814 863-0775
Pennsylvania State University
University Park, PA 16802

From CCNET-L@uga.cc.uga.edu Tue Apr 23 22:44:28 1991
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.64/5.10) with SMTP id AA25352; Tue, 23 Apr 91 22:44:18 -0400
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 2967; Tue, 23 Apr 91 22:43:50 EDT
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 4876;
 Tue, 23 Apr 91 22:43:47 EDT
Date:         Tue, 23 Apr 91 20:42:35 MDT
Reply-To: mleisher%NMSU.EDU@uga.cc.uga.edu
Sender: Chinese Computing Network <CCNET-L%UGA.BITNET@uga.cc.uga.edu>
From: mleisher%NMSU.EDU@uga.cc.uga.edu
Subject:      The "hc" utility fixed
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
Status: RO

Greetings everyone!  Thanks go to cheng%serg%sdsu.edu (Weixin Cheng)
for alerting me to a bug in the "hc" utility.  It wasn't converting
Shift-GB back into GB correctly.  It has been fixed and is available
as:
crl.nmsu.edu:pub/chinese/hc.tar.Z [128.123.1.14]
-----------------------------------------------------------------------------
mleisher@nmsu.edu                      "I laughed.
Mark Leisher                                I cried.
Computing Research Lab                          I fell down.
New Mexico State University                        It changed my life."
Las Cruces, NM                     - Rich [Cowboy Feng's Space Bar and Grille]

From CCNET-L@uga.cc.uga.edu Tue Jul 23 23:07:21 1991
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.61/5.10) with SMTP id AA01373; Tue, 23 Jul 91 23:07:12 -0400
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 3678; Tue, 23 Jul 91 23:06:39 EDT
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 2170;
 Tue, 23 Jul 91 23:06:33 EDT
Date:         Tue, 23 Jul 1991 22:05:13 -0500
Reply-To: "mr. yawei" <yawei%BRONZE.UCS.INDIANA.EDU@uga.cc.uga.edu>
Sender: Chinese Computing Network <CCNET-L%UGA.BITNET@uga.cc.uga.edu>
From: "mr. yawei" <yawei%BRONZE.UCS.INDIANA.EDU@uga.cc.uga.edu>
Subject:      (forward) Re: printing byx files
Comments: To: ccnet-l@uga.cc.uga.edu
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
Status: RO

I am trying to help forwarding the following message to CCNET. Several
people have attempted to post the message numerous times without
success.  If you see this, consider yourself lucky.

Ya-Gui Wei

----------------------------------------------------------------------
From: lee@milo.stanford.edu (Fung Fung Lee)
To: rzhu@watmath
Subject: Request to forward

I have tried to submit the following message to CCNET-L several times
without getting any response from CCNET-L.  No rejection, acknowledgement,
or distribution of my message from CCNET has been observed, although
I can receive postings from others, and I have previously posted messages
on CCNET.

Could you please forward this message to CCNET?

Fung F. Lee

----------------------------------------------------------------------
>Date: Fri, 5 Jul 91 20:29:18 -0700
>From: lee (Fung Fung Lee)
>To: ccnet-l@uga.cc.uga.edu
>Subject: Re: printing byx files


xiaofei%ACSU.BUFFALO.EDU@uga.cc.uga.edu  wrote

> ahkcus.org [192.55.187.25] has a b2g which converts GB to BIG5 and BIG5 to
> GB. I compiled it on unix and I believe it works on msdos machine also.

Also available on ahkcus.org is the original GB<->BIG5 conversion program,
Hanzi Converter (HC) or hc.  Actually, there was a recent announcement
about it on CCNET-L on June 21, 1991.

I was surprised to find out that most of the source code of b2g, and the
conversion table files were actually the same as those of hc.
Under these circumstances, I usually expect the newer program (b2g) should
in some way enhance the original program (hc).
Unfortunately, b2g removes some of the useful functionalities of hc!


> It seems to me that both hz2ps and news2ps do the same thing, converting big5
> to ps.
> Is there any difference?

There was also a recent annoucement about "hz2ps 2.0" on CCNET-L on
June 11, 1991.  Since the original message already answered this and some
other related questions pretty well, let me repeat it in the following.
To further clarify the message, parts of the man (manual) page of hz2ps
are also included.

(By the way, someone reported "hz2ps 2.0" printed a useless warning about
the lack of some font file.  This has been fixed. You may want to re-ftp
hz2ps from ahkcus.org if you ftp'ed it before June 13, 1991.)


---------------------------------------------------------------------------
>Date:         Tue, 11 Jun 1991 13:45:35 -0700
>Reply-To: Fung Fung Lee <lee%MILO.STANFORD.EDU@uga.cc.uga.edu>
>Sender: Chinese Computing Network <CCNET-L%UGA.BITNET@uga.cc.uga.edu>
>From: Fung Fung Lee <lee%MILO.STANFORD.EDU@uga.cc.uga.edu>
>Subject:      hz2ps version 2.0 available for ftp
>Comments: To: CCNET-L@uga.cc.uga.edu
>To: Multiple recipients of list CCNET-L <CCNET-L@UGA>

This is a software release announcement.

hz2ps (version 2.0) - convert a hanzi (GB/BIG) file to PostScript
-----------------------------------------------------------------

Hz2ps 2.0 is an significantly improved version of hz2ps 1.0, which was
released back in 1989. The bugs which limit the number of pages that can be
printed have been fixed. It now accepts both GB (HGB) and BIG5 files.

Style files used in v1.0 are no longer supported; instead the various
options can now be more conveniently specified in the command line.
The program supports both horizontal and vertical printing mode with or
without page numbers.  Other printing options and fonts can also be
selected. Please see the man page "hz2ps.1" for details.
(e.g. try "nroff -man hz2ps.1")

The program "hz2ps 2.0" is now available on the ftp site "ahkcus.org".
The pertinent file are
ahkcus.org: src/unix/hz2ps-2.0.tar.Z
ahkcus.org: src/unix/hzfont.tar.Z

Enjoy!

Fung F. Lee

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

---------------------------------------------------------------------------
% nroff -man hz2ps.1  | <extract parts of the file>
---------------------------------------------------------------------------


     6 June 1991                                                   hz2ps(1)



     NAME
          hz2ps (version 2.0) - convert a hanzi (GB/BIG) file to PostScript

     SYNTAX
          hz2ps [ options ] [ file ]

     DESCRIPTION
          The hz2ps program converts a GB (HGB) or BIG5 hanzi file to
          PostScript. It supports both horizontal and vertical printing
          mode with or without page numbers.  Other printing options and
          fonts can also be selected.

          The possible options are

          -gb  use GB encoding. This is the default.

          -big use BIG5 encoding.

          -h   horizontal printing mode. This is the default.

          -v   vertical printing mode.

          -margin left  right  bottom  top
               margins measured in inches from lower left corner of a page.
               Default is -margin 1 7.5 1 10.

          -ls line-spacing
               line height (width) in horizontal (vertical) printing mode,
               measured in points (1 in = 72 points).  Default is -ls 15.

          -htab n
               number of hanzi between two adjacent tabs.  Default is 4.

          -hf hanzi-font  point-size  inter-hanzi-spacing
               measure in points. Default is -hf Beijing 10 1.  Note that
               point-size is not the same as bitmap size, see -hbm below.

          -hbm m
               use an m x m hanzi bitmap matrix. Default is -hbm 24.

          -af ascii-font  point-size  width  descender
               Default is -af Courier 10 6 2.

          -pnp left  bottom
               positions to print page number, measured in inches from the
               lower left corner of a page.  Default is -pnp 4.15 0.5.

          -pns page-number
               starting page number.  Default is 1.

          -nopn
               no page number printed.

          The font files and the PostScript prolog file should all be under
          the directory HZDIR (setenv HZDIR the-hanzi-directory).

     FILES
          Each bitmap file contains the bitmaps of consecutive valid code
          in ascending order.  The bitmap of each hanzi is scanned from
          left to right, and top to bottom.  For the NxN/8 bytes belonging
          to an N dot hanzi, the MSB of the first byte is the upper left
          bit; the LSB of the last byte is the lower right bit.  A black
          (white) pixel is represented by a 1 (0).

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


Fung F. Lee

From CCNET-L@uga.cc.uga.edu Sun Nov  3 14:02:38 1991
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.61/5.10) with SMTP id AA13264; Sun, 3 Nov 91 14:02:20 -0500
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 3469; Sun, 03 Nov 91 14:01:20 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 7149;
 Sun, 03 Nov 91 14:01:19 EST
Date:         Sun, 3 Nov 1991 12:59:52 CST
Reply-To: Xiaoyu Li <xiaoyu%GRUMPY.SSC.GOV@uga.cc.uga.edu>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: Xiaoyu Li <xiaoyu%GRUMPY.SSC.GOV@uga.cc.uga.edu>
Subject:      Re:  GB versus KangXi CiDian
Comments: To: ccnet-l@uga.cc.uga.edu
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
Status: RO

Hi, sorry to respond late but I was busy with my own stuff in
the weekend and didn't come to the computer till now.

Xiaofei has raised a very good question. The problem mentioned
I have already encountered sveral times during my typing various
poemes and the Lao Zi's "Dao De Jing". In fact, the GuoBiao table
even seems not to include all the characters in Xin Hua Zi Dian,
not to say the grand KangXi ZiDian character set. For instance,
there are two characters in Xin1 Qi4-Ji3's Ci poem "Jing Kou Bei
Gu Ting": KUAI4 as in the line "Xiu1 Shuo1 Lu2 Yu2 Kan1 Kaui4"
and the WEN4 as in "Wen4 Ying1 Xiong2 Lei4". Both can be easily
found in XinHua ZiDian but are not in the GuoBiao set (I tried
both MacOS 6.07 as well as CXterm). Of course, there is even
a few characters in the Dao De Jing which can be found nowhere
except (I guess) KangXi ZiDian. So my past practice was making
a footnote for these charaters and enlisting them in a preface
chapter. Maybe the best I can do for the moment in our classic
collection project, is the scheme as suggested by Huangxin --
using HanYu PinYin as a substitute, although these PinYin will
look very odd among the rest of the Chinese context.

As for, how to represent all the Chinese characters in the computer
form, I don't think I know a better solution at present -- it's
just beyond my scope/expertise as a "non-scholar" like Xiaofei.
It's won't be an easy task anyway.

BTW, As I used quite a lot the CXterm for inputting, I also noticed
the Inputting Table of the CXterm either misses a few characters
of the GuoBiao set or mis-places them under a wrong pronuciation.
This should be fixed in the future version of CXterm.

--Xiaoyu

PS: I assume Xiaofei and Huangxin both are on CCNET so I delete
    my Cc line from this response to avoid duplication.

From CCNET-L@uga.cc.uga.edu Sun Nov  3 17:04:29 1991
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.61/5.10) with SMTP id AA14527; Sun, 3 Nov 91 17:04:14 -0500
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 3972; Sun, 03 Nov 91 17:03:38 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 0294;
 Sun, 03 Nov 91 17:03:37 EST
Date:         Sun, 3 Nov 1991 16:02:23 CST
Reply-To: Xiaoyu Li <xiaoyu%GRUMPY.SSC.GOV@uga.cc.uga.edu>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: Xiaoyu Li <xiaoyu%GRUMPY.SSC.GOV@uga.cc.uga.edu>
Subject:      Re: CXterm input table (was: Re: GB versus KangXi CiDian)
Comments: To: CCNET-L@uga.cc.uga.edu
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
Status: RO

ygz <ygz%CS.PURDUE.EDU@uga.cc.uga.edu> wrote:
> Could you please tell me which characters are missing or misplaced?

I can not recall. I didn't systematically collect all
the missing or misplaced ones. I'll collect them and
let you know when I encouter them again in the future.

> You don't need to wait for the next version.  You can fix it right
> the way:

Yes, I know this. The input table used on this site has
been modified a lot. I even included those Chinese Biao Dian
Fu Hao in the CCDOS table for my conveniece.

> Cxterm provides an infrastructure for your input method, but we are not
> concentrate on the later.  So do tell me what needs to be fixed in which
> input table.  I will coordinate the changes and place the new version in:

That's actually what I suggested -- fixing for the new version.

BTW, I'd take the opportunity to say thank you for the nice CXterm.

--Xiaoyu

From CCNET-L@uga.cc.uga.edu Mon Nov  4 11:45:27 1991
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.61/5.10) with SMTP id AA24136; Mon, 4 Nov 91 11:44:46 -0500
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 9231; Mon, 04 Nov 91 11:44:32 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 2602;
 Mon, 04 Nov 91 11:44:30 EST
Date:         Mon, 4 Nov 1991 17:40:33 GMT
Reply-To: A06G%DHBRRZ41.BITNET@uga.cc.uga.edu
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: A06G%DHBRRZ41.BITNET@uga.cc.uga.edu
Comments: To: ccnet-l@uga.cc.uga.edu
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
Status: RO

Dear Xiaofei and all others who might be interested in the problem,

Xiaofei indeed points out a very important question. I try to give some
hints by by looking at the way other people have dealt with the problem.

- Shenzhen University: Hong Lou Meng Retrieval System and the Quan Tang Shi
  Retrieval System:
  At Shenzhen University both projects used the GB 2312 code with only
  some 7000 simplified characters. I will not discuss the problem of
  encoding classical Chinese text with simplified characters. As long as
  you use a reference edition in simplified characters the problem will
  not be a problem for the computing people, but the problem must have
  been solved already by the editors of the paper edition. Mainland China
  scholars have produced quit a lot of final editions of important
  classical texts in simplified characters (the best edition for example
  of `Ru Lin Wai Shi' is the Shanghai Guji Chubanshe edition of 1984 in
  simplified characters).
  For Hong Lou Meng there have been some 300 extra characters not found in
  the GB 2312 code. These characters have been created by the character
  generater program (which should be part of every Chinese system), and
  which have been place on empty positions in GB-code. Empty positions
  are for example QU 10 to 15 and QU 88 to 94, altogether 13 QU. Since
  each QU ca accomodate 94 characters, there can be accomodated additional
  1222 characters. Of course, these additional characters do not corespond
  to any standard coding scheem. So if somebody else than the original
  author wants to work with the Hong Lou Meng System, it will not be enough
  to give the electronically available text, but there must go with the
  text the enlarged character fonts.

  With the Tang-Dynasty Poetry the Shenzhen people had much greater problem,
  because there have been more than 2000 characters not found in the
  GB-code. Since there have not been enough empty positions they also put
  Tang-Poetry characters on GB-code positions with characters which
  do not appear in Tang-Poetry. Thus many of the special characters,
  including Japanese hiragana and katakana are overwritten by Chinese
  characters. Personally I do not consider this a very elgant solution,
  but sticking to GB-2312 there is no other way!

- Academy of Social Science, Beijing: Quan Tang Shi System (also!).
  They chose a different approach. First they voted for traditional
  characters. They designed their own coding system together with their
  own Laser Printer system. I think this approach is not advisable,
  because it's not based on any accepted standard. Moreover one has
  to do every thing by oneself. Why did they do so? Because nobody should
  be able to illegaly copy the texts. Or, if one gets a illegal copy
  nobody can use it, because of the non-standard coding system. I can
  understand this approach, since this is a very excellent electronic
  version of the Quan Tang Shi with many times of proofreading and
  quite a few man-years (or should I say woman-years, when I think of
  the many young woman doing the hard work of inputing) invested into
  the project. Nevertheless the responsible people contemplate to
  produce a BIG-5 version of the Quan Tang Shi system

- Academia Sinica, Taibei: 25 History project: Through this project
  the 25 Official Histories are available in electonic form. The datefiles
  are available in two coding scheems: 1) CCCII-code, which is developed
  and maintained by people closely related to the Academia Sinica.
  The CCCII-code is a multy-byte code with up to 50.000 Chinese
  characters, which needs special software to handle the code.
  Readily availble is a library system and a text system. The retrieval
  system for the 25 Histories has been specially programmed for the
  project. Thus it might be difficult to use the CCCII code.

  The Academia Sinica can convert the text of the 25 Histories also
  to the BIG-5 code. In the BIG-5 code - at least in the version of
  ETEN - the user defined characters are collected in a special file,
  which allows up to 5000 characters. Thus: should one ever get some
  date files form the 25 Histories project, they will be acompanied
  by some USERFONTS containing the non-BIG-5 characters.

Having reviewd some famous projects with classical texts it should
be possible to come to some conclusion or suggestion of how to handle
such texts with the available codings scheems.

- Each project concerned with one larger text or a group of related
  text should be coded with a standard coding scheem. It should be
  roughly known whow many non standard characters are to be expected.
  If it's more than some 1000 characters one should use BIG-5 sytems
  such as ETEN, because the GB-code does not allow comfortably for more
  than some 1000 new characters. If there are not too many new characters,
  one can consider the source: if in simplified characters, then GB-2312,
  if in tradtional characters, then BIG-5.

- A definit advantage of a sytem like ETEN (BIG-5 coding) is, that the
  user defined characters are in a separate font, which is much easier
  shipped together with the text than if standard and user font are
  in one big file.

- I think the special fonts for non-standard characters should go together
  with one special text (or may by a groupe of realted texts). I think in
  this way the fonts are easier to handle, than to accumulate all the
  non-standard characters which might appear - say on the level of a
  sinological institute - in one single file. Such large font files might
  become very confusing expecially when date are exchanged between different
  institutions.

- Special fonts which go together with some texts or text groupes should
  be documented. Some programs (as ETEN) provides such an option within
  the character generator program. Such a printed documentation will also
  be useful or even necessary for the input of these characters.
  As soon as larger coding scheems (as UNICODE oder 10646) and user
  software based on it become available, it will not be very hard to
  convert textfiles from a standard coding scheem (GB-2312 or BIG-5)
  supplemented by some user characters to the new system.

What we considered until now is how to handel missing characters when
doing electronic editing. But what to do when transmitting some text
via email. Normaly it is not possible or at least not very handy to
transmit also the necessary font files.

Wei Ya-gui suggested a standard language to describe characters that
cannot be found in a standard character set. If there exists such a
language it could indeed be a useful tool for occasional missing
characters.

Here I would like to suggest another solution, which might be more
appealing within sinological scholarship. When we don't know a character
we look it up in a dictionary. When a coding scheem doesn't know a
character we could also turn to a dictionary and indicate a *unique*
identification of the character in that dictionary. To be useful for
communication such a dictionary should fullfil two creteria: 1) the
characters should be numbered consecutively (no reference by page etc.) and
this numbering should be rather constant during conscutive editions.
2) Such a dictionary should be available in all the major Sinological
institutions.

As reference dictionaries could be used:

- MOROHASHI, within western Sinology this dictionary should be quite
  popular, but I don't know whether it is also accepted in Sinological
  institutions in Mainland China and Taiwan. Contains characters numbered
  from 1 to 48.902.
- Zhon Wen Da Ci Dian, Taibei 1968. Contains characters numbered from
  1 to 49.888.
- The Han Yu Da Zi Dian, Wuhan 1990, which seems to be one of the most
  complete character dictionaries, unfortunately contains no consecutive
  numbering.

In order to distinguish such a number from ordinary numbers, that might
appear in a Chinese text, they should be inclosed by braces (e.g. XYXY
XY<23456><01666>XYXY where XY stands for a Chinese character). When one
gets some files containing such numbers one can look up the corresponding
Chinese character. If necessary I might then incorporate this character
with the fontgenerating program into a USERFONT of my system. With a
simple replace machanism of any editing system these numbers will then
be replace by the characters in my userfont.

Since by now I am no more a active classical sinologist, I would like
very much to hear from experts, what dictionary - if at all - could be
useful. I would like very much to summarize different opinions on
the subject and thus help to find a workable solution for it.

urs

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

From sol.ctr.columbia.edu!lll-winken!uwm.edu!ogicse!plains!kkim@plains.NoDak.edu Mon May  6 12:04:46 EDT 1991
Article: 29695 of soc.culture.china
Path: sol.ctr.columbia.edu!lll-winken!uwm.edu!ogicse!plains!kkim@plains.NoDak.edu
From: kkim@plains.NoDak.edu (kyongsok kim)
Newsgroups: soc.culture.china
Subject: China Standard Character Code (GB13000 or ...): help wanted
Message-ID: <10184@plains.NoDak.edu>
Date: 4 May 91 21:57:48 GMT
Organization: North Dakota State University, Fargo
Lines: 25
Status: RO


	I am a Korean and heard that some China Standard Character Code
contains Hangul (Korean) in addition and Chinese ideographs.  The Std.
document number may be GB13000 but I am not sure.
	I would really like to get the Hangul portion of the
Standard(s).  Is there any kind soul who would mail it to me.  I will pay
postage and copying cost (I expect that the portion will be at most 10
pages).  Since I do not subscribe to this newsgroup regularly, please
e-mail to me if you can help me in any way.
	Thanks in advance.

Kyongsok Kim,

e-mail address:
    Internet: kkim@plains.nodak.edu
    Bitnet:   kkim@plains.bitnet
    Uucp:     ...!uunet!plains!kkim

Office:                              
 Department of Computer Science       
 North Dakota State University        
 300 Minard Hall, P.O.Box 5075        
 Fargo, ND. 58105-5075                
                                      
 (701) 237-8185                       


From CCNET-L@uga.cc.uga.edu Mon Nov 25 12:16:42 1991
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.61/5.10) with SMTP id AA27948; Mon, 25 Nov 91 12:16:20 -0500
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 1102; Mon, 25 Nov 91 12:08:37 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 5814;
 Mon, 25 Nov 91 12:08:36 EST
Date:         Mon, 25 Nov 1991 12:08:23 TZONE
Reply-To: "Minghui Yao, Dept of Physics, ASU" <YAOM%ASUCP1.LA.ASU.EDU@uga.cc.uga.edu>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: "Minghui Yao, Dept of Physics, ASU" <YAOM%ASUCP1.LA.ASU.EDU@uga.cc.uga.edu>
Subject:      Re: GB and BIG5
Comments: To: ccnet-l@uga.cc.uga.edu
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
Status: RO

I don't know much about GB and Big5 technically. But I am an advocator
of simplified Chinese Characters. The evolution of Chinese Characters is
a nature simplifying process, from complex to simplicity. If a language
is unchanged, it is dead.

Merits of simplfed char?
(1)Easy to learn. This is especially important for a country whose
population is over 1100000000, and whose education level is still
comparatively low.
(2)More economical: one can write in simplified char faster.(printer
can print faster?:-) )  This is very important in a modern soceity.
(3)It's nature. Most simplied chars are NOT created unreasonably by
PRC government. They have existed for hundreds of years in Chinese
handwritting.(you can find them in CaoShu and XingSu)

As far as simplified Chinese Char is concerned, GB is adquate.
We have published 34 issues of HXWZ (16000x34 chars).Yet, we have
not come across a single char that could not be found in GB.(some
might say that we used 'substitute':-). But they are not. They are
official chars in mainland China.)  We have not got a complaint
about simplified char from 3400 HXWZ subscribers yet.

As Wei Lin and XiaoFei said in their postings, language is used to
convey an idea. If a 'substituting' char can convey the idea, then
I don't see anything wrong in the 'substitution'. If an 'original'
(or 'traditional') char is used to convey the idea, but 99% people
don't recongnize that char, then the char is useless, it will be
dead(or already dead).

 Minghui Yao

From CCNET-L@uga.cc.uga.edu Mon Nov 25 12:54:11 1991
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.61/5.10) with SMTP id AA28214; Mon, 25 Nov 91 12:54:00 -0500
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 1341; Mon, 25 Nov 91 12:53:35 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 8040;
 Mon, 25 Nov 91 12:53:34 EST
Date:         Mon, 25 Nov 1991 12:52:21 -0500
Reply-To: Stephen G Simpson <simpson%MATH.PSU.EDU@uga.cc.uga.edu>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: Stephen G Simpson <simpson%MATH.PSU.EDU@uga.cc.uga.edu>
Subject:      Re: GB vs BIG-5
Comments: To: ccnet-l@uga.cc.uga.edu
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
Status: RO

"Minghui Yao, Dept of Physics, ASU" writes:
 > I don't know much about GB and Big5 technically. But I am an advocator
 > of simplified Chinese Characters. The evolution of Chinese Characters is
 > a nature simplifying process, from complex to simplicity. If a language
 > is unchanged, it is dead.

and he goes on to list other merits of simplified characters.

I can't really comment on the literary or historical question.  I am
not a native Chinese speaker or a deep student of the language and its
history.  And I am certainly not opposed to simplified characters, I
myself prefer them in handwriting.

My only point about traditional versus simplified characters was a
practical one.  Usually, if you are preparing a document, you are
doing so for some particular purpose, i.e. publication in some
fashion.  Therefore, you have to take account of the stylistic
conventions of the publication medium.  If you are publishing in a
newsletter that uses simplified characters, GB is a very practical
choice.  Some other publications may insist on traditional characters,
and preserve distinctions as between Mian4 ("face") and Mian4 ("wheat
flour").  For these publications, the author may find BIG-5 more
practical.  In the United States, many Chinese scholarly books,
newspapers, and other printed publications are in traditional
characters, so this may be a consideration.  That's all I wanted to
say.  I didn't mean to offend anyone or express a preference for one
type of character over the other.

 > As far as simplified Chinese Char is concerned, GB is adquate.
 > We have published 34 issues of HXWZ (16000x34 chars).Yet, we have
 > not come across a single char that could not be found in GB.(some
 > might say that we used 'substitute':-). But they are not. They are
 > official chars in mainland China.)  We have not got a complaint
 > about simplified char from 3400 HXWZ subscribers yet.

I too would like to congratulate the publishers of HXWZ, you are doing
a great job.

When I said `substitute', I meant from the point of view of
traditional characters.  I am aware that in mainland China these
`substitutions' are not really substitutions, they are official
standards, so for instance it is actually incorrect to use the
traditional character Mian4 ("flour"), although older books still
contain this character.  I think of this as being something like the
distinction between British and American spelling, one spelling is
correct in America and the other is correct in Britain, neither one is
inherently better.

My only point about this was that the person who wants to print a
document in traditional characters will have problems with GB, even if
he is using a traditional character font.

From CCNET-L@uga.cc.uga.edu Mon Nov 25 13:51:48 1991
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.61/5.10) with SMTP id AA28672; Mon, 25 Nov 91 13:51:32 -0500
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 1878; Mon, 25 Nov 91 13:51:19 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 2199;
 Mon, 25 Nov 91 13:51:18 EST
Date:         Mon, 25 Nov 1991 12:48:38 CST
Reply-To: Jianxun Ding <jding%CS.TAMU.EDU@uga.cc.uga.edu>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: Jianxun Ding <jding%CS.TAMU.EDU@uga.cc.uga.edu>
Subject:      Re: GB and BIG5
Comments: To: YAOM%ASUCP1.LA.ASU.EDU@uga.cc.uga.edu
Comments: cc: ccnet-l@uga.cc.uga.edu
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
In-Reply-To:  <9111251731.AA19729@neuron.cs.tamu.edu>; from "Minghui Yao,
              Dept of Physics, ASU" at Nov 25, 91 12:08 pm
Status: RO

> As far as simplified Chinese Char is concerned, GB is adquate.

  I think you should specifically say "GB 2312" according to your
  context.   There is GB xxxx ( I don't know the specific number)
  that is for traditional Chinese Characters.

  --Jianxun Ding
    Dept. of Computer Science
    Texas A&M University

From CCNET-L@uga.cc.uga.edu Mon Nov 25 15:01:41 1991
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.61/5.10) with SMTP id AA29268; Mon, 25 Nov 91 15:01:29 -0500
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 2725; Mon, 25 Nov 91 15:00:32 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 7823;
 Mon, 25 Nov 91 15:00:31 EST
Date:         Mon, 25 Nov 1991 14:57:31 -0500
Reply-To: Stephen G Simpson <simpson%MATH.PSU.EDU@uga.cc.uga.edu>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: Stephen G Simpson <simpson%MATH.PSU.EDU@uga.cc.uga.edu>
Subject:      Re: GB and BIG5
Comments: To: Jianxun Ding <jding@cs.tamu.edu>, ccnet-l@uga.cc.uga.edu
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
In-Reply-To:  <9111251851.AA03696@leibniz.math.psu.edu>
Status: RO

Jianxun Ding writes:
 > > As far as simplified Chinese Char is concerned, GB is adquate.
 >
 >   I think you should specifically say "GB 2312" according to your
 >   context.   There is GB xxxx ( I don't know the specific number)
 >   that is for traditional Chinese Characters.
 >
 >   --Jianxun Ding
 >     Dept. of Computer Science
 >     Texas A&M University

Wow!  That is really interesting.  I'm generally surprised.  Live and
learn.  Where can I find out more or get a font for GB xxxx?  Is there
a public domain font, like the CCLIB fonts for GB-2312?  Is there any
software for GB xxxx?

From CCNET-L@uga.cc.uga.edu Tue Nov 26 10:14:51 1991
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.61/5.10) with SMTP id AA08716; Tue, 26 Nov 91 10:14:20 -0500
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 7820; Tue, 26 Nov 91 10:14:00 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 6799;
 Tue, 26 Nov 91 10:13:59 EST
Date:         Tue, 26 Nov 1991 10:12:31 -0500
Reply-To: Benjamin Ao <ao-b%CIS.OHIO-STATE.EDU@uga.cc.uga.edu>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: Benjamin Ao <ao-b%CIS.OHIO-STATE.EDU@uga.cc.uga.edu>
Subject:      Re: GB versus BIG-5
Comments: To: ccnet-l@uga.cc.uga.edu
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
Status: RO

I agree with Stephen that BIG-5 is more useful, because it's a superset
of GB. I think it's rather narrow-minded to say that we don't need any
of the edge of BIG-5 over GB as long as we stick to the simplified
characters. Traditional characters are a reality to be reckoned with by
any serious language scientist, as long as there are people using them
and there are materials written or printed in them. The difference
between traditional and simplified characters is not the issue here.
The real issue is how many characters should be included in a character
set to be used on a daily basis, and what can be done about characters
that are not included. I believe that there is an optimal solution to
this problem. And such a solution should be based on the statistical
properties of the characters. True, there has never been any research
of the statistical properties of all the characters used in all walks
of life in the past hundred or so years. Yet, the probability of
occurrence of any linguistic unit, including the character, is dictated
to a large degree by the structure of language. Whatever material we
use, the more frequently used characters will be the same, although each
character's ranking in relative frequency of occurrence may vary.
According to the study I referred to in my last posting, 3000 characters
already cover 99.15% of all the characters in that corpus of data. Any
other corpus of data will yield the same result, although the composition
of the 3000 character may not always be the same. In other word, the over-
whelming majority of characters have a very low probability of occurrence.
If 7754 characters already covered 100% of the over 11 million characters
used in a huge corpus of data that included studied in literature,
philosophy, linguistics, etc, then it's not likely that any other character
will have a more than 1 millionth probability of occurrence. This is not
to say that none of those infrequent characters will ever be used in a
text, in fact some of them do pop up occasionally. The question is whether
this justifies the inclusion of most or all of the infrequent characters
in a basic charater set, and if not, how big should the basic set be.

From CCNET-L@uga.cc.uga.edu Wed Nov 27 00:33:49 1991
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.61/5.10) with SMTP id AA14073; Wed, 27 Nov 91 00:33:12 -0500
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 7027; Wed, 27 Nov 91 00:32:42 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 3622;
 Wed, 27 Nov 91 00:32:41 EST
Date:         Wed, 27 Nov 1991 00:29:10 EST
Reply-To: Ned Walsh <walsh%CUNIXA.CC.COLUMBIA.EDU@uga.cc.uga.edu>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: Ned Walsh <walsh%CUNIXA.CC.COLUMBIA.EDU@uga.cc.uga.edu>
Subject:      Re: GB versus BIG-5
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
Status: RO

Just my 2 cents...

Benjamin Ao wrote:

>I agree with Stephen that BIG-5 is more useful, because it's a superset
>of GB.

Not exactly.  Big-5 is not a superset of GB.  It does not include
simplified characters, which should be considered variants of their
traditional forms.  Very often I need traditional characters,
simplified characters, and Japanese touyou kanji and kana all in the
same file.  This is impossible with a GB-based system.  It is
possible, though awkward, in ETen and other Big-5 systems by putting
simplified characters in a separate userfont file allowed for by the
coding system; of course, though, there is no standardized simplified
character userfont file, so if you want to share a Chinese file the
userfont file must go with it.  ChinaStar's character set allows
mixing simplified and complex characters if you're willing to pay
something like $900 for their ROM-card system; but then you're stuck
with a file that can only be read by ChinaStar (there is no utility to
convert ChinaStar files to GB or Big-5 code).  Tianma and Guoqiao
support both traditional and simplified characters--but only one set
at a time; you can't mix the two in the same file.

There are plenty of serious Chinese computer users who would be
willing to sacrifice RAM and disk space to accomodate a broader
character set than that offered by either Big5 or GB.  Not that every
version of every application must support all the characters in a set,
but there needs to be a standardized code and public domain bitmap
fonts for far more than 8,000 or 13,000 characters.

It would be nice if the Taiwanese Ministry of Education would design a
series of standardized Big5 userfonts--one for simplified characters
(one country, two systems:) ) and others for, say, Chinese
Buddhist texts, or classical poetry, or dialect-specific characters,
or Touyou kanji.

As I understand it, the PRC's GuoBiao code was supposed to include a
primary set of codes (GB 2312) for commonly used, simplified
characters, and auxiliary sets to cover traditional forms and
dialect- or region-specific characters.  I assume the auxiliary sets
idea never got very far.  Anyone know?

Where's Unicode when you need it?

And while I'm in a whining sort of mood, I might as well mention
there's still no solution to the sorting problem I mentioned last
month.

/Ned

p.s.

As for simplified vs traditional: Is there any hard data indicating
that simplified characters are any easier to learn than traditional
characters?  or indicating that they are easier to read (i.e. fewer
"misreadings")?  I suspect it makes no difference, that the only
significant effect of simplifcation is to increase writing speed and
make printing easier.  It also is my impression that people who learn
simplified characters first have a very difficult time adjusting to
traditional characters, whereas people who have learned traditionals
first adjust to simplified rather quickly after the initial shock
wheres off.  I suppose it's the old problem of non-commutivity of
simplification rules.  In any case, in most situations I suppose it
doesn't really matter whether you use simplified or traditional forms.
But in some situations it's essential that you reproduce as closely as
possible the forms of the characters used in the original text--for
example, in poetry, when you might be trying to spot visual puns, or
clues for dating and placing a text. It's somewhat analogous to
preserving old spellings for pre-modern English literature.  But I
digress from CCNET-ish interests...forgive me.

From CCNET-L@uga.cc.uga.edu Wed Nov 27 04:56:54 1991
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.61/5.10) with SMTP id AA15142; Wed, 27 Nov 91 04:56:39 -0500
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 7736; Wed, 27 Nov 91 04:56:20 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 8249;
 Wed, 27 Nov 91 04:56:18 EST
Date:         Tue, 26 Nov 1991 17:20:31 GMT
Reply-To: A06G%DHBRRZ41.BITNET@uga.cc.uga.edu
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: A06G%DHBRRZ41.BITNET@uga.cc.uga.edu
Subject:      BIG-5/GB2312
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
Status: RO

This week began with a very lively discussion on different coding
scheems. I got the impression that some arguments have been taken
to personal. I do not think that it will be we to influence what
code will be use in the (could I call them) CJK-countries.
The GB 2312 is the official standard in mainland China and is
suitable for the handling of modern texts and data. Of course
it's adapted to the local conditions in mainland China, i.e. it is
based on the simplified characters. So if I have to do with scholars,
and institutions from mainland China or even topics concerned
with modern China, the use of GB 2312 might be a proper choice. With
GB 2312 there is a one to one relation in code and character in
the written/printed material from mainland China.

The same holds true for Taiwan. BIG-5 is not only the quasi standard
code in Taiwan, but it is also a traditional character code. Thus those
writing and encoding traditional characters probably will use very
naturally the BIG-5 code, because it gives coding points for the
traditional character set. There is no one to one mapping possible
between the GB 2312 and the BIG-5 code, because of the "one to many"
between simplified and traditional characters.

[Some notes concerning further code tables beyond GB 2312, which someone
mentioned in a email:]
In mainland Chinese publications sometimes one comes across some hints,
that other coding plans than GB 2312 are already finished. But
whenever one asks for more then the mere confirmation of this fact, nobody
seems to have seen this coding scheems, not to speak of an available
public domain font. There are two follow up coding tables to GB 2312
(simplified) and altogether three alternate coding tables containing the
corresponding traditional characters.
  -----------------------------------------
  charcters   simplified        traditional
  -----------------------------------------
     6763         G0 (GB 2312)      G1
     7237         G2                G3
     7039         G4                G5
  -----------------------------------------
It is only to speculate: I think that these coding tables will never
be released. Mainland China is now very much engaged in pushing a
unified Han-code for alls the CJK-countries. G2 to G5 might just internally
be used for reference in deciding on the inclusion of characters in this
new universal code. It is very lucky that Mainland China, Taiwan, Japan
and Korea are working together in this very important field. In a few
years this universal code should be available (as ISO DIS 10646?). Very
important: this code should contain UNICODE, i.e. UNICODE will be a
(very important) subset of ISO 10646.

[let me answer somthing to Huang Yolin's ideas:] I do not think that the
simplified characters should or could be regarded as a style or fontface.
It has nothing to do with politics (though both sides used to demonstrate
the superiority of the political system by pointing to their way of
handling the simplified/traditional issue), but it is a fact, that in
mainland China the simplified characters are not only an official standard,
but are well accepted among the population. The simplified characters
cannot be considered writing variants of the traditional characters,
just because there is no one to one relation between the two character sets.

On the same reason I also would not say that the GB-code is for beginners,
and the BIG-5 code is for the learned. Whenever you use traditional
characters one should/could use BIG-5. Thus people in Taiwan use BIG-5
and People in mainland China doing computer aided research in classical
fields will also (and actually do) use BIG-5 as I demonstrated in a
earlier email on full text systems.

The day is closing here in Bremen and the sky is already dark
Urs Widmer

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

From CCNET-L@uga.cc.uga.edu Wed Nov 27 09:30:51 1991
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.61/5.10) with SMTP id AA16654; Wed, 27 Nov 91 09:30:43 -0500
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 8545; Wed, 27 Nov 91 09:29:39 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 5578;
 Wed, 27 Nov 91 09:29:38 EST
Date:         Wed, 27 Nov 1991 09:28:22 EDT
Reply-To: Benjamin Ao <ao-b%CIS.OHIO-STATE.EDU@uga.cc.uga.edu>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: Benjamin Ao <ao-b%CIS.OHIO-STATE.EDU@uga.cc.uga.edu>
Subject:      Re: GB versus BIG-5
Comments: To: walsh%CUNIXA.CC.COLUMBIA.EDU@uga.cc.uga.edu
Comments: cc: ccnet-l@uga.cc.uga.edu
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
In-Reply-To:  Message from "Ned Walsh" of Nov 27, 91 at 12:29 am
Status: RO

Ned Walsh wrote:
>
> Benjamin Ao wrote:
>
> >I agree with Stephen that BIG-5 is more useful, because it's a superset
> >of GB.
>
> Not exactly.  Big-5 is not a superset of GB.  It does not include
> simplified characters, which should be considered variants of their

	When I said BIG-5 was a superset, I was assuming that the simplified
characters share the same coding with their traditional counterparts, but
are put in a different font.

> traditional forms.  Very often I need traditional characters,
> simplified characters, and Japanese touyou kanji and kana all in the
> same file.  This is impossible with a GB-based system.  It is

	This is not true. As long as the text editor can handle multiple
fonts in a text, it is possible, provided that the missing characters
involved in the one-to-many mapping are also supported.

> possible, though awkward, in ETen and other Big-5 systems by putting
> simplified characters in a separate userfont file allowed for by the
> coding system; of course, though, there is no standardized simplified
> character userfont file, so if you want to share a Chinese file the
> userfont file must go with it.  ChinaStar's character set allows

	Standardization is indeed very important.

> mixing simplified and complex characters if you're willing to pay
> something like $900 for their ROM-card system; but then you're stuck
> with a file that can only be read by ChinaStar (there is no utility to
> convert ChinaStar files to GB or Big-5 code).  Tianma and Guoqiao
> support both traditional and simplified characters--but only one set
> at a time; you can't mix the two in the same file.

	You may tell the developers about this. It shouldn't be too hard
to fix this problem.
>
> There are plenty of serious Chinese computer users who would be
> willing to sacrifice RAM and disk space to accomodate a broader
> character set than that offered by either Big5 or GB.  Not that every
> version of every application must support all the characters in a set,
> but there needs to be a standardized code and public domain bitmap
> fonts for far more than 8,000 or 13,000 characters.

	In theory, we need as many formally coded characters as there
have been on the earth, i.e. well over 90,000. Imagine, for examply,
what would be called for if someone decided to eletronicize Dai Kanwa
Jiten. In practice, however, this does not mean every font file must
contain over 90,000 characters, although they probably should all be
formally coded. The coding scheme need not be one dimensional. Rather,
all these characters can be divided into groups of say 8000 or even even
fewer characters. Each group is treated as a different font, and given
a standard font name. Thus, character A and character B may be totally
unrelated, but nevertheless share the same code in two different fonts.
This idea is similar to Ned Walsh's suggestion below. This way, one does
not need to sacrifice too much for a single giant font, but has the
flexibility of choosing from a number of small font according to his/her
needs. Of course, in order to do so, the text editor must have a good
font management capability, which is not at all difficult to implement.
>
> It would be nice if the Taiwanese Ministry of Education would design a
> series of standardized Big5 userfonts--one for simplified characters
> (one country, two systems:) ) and others for, say, Chinese
> Buddhist texts, or classical poetry, or dialect-specific characters,
> or Touyou kanji.
>

From CCNET-L@uga.cc.uga.edu Wed Nov 27 10:14:43 1991
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.61/5.10) with SMTP id AA16922; Wed, 27 Nov 91 10:14:31 -0500
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 8966; Wed, 27 Nov 91 10:14:12 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 9195;
 Wed, 27 Nov 91 10:14:11 EST
Date:         Wed, 27 Nov 1991 10:12:43 EDT
Reply-To: Benjamin Ao <ao-b%CIS.OHIO-STATE.EDU@uga.cc.uga.edu>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: Benjamin Ao <ao-b%CIS.OHIO-STATE.EDU@uga.cc.uga.edu>
Subject:      Re: GB versus BIG-5 p.s.
Comments: To: walsh%CUNIXA.CC.COLUMBIA.EDU@uga.cc.uga.edu
Comments: cc: ccnet-l@uga.cc.uga.edu
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
In-Reply-To:  Message from "Ned Walsh" of Nov 27, 91 at 12:29 am
Status: RO

Ned wrote:
> p.s.
>
> As for simplified vs traditional: Is there any hard data indicating
> that simplified characters are any easier to learn than traditional
> characters?  or indicating that they are easier to read (i.e. fewer
> "misreadings")?  I suspect it makes no difference, that the only

	No! None whatsoever! There has never been any comparative
study done to prove those claims. The only observable and undeniable
fact is that characters with fewer strokes are easier for first and
second graders, who are just learning to control their pencils, to
write in a small square.

> significant effect of simplifcation is to increase writing speed and
> make printing easier.  It also is my impression that people who learn

	Writing simplified characters is faster only if you are
a beginner or if you are writing in printing style (kai3 shu1). There
is little or no difference if you write in running style (xing2 shu1).
Simplification has no effect whatsoever on printing or typing, except
that one has to change the entire set of types.

> simplified characters first have a very difficult time adjusting to
> traditional characters, whereas people who have learned traditionals
> first adjust to simplified rather quickly after the initial shock
> wheres off.  I suppose it's the old problem of non-commutivity of

	It's slightly more complicated. People who learn simplified
characters have a difficult time with writing traditional characters but
not with reading them. The reason is that even in the mainland, they may
often read materials in traditional characters, although they don't need
to write in traditional characters. On the other hand, people who learn
traditional characters have no trouble with writing some of the simplified
characters, because they use those characters in their everyday writing
anyway. However, these people usually don't have access to materials
printed in simplified characters, and therefore often have a hard time
getting used to them.

> simplification rules.  In any case, in most situations I suppose it
> doesn't really matter whether you use simplified or traditional forms.
> But in some situations it's essential that you reproduce as closely as
> possible the forms of the characters used in the original text--for
> example, in poetry, when you might be trying to spot visual puns, or
> clues for dating and placing a text. It's somewhat analogous to
> preserving old spellings for pre-modern English literature.  But I
> digress from CCNET-ish interests...forgive me.
>

	The simplification of Chinese characters was meant to lessen the
burden of students of the Chinese writing system. But, as an American
sinologist pointed out, "the gloomy fact is that as a student of the
Chinese language, I have to study both the traditional writing system
and the simplified system", which effectively made the burden of students
of the Chinese writing system even worse. Moreover, it causes an additional
headache to the already complicated issue of Chinese language computing.
This is one of the best examples of a nearsighted and failed language
planning policy which achieves exactly the opposite of what it was intended
for.

From CCNET-L@uga.cc.uga.edu Wed Nov 27 19:13:20 1991
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.61/5.10) with SMTP id AA20610; Wed, 27 Nov 91 19:10:02 -0500
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 3866; Wed, 27 Nov 91 19:09:27 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 8265;
 Wed, 27 Nov 91 19:09:26 EST
Date:         Wed, 27 Nov 1991 19:06:47 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:      GB vs BIG-5: technical point of view
Comments: To: CCNET-L@uga.cc.uga.edu
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
Status: RO

The fundamental problem faced by the any Chinese encoding scheme designer
is that there are too many Chinese characters.  Many consider Big5 better
than GB2312-80 because Big5 has more characters.  However, from technical
point of view, the Big5 has several problems.

The biggest problem is that Big5 contains too many characters in one
character set, so that them can not be put into one 2-byte coding plane.
In ISO 2022 (international standard for encoding and combining character
sets), a 2-byte code set is encoded in two 7-bit octets, each octet in
0x21-0x7e.  So a 2-byte code set can at most hold 94x94 = 8836 characters.
Therefore, Big5 shouldn't be defined as a 2-byte encoding at all.  It
can be a 3-byte encoding as in CNS 11643.

Not conforming to ISO 2022 standard, Big5 has many technical problems.

First, Big5 is not an acceptable standard in many internationalized
software system, although it is widely used in Taiwan and elsewhere.
For example, Big5 does not work well with X window system.  You cannot
use Big5 in inter-client communication such as cut and paste, window
properties, resources, etc.  You have to either sacrifice Big5, as in
kterm, where Big5 code is converted to GB first before cut & paste; or
sacrifice the the generality, as in cxterm, where X11 Compound Text
Encoding standard is not followed.  Either way, Big5 is frustrated.

Second, Big5 cannot be efficiently converted to 7-bit internal code
representation.  Although the most practical systems exclusively use the
double-byte 8-bit internal code representation, i.e. use "1XXXXXXX ?XXXXXXX"
for a Chinese character, GB2312-80 defines only 7 bits in each byte,
(i.e. "_XXXXXXX _XXXXXXX").  GB can be represented in 7-bit environment
(i.e. "0XXXXXXX 0XXXXXXX") by using standard ESC sequence, as defined in
ISO 2022.  Efficient representation of a code set in 7-bit environment
is essential because such code set can extend and co-exist with other
code sets.  Once needed, all the GB text we currently used, such as XHWZ,
poems, etc, can be easily converted into 7-bit and fit into ISO platform.
Moreover, if many uncommon Chinese characters are required, a new code set
of rarely used characters can be designed and join in.  Big5 simply
doesn't have such expanding capability.

Third, the mixture of two coding planes in one code set in Big5 adds extra
difficulty to the software development.  For example, in GB encoding, it
is straightforward to tell whether any given byte is a part of a Chinese
character or not.  But in Big5, it is much more complicated, sometimes you
need to trace back to the beginning of the text.  As another example,
elvis/celvis already has multi-font feature.  Make it a 7-bit Chinese editor
for GB encoding is quite possible, but for Big5 encoding, I don't have
any solution yet.  In my development of cxterm and celvis, I found Big5
had led to many problems which would not have existed otherwise.  Therefore,
Big5-oriented system is intrinsically more complex.

It is quite interesting that many software systems I know of, which are
developed outside China, HK, and Taiwan (means that you have absolute
freedom to choose GB or Big5), are either designed for GB exclusively,
or designed for GB first and added Big5 later.  For instance, ChTeX, HZ,
and many PC Chinese editors support GB only.  Cxterm, celvis, xhzview,
pmTeX, etc., were initially designed to support GB only, Big5 supporting
feature were added later.

Forth, Big5 cannot be easily split into 2 ISO conforming character sets.
Big5 is divided into 2 levels, level 1 (5401 characters) and level 2
(7650 characters).  These two levels should have been put into separated
planes to ensure efficiency.  However, Big5 isn't arranged this way.
Level 1 occupies the lower space of both GL plane ("1XXXXXXX 0XXXXXXX")
and GR plane ("1XXXXXXX 1XXXXXXX"); level 2 occupies the higher space
of both.  Since GL and GR set must use different escape sequences, one
has to switch back and fore all the time, adding unnecessary overhead.
If the two levels were put into separated planes, say, level 1 in GR
and level 2 in GL, it would be more efficient.  We could simply stick
with GR and occasionally switch to GL (because the level 2 is not so
commonly used), which was acceptable.


I think GB may be a technically better way to start.  It conforms ISO
standard and makes itself really adaptable.  It is extendible to work
together with other character sets.

If we stay with double-byte code, we can also absorb Big5 into a "twin
character sets double-byte" scheme: put the common used character set,
GB2312-80 in GR plane ("1XXXXXXX 1XXXXXXX"), and put another less
frequently used character set (including traditional characters) in GL
plane ("1XXXXXXX 0XXXXXXX").  This scheme has many advantages over Big5:
it can be made acceptable to most internationalized systems; it can be
easily expanded and efficiently converted into 7-bit; and it can have
more characters than Big5 (max: 17672 = 2*94*94).  The disadvantage is
that there is no immediately distinction between a Chinese byte and a
ASCII byte, hence it is hard to process, but no harder than Big5.

CNS 11643 is another choice.  It's a 3-byte 7-bit encoding, level 1 and
level 2 of Big5 are put into different planes in CNS 11643.  However,
if CNS 11643 is put in double-byte internal code representation, there
will be no place for many frequently used simplified characters.


Here I am not intended to judge which one is overall better, Big5 or
GB, nor to say which one you should use.  Neither do I comment the
future trends of encoding systems, including ISO 10646 and Unicode,
which require rewriting of almost everything.  I simply stated the
technical problem I saw of Big5, under the current framework of ISO
2022 encoding system.  Comments are welcome.


Yongguang Zhang
Purdue Dept of Computer Sciences


Appendix 1:  GB encoding standard

By GB we usually refer GB2312-1980, "Code of Chinese Graphic Character
for Information Interchange, Primary Set".   It was announced in 1980,
and registered with ISO.  The "final character" of ESC sequence assigned
by ISO is `A'.  (`B' is assigned to Japanese JIS X0208-1983, and `C'
to Korean KS C5601-1987.)

Around 1983, a CCIPS (China Computer & Information Processing Standard-
ization) technical committee is formed to be parallel with ISO/TC97;
CCIPS/SC2 is formed to be parallel with ISO/TC97/SC2. In 1984 CCIPS/SC2
proposed 6 sets of "Code of Chinese Graphic Character for Information
Interchange".  All sets were designed to be in double-byte 7-bit encoding.
Here is the list.

Basic Set:
  GB2312-1980, national standard, announced in 1980.
  7445 graphic characters: 202 symbols, 60 ordinals, 22 numbers,
	52 Latin, 169 Kana, 48 Greek, 66 Russian, 26 pinyin symbols,
	37 zhuyin (bopomofo), 6763 Hanzi (simplified).
    hanzi:
	level 1: 3755 (in pinyin pronunciation order),
	level 2: 3008 (in radical order).

1st Aux Set:
  GB12345-90, recommended national standard, announced in 1990.
  Traditional counterpart of the Basic Set.
  7583 graphic characters: 682 non-Hanzi (same as in the Basic Set),
	35 punctuations and pinyin, 6886 Hanzi (traditional).
    in 6886 Hanzi:
	level 1: 3755,
	level 2: 3008,
	level 3: 103 (many-to-one traditional characters in level 1, 2).

2nd Aux Set:
  GB7589-87, announced in 1987.
  Less frequently used characters than the Basic Set (GB2312).
  7237 graphic characters: all simplified Hanzi (in radical order).

3rd Aux Set:
  yet to be announced, under final preparation.
  Traditional counterpart of the 2nd Aux Set.
  7237 corresponding traditional Hanzi.

4th Aux Set:
  GB7590-87, announced in 1987.
  Really less frequently used characters.
  7039 graphic characters: all simplified Hanzi (in radical order).

5th Aux Set:
  yet to be announced, under final preparation.
  Traditional counterpart of the 4th Aux Set.
  7039 corresponding traditional Hanzi.

No software system or font for any GB Aux set is available.

Reference:
The Status and Progress of Chinese Language Processing Technology
ACCC, International, Beijing, China, 1991

From CCNET-L@uga.cc.uga.edu Thu Nov 28 06:03:08 1991
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.61/5.10) with SMTP id AA24295; Thu, 28 Nov 91 06:02:58 -0500
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 5869; Thu, 28 Nov 91 06:01:58 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 1578;
 Thu, 28 Nov 91 06:01:57 EST
Date:         Thu, 28 Nov 1991 11:28:19 +001
Reply-To: AG02005%MVS.UNI-C.DK@uga.cc.uga.edu
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: AG02005%MVS.UNI-C.DK@uga.cc.uga.edu
Subject:      GB aux. set is in use.
Comments: To: ccnet-l@uga.cc.uga.edu
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
Status: RO

 After having read posting on GB vers. BIG5, I can't help but writing
 what I learnt about GB set for traditional chars. Probably better to
 call it GB aux. set.
 I happen to have access to LianXian Han Ka system, the handling of
 traditional characters requires FANTIZI fonts. The system has a BASIC
 program to convert Jianti GB to Fanti GB file. To solve ONE to MANY
 characters problem in conversion, the BASIC search for string or phrase,
 so the wrong conversion can be kept low depending the context of the GB
 file. I counted the number of one to many character to be 119 on a
 24x24 FANTIZI font beginning at serial No. 941 and onwards. The total
 size of FANTIZI 24x24 is 588816, which means 8178 characters in all.
 It doesn't complete compatible with BYX since BYX doesn't have full
 range of GB code. Otherwise, it will be trivial to let BYX compatible
 with this GB aux set. The BYX 2.0A I bought can be redefined to reach
 those one to many characters via pinyin input method.
 The only thing I hate about LianXiang HanKa is it protects the FANTIZI
 fonts i.e 24x24 (although bitmapped format) in such a manner that it
 requires a drivers to be loaded in memory to decode the font when
 printing.
 It seems to me the soft company doesn't even want to share how the
 conversion is made. The BASIC program is saved with protect parameter P.
 To have a look at the conversion tricks, I have to look into RAM and
 hacked it out. I don't how if is illegal :++).
 I think if software is written with copy-protect nonsense, it should be
 legal to hack. +++)
 An interesting story which has nothing to do with software, but I would
 like to share with you. This country is going to add tax on empty
 cassettes and video tapes to compensate those would-be copy right holders
 for lose of pirat copying. Just image  someday the stupid politicians
 are ready to add tax on blank diskettes.

From CCNET-L@uga.cc.uga.edu Tue Nov 19 11:47:13 1991
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.61/5.10) with SMTP id AA02225; Tue, 19 Nov 91 11:46:57 -0500
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 7701; Tue, 19 Nov 91 11:46:19 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 9104;
 Tue, 19 Nov 91 11:46:07 EST
Date:         Tue, 19 Nov 1991 11:37:45 EST
Reply-To: Ned Walsh <walsh%CUNIXA.CC.COLUMBIA.EDU@uga.cc.uga.edu>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: Ned Walsh <walsh%CUNIXA.CC.COLUMBIA.EDU@uga.cc.uga.edu>
Subject:      Big5 to GuoBiao conversion
Comments: To: CCNET-L@uga.cc.uga.edu
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
Status: RO

Does anyone know whether the b2g Big5/GuoBiao conversion utility
expects Hong Kong University Big5 or ETien Big5?  Or doesn't it make
any difference?

/Ned

From CCNET-L@uga.cc.uga.edu Sat Nov 23 13:16:07 1991
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.61/5.10) with SMTP id AA15590; Sat, 23 Nov 91 13:15:54 -0500
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 3182; Sat, 23 Nov 91 13:15:30 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 9145;
 Sat, 23 Nov 91 13:15:29 EST
Date:         Sat, 23 Nov 1991 13:07:10 EST
Reply-To: Yolin H u a n g <yih%BRL.MIL@uga.cc.uga.edu>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: Yolin H u a n g <yih%BRL.MIL@uga.cc.uga.edu>
Subject:      JIS, GB, Big5, Unicode
Comments: To: ccnet-l@uga.cc.uga.edu
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
Status: RO

ref: ------------------------------------------------------------------
Date:         Tue, 19 Nov 1991 15:26:15 -0500
From:         Stephen G Simpson <simpson%MATH.PSU.EDU@uga.cc.uga.edu>
Subject:      Pinyin input for ETEN.  BIG-5 versus GB.
Comments: To: ccnet-l@uga.cc.uga.edu

I think a lot of people have wondered about GB versus BIG-5 character
codes.  BIG-5 is in a sense much better, because it includes about 13000
characters, compared to about 7000 for GB.  Also, since BIG-5 is keyed to
traditional rather than simplified characters, it is more suitable for
classical Chinese literature and for everyday use in the United States
and indeed most parts of the world, except mainland China.
-----------------------------------------------------------------------

for those who are sentimentally attached to GB, this is probably hard to
swallow, and demoralizing.  But, we can consider 'simplified character'
as a style or font, as so successfully demonstrated by Ben Ao in his
CWP.  Actually, for those educated in traditional way, many people also
write in various simplified styles in everyday routine.  The 'simplified
style' has the merit of facing (and formalizing) this fact from the
grass-root, in a way quite American (cowboy, blue jean, New Orlean Blue).

'Pinyin' is in fact derived (romanized) directly from 'bopomofo' phonetic
system, which was developed around the turn of the century; which again
was developed along the line of Japanese 'kana' phonetic system since
there were many Chinese studying in Japan at the time; and 'kana' was
first developed in Japan during Nara and Heian period by woman folks to
simplify hand writing of the heavy Han writing system from the Continent
prefered by the literati.

Since GB code covers fewer characters, it is sufficient for beginners.
For learned dons, Big5 offers a larger coverage, sometimes necessary for
richness and depth.  For the upcoming Unicode, I would like to see a
coverage no less than Big5's.  Maybe, Unicode can cover all characters in
the celebrated 'Kang Xi Zi Dian' (with some studied corrections), plus
some characters used only regionally such as in Japan and Hong Kong, and
as a superset to Big5, GB, and Japanese JIS; if the OS (Operation System)
can stand it.  If the OS can not handle it, it can be separated in several
subset files depending upon their statistical freqency of usage in each
community, and personal preference.  I think it is unwise to keep
different writing styles in the same code, and each occupying a code
number slot.  Each community can have their own prefered font file for
display and printing.  And one user might consider several fonts for
style and appearance.  For instance, a compendium of celebrated classical
brush writings by famed historical personalities can contain many choices
for a single character.  People may want to print in Yan style (Yan
ZhenQin), or Wang style (Wang XiZhi), or many other styles.

A single format is better than the warring state of Beta and VHS.  A
unified HDTV is better than NTSC, PAL, and SECAM.  I think for
conservative Japanese literati, a superset in the form of a wise and fair
choice of Unicode will be appreciable.

Yolin Huang.

Appendix:
-----------------------------------------------------------------------
From: tozaki@math.keio.ac.jp (Hidekazu TOZAKI)
Subject: Re: Chinese-Japanese kanji
Date: 21 Nov 91 12:08:40 GMT
Organization: Faculty of Sci. and Tech., Keio Univ., Yokohama, Japan.

In article <GARRIGUE.91Nov20140447@prao.ens.ens.fr> garrigue@prao.ens.ens.fr
 (Jacques Garrigue) writes:
 >!   To speak of Chinese kanji may sound as redundant. But introduction of
 >! Chinese ideograms in Japanese has not been done all at once, and some
 >! variations appeared.
 >!
 >!   Up to a 50 years ago they were still very similar, but simplifications
 >! on both sides have made it much more difficult.

 Yes, the following is quoted (with ">&") from what I posted to
comp.std.internat a month or two ago.

###  I wrote it in a hurry and for another purpose, but I have no time    ###
### now to modify it, so please, please ignore the digressive parts, (and ###
### sorry for many grammatical mistakes.)                                 ###

 >&  In 1716 Chinese Emperor ordered some specialists to make Kanji
 >& dictionary, which is named Kouki-Jiten after the name of the Emperor.
 >& (I don't know its chinese pronounciation and spelling, sorry.) This
		    note: I've now learnt its Chinese name "Kang Xi Zidian".
 >& has been used as the standard for long years both in China and Japan.
 >& (Perhaps there are some differences between them but I don't know the
 >& differences in detail.) Almost all kanji dictionaries *now* published
 >& in Japan are listed these characters as "Seiji" (of which direct
						<Zhen Zi>
 >& translation into English is perhaps "correct character".) What we use
 >& in prewar era is now called Kyuuji (Old Character) which is very close
				<Jiu Zi>
 >& to this Seiji. After the War, in 1946, Japanese government established
 >& "Touyou Kanji" system which limits our Kanji usage to 1,850 Kanjis,
 >& and some of the Kanjis in it are simplified its shapes. This is called
 >& Shinji (New Character). But many cultural people didn't accept this
 >& change, continue to use Kyuuji. There are still many books in Japan
 >& printed in this Kyuuji, and cultural people *now* can read/write this
 >& Kyuuji. (Why this Shinji is so disliked is this: all simplified
 >& characters are in that 1,850 sets, so when one write a kanji, if the
 >& kanji is within the set, one must write it in simplified shape, and if
 >& the kanji is without the set, one must write it in old style, even if
 >& they have common parts. This forces us to memorize whether the kanji
 >& one now want to write is within the set or not. This is none other
 >& than the nonsence.) In 1981 "Touyou Kanji" is revised to "Jouyou
 >& Kanji", but there's no big changes of situation.
 >&
 >&  Now, Kyuuji and Shinji are confused by such reasons, some of Japanese
 >& (including me) may prefer Kyuuji for some words; in other words, some
 >& Japanese distinguish Kyuuji and Shinji as a different character;
 >& especially for personal names and place names. It is quite natural
 >& that, if someone (even government) forces one to change his/her name
 >& on behalf of his/her character is Seiji but not the standard (i.e.
 >& Shinji), he/she deny such demand, isn't it? (Even if it is not a
 >& Seiji, if he/she want to use the character, it should never be
 >& prohibited by any kind of power.)
 >&
 >& #  In another word, Japanese government failed to standarized Kanji, so
 >& # there are widely used both Kyuuji and Shinji. I again insist, there do
 >& # exists some people who distingusihed them *consciously*, they must be
 >& # distingusihed.
 >&
 >&  On the other hands, in 1965, China has made Kantaiji (I don't know
 >& its Chinese spelling, sorry) which is also simplified from Seiji, but
 >& *very much* different with Japanese Shinji. Since I have never learned
 >& modern Chinese Language, I cannot read most of the Kantaiji, i.e. I
 >& can't understand which Japanese Character (Whether Shinji or Kyuuji)
 >& corresponds to the Kantaiji. I don't know how the Chinese feel this
 >& Kantaiji.
 >&
 >&  And in Taiwan as far as I know there's no big changes about Kanji,
 >& that means the character which is close to Seiji is used.

>From here I've newly added:

 As for Seiji, there also exist who have another point of view; since
even Kouki Jiten have some (not so few) mistakes, more older kanjis as
in "Setsumon-Kaiji" (I don't know whose chinese name) are correct
  <Shuo Wen Jie Zi>
ones. Some call such kanji's Honji whose direct translation would be
                           <Ben Zi>
"original character". (There are another naming for kanji also, but
here, I follow this situation to the word usage of Seiji and Honji,
i.e. Seiji is Kouki-Jiten style, Honji is Setsumon-Kaiji style
basically.)

 If one decide what is Seiji, another kanjis are regarded as
non-standardor variation, which we call Itaiji. If you know some
					<Yi Ti Zi>
examples for Itaiji, the following book is convenient.

Katsumi YAMADA (ed), Itaiji Kaidoku Jiten
	Kashiwa Shobo, 1987, ISBN 4-7601-0332-5, 1 800 yen

 >!   Even without it, some characters were created in Japan (kokuji), some
 >! of them very frequent. And many Chinese characters are not used in Japan,
 >! mostly for grammatical reasons.

 I also know onw kanji dictionary with only kokuji.

Yoshizo SUGAWARA (ed.), Kokuji no Jiten,
	Tokyodo Shuppan, 1990, ISBN 4-490-10279-8, 2 000 yen

 >!   Maybe the best way to see differences between Chinese and Japanese is
 >! to have a look at a 'kanwa jiten', a dictionary of Chinese character for
 >! Japanese. It explains about the writing, the original meaning (in China)
 >! and its in Japan.

 Usual Japanese Kanwa Jiten dose not include Chinese Kantaiji as an
item, but some list the table of the difference as an appendix. As the
Chinese simplification is regular (in comparison with Japanese ones),
they might probably not list the whole table but some rules to
simplify. But I know one Kanji dictionary meant for beginners for
Japanese (i.e. written in English.)

Jack Halpern et al. (ed.), New Japanese-English Character Dictionary
	 Kenkyusha Ltd., 1990, ISBN 4-7674-9040-5, 8,000 yen

 This kanji dictionary is meant for to read and write Japanese, but
have its Chinese Kantaiji for each kanji. (It has also interesting
systems for searching for kanjis, I think it is more convenient for
foreigners than using Bushu (radical) systems.)

--
Hidekazu TOZAKI
Faculty of Science and Technology, Keio University, Yokohama, Japan.
E-mail: tozaki@nak.math.keio.ac.jp

From CCNET-L@uga.cc.uga.edu Sat Nov 23 23:20:53 1991
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.61/5.10) with SMTP id AA18413; Sat, 23 Nov 91 23:20:45 -0500
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 4275; Sat, 23 Nov 91 23:19:55 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 8903;
 Sat, 23 Nov 91 23:19:54 EST
Date:         Sat, 23 Nov 1991 20:12:47 PST
Reply-To: Val Luck <VALUCK%UCDAVIS.BITNET@uga.cc.uga.edu>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: Val Luck <VALUCK%UCDAVIS.BITNET@uga.cc.uga.edu>
Subject:      cxterm
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
Status: RO

Hello:

I use big5 more than I use GB, and I have been told that there is a way
to use cxterm with BIG5 codes?  (et's BIG5 codes)  Is there a simple
way to do this?  Can the yitian's "box" files be converted into a
.tit file?  Someone told me it was possible, but I forget how, and seemed
to mess things up!

Thanks!!

--Val

From CCNET-L@uga.cc.uga.edu Sun Nov 24 10:37:04 1991
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.61/5.10) with SMTP id AA20438; Sun, 24 Nov 91 10:36:57 -0500
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 4947; Sun, 24 Nov 91 10:16:05 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 4864;
 Sun, 24 Nov 91 10:16:04 EST
Date:         Sun, 24 Nov 1991 10:13:21 -0500
Reply-To: Benjamin Ao <ao-b%CIS.OHIO-STATE.EDU@uga.cc.uga.edu>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: Benjamin Ao <ao-b%CIS.OHIO-STATE.EDU@uga.cc.uga.edu>
Subject:      More =\= Better -- GB or BIG5
Comments: To: ccnet-l@uga.cc.uga.edu
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
Status: RO

	The evaluation of BIG5 versus GB is not a simple one. I think
this should be described in terms of relative, not absolute, merits.

	GB contains fewer characters, and is therefore more likely
to encounter the problem of not including an existing and useful
character. This is defintely its disadvantage. Yet, being a smaller
character set, both the coding table and the font files are smaller
in size. In cases where the memory and the storage are not unlimited,
this is clearly an advantage.

	On the other hand, BIG5 is undoubtedly less likely to have
a character missing problem, being a larger character set. Yet, just
because it's larger, it occupies more memory and storage space, and
therefore does pose a problem for smaller computers.

	A simple arithmetic shows that, ignoring the punctuation
marks and other symbols, the GB set contains 94 x 72 = 6768 (6763
used) characters, and the BIG5 set contains 191 x 84 = 16044 (15875
used) characters. Therefore, a 16x16 GB font is 216.576 KB, but a
16x16 BIG5 font is 513.408 KB; and a 24x24 GB font is 487.296 KB,
but a 24x24 BIG5 font is 1155.168 KB. There is a 296.832 KB difference
in the first case, and a 667.872 KB difference in the second. Consider
cases where more fonts with higher resolution are needed, the
difference in storage requirement between GB and BIG5 will become
greater. These figures may not sound very impressive for people who
are used to computers with almost unlimited memory and storage space,
but for those who have to confine themselves to the limits of small
computers used by private owner and small businesses, these are
serious problems.

	Generally speaking, more is not always better. It all depends
on what most people need most of the time. If we concede that most
people use Chinese word processors to process modern Chinese language
data, then an appropriate character set should contain about the same
number of characters as those used in modern Chinese. According to
a 1985 Chinese character frequency assessment, whose scale is the
largest in history, a total of 7,754 characters appear at least once
in a literature composed of 11,873,453 characters, which was published
in mainland China from 1977 to 1982 covering subjects in natural and
social sciences. Allowing for some variance, 8000 is probably a close
estimate of the number of characters used in modern Chinese. If this
is true, then the 6768 total of GB is definitely closer to this
estimate than the 16044 total of BIG5. In other words, about half of
all the characters defined in BIG5 will probably never be used.

	On the other hand, even BIG5 proves to be too small a character
set if we are going to process pre-modern Chinese texts. Kangxi Zidian
contains 47035 characters, and the largest collection of Chinese
characters appears to be a Chinese-Japanese dictionary called Kanwa
Dai Jiten, which reportedly contains well over 90,000 characters. I
haven't checked out that dictionary and counted the characters in it
myself. But if this report is true, then it's bad bad news for
advocates of UNICODE who believes 65 K is more than enough. The worst
thing about this that one never can tell which of the tens of thousand
pre-modern character may appear in any given pre-modern text, and there
has been no statistics of the frequency of usage of these characters.

	Given the statistical properties of Chinese characters, and to
achieve the maximum cost-effectiveness, I don't think it is wise to
advocate for arbitrarily large character sets. Rather, we should be
content with a basic set which contains somewhere in the neighborhood
of 8000 characters, or maybe simply with a slightly modified GB set
that no longer has the problem of the one-to-many relationship between
simpified and traditional characters, and that includes some regional
characters used in Japan, Hong Kong etc. Additional and pre-modern
characters could be supplies as additional font packages. In other
words, modern and pre-modern characters may share the same code, but
are differentiated with their font names.

	This solution to the Chinese character coding problem may not
be very elegant, but is much more efficient than coding systems that
enclude tens of thousand almost useless archaic characters to engulf
our otherwise valuable and useful memory and storage space.

	Benjamin Ao
	Department of Linguistics
	Ohio State University

From CCNET-L@uga.cc.uga.edu Sun Nov 24 10:53:34 1991
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.61/5.10) with SMTP id AA20550; Sun, 24 Nov 91 10:53:07 -0500
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 4967; Sun, 24 Nov 91 10:52:42 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 5109;
 Sun, 24 Nov 91 10:52:41 EST
Date:         Sun, 24 Nov 1991 10:51:11 -0500
Reply-To: Stephen G Simpson <simpson%MATH.PSU.EDU@uga.cc.uga.edu>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: Stephen G Simpson <simpson%MATH.PSU.EDU@uga.cc.uga.edu>
Subject:      Big-5 in cxterm
Comments: To: Val Luck <valuck%ucdavis.BITNET@psuvax1.cs.psu.edu>,
              ccnet-l@uga.cc.uga.edu
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
In-Reply-To:  <9111240420.AA01049@leibniz.math.psu.edu>
Status: RO

Val Luck writes:
 > I use big5 more than I use GB, and I have been told that there is a way
 > to use cxterm with BIG5 codes?  (et's BIG5 codes)  Is there a simple
 > way to do this?  Can the yitian's "box" files be converted into a
 > .tit file?  Someone told me it was possible, but I forget how, and seemed
 > to mess things up!

Cxterm works fine with BIG-5 codes.  Of course you have to use a BIG-5
font, for instance the HKU BIG-5 font, hku-ch16, which comes with
cxterm.  There are also ET BIG-5 fonts taipei15 and taipei24 (Yi Tian
compatible) which are available elsewhere.  Big-5 input methods for
cxterm are provided by ETZY.tit and PY-b5.tit, which come with cxterm.
The first of these is compatible with ET's Zhu Yin input, while the
second is based on Pin Yin with tones.

I don't think it is possible in general to convert Yi Tian .box files
to .tit files, because .tit files are only appropriate for entering
single characters, not phrases (Ci Hui).  I think .box files are often
used to enter phrases.  But maybe an expert on .box and .tit files should
answer this.

Stephen G. Simpson               simpson@math.psu.edu
Department of Mathematics        +1 814 863-0775
Pennsylvania State University    home: +1 814 238-2274
University Park, PA 16802

From CCNET-L@uga.cc.uga.edu Sun Nov 24 12:27:44 1991
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.61/5.10) with SMTP id AA20974; Sun, 24 Nov 91 12:27:18 -0500
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 5086; Sun, 24 Nov 91 12:26:56 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 6294;
 Sun, 24 Nov 91 12:26:55 EST
Date:         Sun, 24 Nov 1991 12:24:56 -0500
Reply-To: Ya-Gui Wei <yawei%BRONZE.UCS.INDIANA.EDU@uga.cc.uga.edu>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: Ya-Gui Wei <yawei%BRONZE.UCS.INDIANA.EDU@uga.cc.uga.edu>
Subject:      Re:  More =\= Better -- GB or BIG5
Comments: To: ao-b%CIS.OHIO-STATE.EDU@uga.cc.uga.edu
Comments: cc: ccnet-l@uga.cc.uga.edu
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
Status: RO

Benjamin,

I agree with you whole heartedly. Increasing the size of the
code table is not a solution for solving the rare character
problem. But rather, the solution should be to define a set
of character construction rules.

Neither the ASCII table nor the English keyboard layout pretends
to include all the symbols that might appear in a piece of
English text. The solution is left to the individual text
processing softwares. This is where software packages like Latex
comes in.

I posted a proposal to CCNET not long ago about the character
construction rules. Perhaps it is somewhat crude and far from
complete - I was only meaning to illustrate a principle.  Note
that one does not neccessary need a set of infinitely scalable
fonts to serve certain construction rules - bitmap fonts can
be shrunk with respectable results.

  Ya-Gui Wei

From CCNET-L@uga.cc.uga.edu Sun Nov 24 14:01:57 1991
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.61/5.10) with SMTP id AA21481; Sun, 24 Nov 91 14:01:30 -0500
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 5196; Sun, 24 Nov 91 14:01:13 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 7656;
 Sun, 24 Nov 91 14:01:12 EST
Date:         Sun, 24 Nov 1991 13:58:46 -0500
Reply-To: Stephen G Simpson <simpson%MATH.PSU.EDU@uga.cc.uga.edu>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: Stephen G Simpson <simpson%MATH.PSU.EDU@uga.cc.uga.edu>
Subject:      GB versus BIG-5
Comments: To: ccnet-l@uga.cc.uga.edu, zhongwen@nada.kth.se,
              chpoem-l%ubvm.BITNET@psuvax1.cs.psu.edu
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
Status: RO

In an earlier CCNET posting, I wrote:

 > I think a lot of people have wondered about GB versus BIG-5 character
 > codes.  BIG-5 is in a sense much better, because it includes about 13000
 > characters, compared to about 7000 for GB.  Also, since BIG-5 is keyed to
 > traditional rather than simplified characters, it is more suitable for
 > classical Chinese literature and for everyday use in the United States
 > and indeed most parts of the world, except mainland China.

Perhaps I was being overly enthusiastic here, and I certainly didn't
mean to start a debate.  (My enthusiasm was triggered by Carlos
McEvilly's kindness in providing a Pin Yin BIG-5 input method for Yi
Tian word processor.)

I don't want to get into a political or "religious" discussion, but
there may be some value in a further clarification of the issues.

The choice of GB versus BIG-5 depends on a lot of factors, including:

    1. intended application

    2. software availability

    3. disk space and memory availability

    4. personal preference

    5. politics

Factors (2) and (3) are becoming less important as time goes on.
Software, cheap disk space, and cheap memory are becoming more and
more available.  Moreover, if you want to use BIG-5 but have a severe
disk space or memory problem, you can always use the stripped down
version of BIG-5, containing only the 5401 most frequently used
characters.  This is adequate for everyday business or scientific use.
Therefore, I think factors (2) and (3) are not decisive.

Because of the nature of this list, I won't comment on factors (4) and
(5), politics and "religion".

I think that the most important factor is (1), intended application.

Benjamin Ao <ao-b.cis.ohio-state.edu> posted some thoughtful arguments
in favor of GB codes and a smaller character set.  I agree with
Benjamin that more is not necessarily better.  If the GB character set
contains all the characters you need for your intended application,
then there is no reason to switch to BIG-5.

However, I think BIG-5 is more suitable for many applications.

The main problem is that GB-2312 simply does not have codes for many
commonly used characters.  An example is Mian4 ("wheat") as in Mian4
Bao4 ("bread").  GB users have to substitute Mian4 ("face") in this
context.  This substitution is acceptable in mainland China, but it is
not acceptable in, for instance, Chinese newspapers published in the
United States.

In addition, GB does not have codes for a great number of uncommon but
occasionally useful characters.  For example, a couple of weeks ago, a
colleague from the mainland told me that her given name was a very
rare character that could not be found in any dictionary or
typesetting system.  The character in question did not exist in GB,
but I easily found it in the second part of the BIG-5 table.  (The ET
BIG-5 hex code is F2C9.)

Finally, if one wants to publish a document in both traditional and
simplified characters, BIG-5 would seem to be the better choice.  This
is because the mapping from traditional characters to simplified
characters is many-to-one, so automatic BIG-5 to GB conversion is at
least possible in principle, while the opposite sometimes presents
severe difficulties (see for instance Ned Walsh's recent complaints on
the Chpoem list).

If there is a version of GB that addresses these problems, I would
like to learn about it.

Benjamin pointed out the following:

 > According to a 1985 Chinese character frequency assessment, whose
 > scale is the largest in history, a total of 7,754 characters appear at
 > least once in a literature composed of 11,873,453 characters, which
 > was published in mainland China from 1977 to 1982 covering subjects in
 > natural and social sciences.

At best this means that GB may be suitable for natural and social
sciences publishing in mainland China.  What about natural and social
sciences in the rest of the world?  What about newspapers?  Perhaps
most significantly, what about literature, poetry, and scholarship in
other fields?  Judging from recent postings on the Zhongwen and Chpoem
lists, European and American and even mainland Chinese scholars in
Chinese literature can't use GB-2312, because GB-2312 lacks a lot of
characters that they need.  It appears that most of the Europeans and
Americans use BIG-5.  I don't know what the mainlanders do.

 > Allowing for some variance, 8000 is
 > probably a close estimate of the number of characters used in modern
 > Chinese.

I don't think the study justifies this conclusion about modern Chinese
as a whole.  As Benjamin pointed out, the study was restricted to
natural and social science publications on mainland China.  And even
in that restricted domain, it may be that the mainland scientists
would have liked to use certain characters, or even do use them in
handwritten notes, but were prevented from using them in publications,
because of the lack of suitable software.

 > In other words,
 > about half of all the characters defined in BIG5 will probably never
 > be used.

This conclusion seems completely unjustified.  For example, if your
name happens to be one of the many characters (common or rare) that
are missing from the GB character set, then you will not be able to
typeset it using GB software, but you will use it nevertheless.

Benjamin went on to discuss other coding schemes, including Unicode
and a hypothetical scheme involving a modified GB with 8000
characters, presumably including all of the common characters that are
missing from GB-2312.  These proposals are interesting, and more
information would be welcome.

Stephen G. Simpson               simpson@math.psu.edu
Department of Mathematics        +1 814 863-0775
Pennsylvania State University    home: +1 814 238-2274
University Park, PA 16802

From CCNET-L@uga.cc.uga.edu Sun Nov 24 14:16:46 1991
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.61/5.10) with SMTP id AA21756; Sun, 24 Nov 91 14:16:27 -0500
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 5244; Sun, 24 Nov 91 14:16:06 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 8015;
 Sun, 24 Nov 91 14:16:01 EST
Date:         Sun, 24 Nov 1991 14:14:08 -0500
Reply-To: Stephen G Simpson <simpson%MATH.PSU.EDU@uga.cc.uga.edu>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: Stephen G Simpson <simpson%MATH.PSU.EDU@uga.cc.uga.edu>
Subject:      character construction rules
Comments: To: Ya-Gui Wei <yawei@bronze.ucs.indiana.edu>, ccnet-l@uga.cc.uga.edu
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
In-Reply-To:  <9111241727.AA01561@leibniz.math.psu.edu>
Status: RO

Ya-Gui Wei writes:
 >
 > Increasing the size of the
 > code table is not a solution for solving the rare character
 > problem. But rather, the solution should be to define a set
 > of character construction rules.
 >
 > ...
 >
 > I posted a proposal to CCNET not long ago about the character
 > construction rules. Perhaps it is somewhat crude and far from
 > complete - I was only meaning to illustrate a principle.  Note
 > that one does not neccessary need a set of infinitely scalable
 > fonts to serve certain construction rules - bitmap fonts can
 > be shrunk with respectable results.

Yes, this proposal is very interesting indeed.  By the way, have you
seen Don Hosek's article in the TeX newsletter, Tugboat, about
Metafont for Chinese characters?  (Sometime in 1989, I can get you the
exact reference tomorrow if you are interested.) Hosek is a Metafont
guru and has done a lot of development work on this particular
project.  His system also involves abstract Chinese character
construction rules.  I am hoping that Hosek is successful, because it
should result in a free or inexpensive set of outline fonts.

Stephen G. Simpson               simpson@math.psu.edu
Department of Mathematics        +1 814 863-0775
Pennsylvania State University    home: +1 814 238-2274
University Park, PA 16802

From CCNET-L@uga.cc.uga.edu Sun Nov 24 14:38:15 1991
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.61/5.10) with SMTP id AA22071; Sun, 24 Nov 91 14:38:00 -0500
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 5269; Sun, 24 Nov 91 14:37:34 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 8278;
 Sun, 24 Nov 91 14:37:33 EST
Date:         Sun, 24 Nov 1991 14:35:00 EST
Reply-To: Dorothy Day <DAY%IUBACS.BITNET@uga.cc.uga.edu>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: Dorothy Day <DAY%IUBACS.BITNET@uga.cc.uga.edu>
Subject:      Big 5 and scholarly usage
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
Status: RO

Recent postings have pointed out that suitability of the size and
selection of the character database of a textprocessing system depends
heavily on the uses to which it is put. Thus, daily business needs
(such as letter-writing) can often be met even by the numerous
electronic typewriters with extremely limited character availability
produced in Taiwan, Japan, and mainland China.

However, traditional literature, history, and other scholarly areas
require a much larger character base. This need not be "every
character in the Dai Kanwa Jiten (ca. 90,000)"; a well-selected
character set could be far smaller and still meet 99.44% of one's
needs. China Star's character generator ROM card contains something
over 40,000 traditional and 20,000 simplified characters; in several
years working with traditional Chinese fiction (probably the richest,
or at least largest, vocabulary in all the literature), I have had to
customize maybe five obscure characters that could not be pulled off
the ROM card.

For a long time I felt that systems that did not provide at least this
large a character base were unsuitable for working is traditional
areas of scholarship. This meant that TianMa (whose character base is
taken from the set in Xinhua Zidian) would be unsuitable, even though
its character input is superior to any other except the Xerox Star
system. Both use contextual analysis to select the correct characters
for phrases typed in.

I'm beginning to suspect that the selection in the Xinhua Zidian has
been done with sufficient care that 98-99% of the characters in any
given document will still be found in the character base. In a word
processor, having to customize the creation of one character per
document is a nuisance but not a hardship, if the character creation
software is sufficiently friendly. This, TianMa may abe more adequate
than I had supposed.

In a character encoding system like Unicode, much closer to universal
coverage is essential for electronic transmission. However, that still
does not have to mean "every character in the Dai Kanwa Jiten." A
substantial number of the occurances in that dictionary have been
determined to have occurred in perhaps only one or two source
documents, where a clerk made a copying error. An error that is picked
up and repeated becomes part of the written language, but isolated
errors do not make for separate characters. The committees working on
Unicode have been able to eliminate a substantial number of these
isolated erroneous forms. If need be, they can be put in separate
subsets defined by user groups; this is how Unicode will handle many
EXTREMELY rare characters from the world's languages, and space for
"special subsets" will be reserved in the code, to be enabled by the
appropriate set tag.

BTW, has anyone on this list tried Xin TianMa, which is now entirely
hard-disk based (but with a hardware "key" on the parallel port)? I
know it's been released, but haven't spoken with anyone who has used
it.

Dorothy Day, Indiana University
DAY@IUBACS or day@ucs.indiana.edu

From CCNET-L@uga.cc.uga.edu Sun Nov 24 15:36:24 1991
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.61/5.10) with SMTP id AA22323; Sun, 24 Nov 91 15:35:58 -0500
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 5433; Sun, 24 Nov 91 15:35:30 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 9493;
 Sun, 24 Nov 91 15:35:29 EST
Date:         Sun, 24 Nov 1991 15:32:46 -0500
Reply-To: Stephen G Simpson <simpson%MATH.PSU.EDU@uga.cc.uga.edu>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: Stephen G Simpson <simpson%MATH.PSU.EDU@uga.cc.uga.edu>
Subject:      correction
Comments: To: ccnet-l@uga.cc.uga.edu, zhongwen@nada.kth.se,
              chpoem-l%ubvm.BITNET@psuvax1.cs.psu.edu
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
Status: RO

 > commonly used characters.  An example is Mian4 ("wheat") as in
 > Mian4 Bao4 ("bread").  GB users have to substitute Mian4 ("face")
 > in this context.  This substitution is acceptable in mainland
 > China, but it is

Sorry, "wheat" should be "flour" and Mian4 Bao4 should be Mian4 Bao1.

From CCNET-L@uga.cc.uga.edu Tue Dec  3 14:39:09 1991
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.61/5.10) with SMTP id AA04375; Tue, 3 Dec 91 14:38:56 -0500
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 3597; Tue, 03 Dec 91 14:38:23 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 1921;
 Tue, 03 Dec 91 14:38:14 EST
Date:         Tue, 3 Dec 1991 13:34:33 CST
Reply-To: Jianxun Ding <jding%CS.TAMU.EDU@uga.cc.uga.edu>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: Jianxun Ding <jding%CS.TAMU.EDU@uga.cc.uga.edu>
Subject:      Re: GB and BIG5
Comments: To: Stephen G Simpson <simpson@math.psu.edu>
Comments: cc: ccnet-l@uga.cc.uga.edu
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
In-Reply-To:  <9111251957.AA27910@boole.math.psu.edu>; from "Stephen G Simpson"
              at Nov 25, 91 2:57 pm
Status: RO

> Wow!  That is really interesting.  I'm generally surprised.  Live and
> learn.  Where can I find out more or get a font for GB xxxx?  Is there
> a public domain font, like the CCLIB fonts for GB-2312?  Is there any
> software for GB xxxx?

Stephon, as I promised you,  I will try to dig out more information.
The following is a message I just received.  I will keep you informed.

Note the <<Computer World>> is the Chinese version.

--Jianxun Ding


-------------------Enclosed Message----------------------------------------
To: jding@cs.tamu.edu
Status: OR

......

This is the answer:
    1. There is a GB-xxxx, which is the extended standard of GB-2312.
    2. The standard may have not been published openly.
    3. You may have further information by reading <<Computer World>>
       (Ji Suan Ji Shi Jie) around Sep. or Oct. if you can.
    4. If it is published, it is available in large bookstore on 'standard
       shelf' in Beijing. I think it is also available in Shanghai.
    5. I have no <<Computer World>> here.  I will do further
       investigation. if I have any finding, I will tell you.
......

xxx-xxxx
Dec.3
----------------------------------------------------------------------------

From CCNET-L@uga.cc.uga.edu Wed Dec  4 17:57:01 1991
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.61/5.10) with SMTP id AA13972; Wed, 4 Dec 91 17:56:33 -0500
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 4896; Wed, 04 Dec 91 17:55:58 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 3107;
 Wed, 04 Dec 91 17:54:46 EST
Date:         Wed, 4 Dec 1991 16:50:41 CST
Reply-To: Jianxun Ding <jding%CS.TAMU.EDU@uga.cc.uga.edu>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: Jianxun Ding <jding%CS.TAMU.EDU@uga.cc.uga.edu>
Subject:      Re: GB and BIG5
Comments: To: Stephen G Simpson <simpson@math.psu.edu>
Comments: cc: ccnet-l@uga.cc.uga.edu
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
In-Reply-To:  <9111251957.AA27910@boole.math.psu.edu>; from "Stephen G Simpson"
              at Nov 25, 91 2:57 pm
Status: RO

> Wow!  That is really interesting.  I'm generally surprised.  Live and
> learn.  Where can I find out more or get a font for GB xxxx?  Is there
> a public domain font, like the CCLIB fonts for GB-2312?  Is there any
> software for GB xxxx?
>

  Someone just told me that that GB-xxxx is GB12345-90;  and the
  <<Computer World>> Chinese edition had an ad "selling the HANZI
  character libarary which contains all the characters published
  in GB2312-80 and GB12345-90".

  I am trying to get the office address of <<Computer World>> Chinese
  edition.   I heard that the newspaper is a Sino-US joint venture.

  --Jianxun Ding

From CCNET-L@uga.cc.uga.edu Sat Nov 23 23:05:44 1991
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.61/5.10) with SMTP id AA18380; Sat, 23 Nov 91 23:05:29 -0500
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 4266; Sat, 23 Nov 91 23:05:02 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 8743;
 Sat, 23 Nov 91 23:05:01 EST
Date:         Sat, 23 Nov 1991 23:03:25 -0500
Reply-To: Ya-Gui Wei <yawei%BRONZE.UCS.INDIANA.EDU@uga.cc.uga.edu>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: Ya-Gui Wei <yawei%BRONZE.UCS.INDIANA.EDU@uga.cc.uga.edu>
Subject:      Re: phrase input in emacs
Comments: To: ccnet-l@uga.cc.uga.edu
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
Status: RO

Yu Shen,

  "zW" was not good at mixing Chinese and ASCII text in the
same line. I don't know how any software can properly decode
your "zW" message the way you intermix ASCII codes in.

  One way to include ASCII codes is to convert them to the
GB representation of ASCII codes by inserting a # sign in
front of each of them.

  An alternative way, which I used in "ZWCCV", is to escape
each ASCII code with a space character, s u c h   a s  t h i s.
ZWCCV, and the zwencode/decode (from/to CCDOS GB) programs
I placed in ahkcus.org were equiped to deal with the space-
escaped ASCII characters.

  Ya-Gui Wei
zWN:QG9p

From CCNET-L@uga.cc.uga.edu Sat Dec 14 18:59:21 1991
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.61/5.10) with SMTP id AA14156; Sat, 14 Dec 91 18:59:05 -0500
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 1600; Sat, 14 Dec 91 18:58:25 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 8134;
 Sat, 14 Dec 91 18:58:23 EST
Date:         Sat, 14 Dec 1991 15:56:00 PST
Reply-To: Xincun Huang <IZZYKD3%UCLAMVS.BITNET@uga.cc.uga.edu>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: Xincun Huang <IZZYKD3%UCLAMVS.BITNET@uga.cc.uga.edu>
Subject:      Retaining Word and Nisus formatting in HC 1.5 TAI-CHI conversion
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
Status: RO

> * HanziConverter 1.5 converts all TEXT files between JianTi and
>FanTi. I use Word to save the file into TEXT ONLY format, convert it,
>and then open and redo the layout. It's "bearable", not bad.

This is exactly the problem for which I was trying to find an
alternative.

If you have a research paper, with hundreds of footnotes, with fonts,
rulers, style sheets, contents, indexing, cross-indexing, etc., then it
is probably easier to retype the Chinese than to reformat the entire
paper.  Or one could save the file as text only, convert, and cut and
paste each selection of Chinese text.

What I was suggesting is that one can use HC 1.5 to change between
TAI and CHI and *retain all the original formatting* by writing a
short Pascal program that removes the text from a MS Word
document file.  The Nisus GREP/macro/push/pop combination offers
a nicer solution with the result that approaches "conversion" of the
file.

However, none of the above solutions approach the ideal that a
formatted high-level word processing document (Nisus or Word) be
convertible as transparently as TEXT ONLY files are.


Thanks to all those who suggested how to combine Mac systems:  it
seems to work very well.

Does anyone know anything about font prices, and whether there are
outline fonts?

Roger Hart
UCLA

From CCNET-L@uga.cc.uga.edu Sun Dec 15 23:11:08 1991
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.61/5.10) with SMTP id AA21867; Sun, 15 Dec 91 23:10:52 -0500
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 4416; Sun, 15 Dec 91 23:10:09 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 9233;
 Sun, 15 Dec 91 23:10:08 EST
Date:         Sun, 15 Dec 1991 23:04:33 EST
Reply-To: Yolin H u a n g <yih%BRL.MIL@uga.cc.uga.edu>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: Yolin H u a n g <yih%BRL.MIL@uga.cc.uga.edu>
Subject:      simplification; PinYin; GB
Comments: To: ccnet-l@uga.cc.uga.edu
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
Status: RO

Re:------------------------------------------------------------------
: "Minghui Yao, Dept of Physics, ASU"
: <YAOM%ASUCP1.LA.ASU.EDU@uga.cc.uga.edu> 25 Nov 1991
: ... The evolution of Chinese Characters is a nature simplifying process,
: from complex to simplicity. If a language is unchanged, it is dead.  ...
--------------------------------------------------------------------------

among these dead scripts?: 1) the modern generations of the European
North Sea and Baltic Sea countries can not understand the old Runic
oracle script (Hellenistic/Cyrillic remnants?) after it was replaced by
the Roman script.  2) the modern generations of the Middle East can not
understand the old Egyptian, Philistian, Phoenician, Aramaic, Syriac,
Akkadian, Babylonian, Chaldean, Sumerian, Old Persian, some Turkic, ...
etc scripts; after those scripts evolved and merged into the modern
Arabic, the new lingua franca.  3) new generations of Tannu Tuva (Dr
Feynman's hobby), the Buryat and the Rep Mongol have difficulties to
understand the traditional Mongolian texts, after the Cyrillic alphabet
was enforced.  4) new generations of VietNam can no longer understand the
bulk of historical archives in Han script, after the French style
spelling was enforced. Many people don't even know of their existence
(probably stored mostly in France as archaeological and anthropological
novelty or vanity?)  5) new generations of Korea have difficulties to
understand the bulk of historical archives in Han script (many highly
achieved scholarship), after the phonetic system set in by decree, so as
to refrain from the Han script implied Chinese chauvinism.

Today, after centuries of evolution, English and French spellings have
lost some of their original phonetic purpose, and have become more or
less ideographical ('ped xing'.)  Maybe one day, after Han Solo and Luke
Skywalker graduated into nirvana, the ASCII script would merge with other
ideographical into an yet unknown new script.:)  But right now, both
groups are cautious to take any measure so as not to deliver the Oxford
and Larousse dictionaries into reincarnation.

Contrary to the assertion, the same Han script has been in use, and
stabilized for almost two milleniums without much change.  Different
fancy writing styles have been artfully painted.  But, there was no
significant gradual simplification of this script in the past as
asserted, other than in the hand-writing routine for convenience.  The
Beijing simplification regulation in the 60's, fueled along the craze of
the Cultural Revolution, can probably better be called an 'experiment'
among other 'social experiments'.

Furthermore, the simplification regulation was not a Beijing innovation
either.  The similar regulation in Japan (same idea, not copyrighted)
predated the Beijing regulation by a couple of years, under the post-war
General McArthur Administration.  At that time, the simplification rule
did have some edge over the slower traditional style, in hand-writing
(saved some brain-hemorrhage cases on desk scribe work.)  But with the
advance of PC, this edge dimishes.  For the electronic text processing,
it poses probably more problem than advantage.

Three decades passed.  It is now probably high time to sit down, and
ponder about its worth, run a decent re-evaluation, and learn from the
experience.  I think, for the pupils learning the traditional style
first, and then (say after the elementary school build-up stage) allowed
to use simplified shorthand (as supplement) in taking notes, writing
reports or exams would be better off as a whole; than learning the
simplified style first, and later randomly picking up the traditional
style in the real life (in unscathed family memorabilia, libraries,
museums, parks, exhibitions, memorials, movies, karaoke clubs, etc.)
Doesn't have to go back to the old Confucian-style rigid perfectionism
(in hand-writing tedium), if you will.  In English dominions, Gregg's
shorthand system is widely used to speed up the hand-writing.  But it is
usually not a part of the regular education, as I understand.  And many
people, even secretaries, don't write with calligraphical excellence,
some just stay at the grade school level I guess.  When typed up, not
even the boss would notice.

	-------------------- <o> --------------------

The 'PinYin' system (Beijing, 1950's) is better than 'bopomofo'
(Nanking/Nanjing, 1910's) in that it is readily adaptable to the QWERTY
keyboard everywhere on Earth/Space.  (And also better than the Wade-Giles
system [Cambridge UK, 1850's/1910's], because of a better phonetic
representation, and the abstinence from the excessive apostrophe, ...
among other things.)  But it is not without its pitfalls.  Since 'PinYin'
was romanized from 'bopomofo', it retains some syllabic nature as that in
the bopomofo, and kana.  Despite of the alphabetical appearance, it
doesn't have all the phonetic resolution of an ideal alphabetical
system.  Such as in 'x', 's', and 'q', 'c', (each has a corresponding
symbol in bopomofo), which are usually quite a hurdle to the
uninitiated.  I suppose, it would make better sense for 'x', and 's' to
use the same openning consonant followed by different vowels (for
instance, one sharp (sii) one muted (si)).  Same for the 'q' and 'c' (for
instance, one sharp (cii) one muted (ci); suppose there is probably no
better choice than 'c' other than 'ts').  (And in combinations, some of
the 'sii' can be reduced to 'si' without causing confusions; same for
'tsii', and 'tsi'.  Isn't SiaoPing as clear as SiiaoPing, even though not
as short.)  (QuYuan isn't really that royal as Queen.  Isn't 'Tsisii'
easier for the uninitiated than 'Cixi'?  Not Tootsie; 'Tsaotsao' easier
than 'Caocao'?  No cacao today; 'Siishi' better than 'Xishi'?  Not
exactly Sushi bar. :-) ) In so doing, the 'c', 'q', and 'x' could be
replaced by the less offending 'ts', and 's'; and easier acceptable to
the commoners, ignorant mass, and innocents abroad.

I think the Beijing tongue of Han pronunciation (Portugese mistakingly
called Mandarim) probably have seven vowels ( (x)i, (s)i, e, a, o, u, and
umlaut u), not counting diphtongs.)  For the umlaut u sound, some write
'u" (Umlaut)', some people use 'uu'. ('uu' probably better.  Probably
'ui', 'u:', 'u^' can also be considered.  But it seems there is no easier
solution with the popular QWERTY keyboard.  The current use of 'ui' would
probably be more accurately represented by 'uei'.)

Furthermore, the 'an' in the following (mostly diphtongs)
(group 1:)
bian, dian, jian, juan, lian, mian, nian, pian, qian, quan, tian, xian,
xuan, yan, yuan
\
is pronounced differently from the 'an' in the following
(group 2:)
chuan, chuang, cuan, duan, guan, guang, huan, huang, jiang, kan, kang,
kuan, kuang, liang, luan, nan, nang, niang, nuan, pan, pang, qiang, ruan,
san, sang, shan, shang, tuan, yang, ShaanXi, XiAn
\
but closer to the 'en' in the following
(group 3:)
feng, gen, geng, hen, heng, ken, keng, leng, men, meng, nen, neng, pen,
peng, ren, reng, sen, seng

Does the emperor have a new dress on?  This pattern again betrays its
root in the syllabic bopomofo system, where 'an' has a (phonetic)
symbol.  Probably the 'an' in the group 1 could be modified, and further
evolve to 'en' as in group 3.  (The rest of PinYin is probably as good as
new?  What do you think?)  After that, the 'an' will be consistent
throught out, and easier to teach to kids.  And the PinYin system will be
closer to a full-fledged alphabetical system.  One flintstone two birds.

Responsible administrators (of all ideological pre-destinations) probably
should please look closer into this, and try out in some language labs,
experimental schools, or better educated townships, (HongKong, TaiWan?)
for a few years.  A short pain (in making improvements) would be better
than chronic pain (in accomodating the flaws for the next ?? years?)

There is another practice in mainland I couldn't understand: many
merchandise and signs use the 'PinYin' stand-alone, as-is; as if people
could understand them.  I suspect most tourists would first have to
struggle for a good pronunciation, let alone its meaning.  The native
speakers probably won't even bother to look at them, simply don't give a
damn.  I think 'PinYin' is better used only as a pronunciation aid:
small print next to the Han script, like with 'kana'.  But after all,
'PinYin' is probably lesser a problem than the simplication regulation.

	-------------------- <o> --------------------

ygz%CS.PURDUE.EDU@uga.cc.uga.edu (27 Nov 1991) (cxterm, great job) gave
an impressive report about the status quo of the GB scheme, with
revelatory discussions about problems with GL, GR planes in Big5.  The
problem described with the Big5 is probably related to the present 7-bit
environment, which was originally designed only to handle the ASCII
characters.  (The Europeans complain about the ASCII as well, even though
got more out of it.)  But, according to Jianxun Ding (jding@CS.TAMU.EDU,
14 Feb 91) GB 0-3 also use the high bit; so the full-blown GB scheme
(like the one in LianXian Han Ka system used by AG02005@MVS.UNI-C.DK, 28
Nov 1991) might have the same problem?

Now, with the maturing in the technology (and in the humanity, such as
the New Age), and the necessity to handle texts other than Latin
derivatives, the hardware and software developers are expanding their
horizon.  I guess that the OS is moving toward 8-bit and beyond.  So, the
mission impossible today with the old 7-bit ISO 2022, will probably become
possible with the new ISO standards.  It was said that in a Confucian
style top-down bureaucracy, obedience|revolution is usually the norm;
whereas in democracy the rules will respond to the need of the
constituents, ... in theory anyway.  The expanded bandwidth can also
treat other problems in communication, not just Han scripts.

In the current GB 0-5 arrangement, simplified and traditional characters
seem to have different code numbers.  So, the programmers have to build a
conversion procedure into the software, and exercise contextual analysis
to sort out the 1:n mapping pain with a sufficient phrase database
(Dorothy Day DAY@IUBACS.BITNET, 24 Nov 1991; AG02005@MVS.UNI-C.DK, 28 Nov
1991.)  The overhead is expensive.  I think it is probably not a good
arrangement.  Why should a proper name, printed differently in mainland,
ChoSun, HanKuk, HongKong, JaPan, TaiWan, and elsewhere, have different
pointers?  Don't they in fact mean the same, whether it is in Time-Roman,
Helvetica, or Gothic|Fraktur?  Too complicated.  It is here, I suppose,
that some decent simplification will be helpful.  (Improved efficiency
can improve the economy, i.e. money.)  Therefore, the current GB is
probably not much better than Big5, and is probably a flaky foundation to
build upon for long-term textual database effort.  (Notwithstanding,
cxterm, byx, cwp, njstar, cedit ...  are respectful endeavors.)

IMHO, it would make much better sense to start off with a larger, more
complete generic character set ('logic OR' of all styles; no matter how
written), with considerations to regional sets (JaPan, HongKong etc.),
and then lay out the simplified character set over it (with hundred some
holes), statistically sorted into subsets, and make sure to use the same
code number for the same character for all styles, (in PinYin first,
radical second, stroke count third sequence.)  And then use a background
selector to select fonts (like in DOS Word Perfect, or other Window
softwares.)  In Mcintosh I remember there is even a 'blackmail ASCII
font' for the reckless types.

Then, the user can write many different styles of Han script in the same
text.  For instance, the reporters can write a text, and use the mouse to
mark those personal and locality names into Kanji style in five seconds.
The users (cadre, non bourgeois?) have the freedom to choose the
simplified style (as for 1:n simplified characters, there will be fewer
listed for PinYin choice.)  For some (learned dons, nouveau riche?)
aspiring to stay ahead of the vulgarity, they should have the freedom,
without coercion or harassment, to use other styles.  (The 'blackmail
font' is not suggested.:)

And it can readily be expanded to cover classical script styles, such as
the JiaGuWen (Shell|Bone Oracle script?), ZongDingWen (Bronze Vessel
script?), XiaoZuan, DaZuan, LiShu, etc., and hundreds other brush writing
styles, with minimal effort.  (probably with a lot of holes in the
arrays/subsets as well.)  And it can be readily expanded to handle
different bitmap fonts and Postscript fonts in the future.  Other
languages as well.

With the present demographical distribution, the (Imperium) Han culture
probably better be considered a common heritage to CJK countries plus
Japanese produce growers, Korean grocers, and Chinese carry-outs here and
there, plus Sino philos, enthusiasts.  Anyhow, it's a minority culture on
Earth, with a size less than the Latin derivatives.  As long as the
stability and the self-esteem are not compromised, less chauvinism/
feudalism is probably more constructive.  (Actually, 'Chinese' is more
geographical than ethnic.)

Furthermore, for a mutli-cultural society, supposedly the GB space should
be used, IMHO, to cover other 50+ scripts under the mainland
administration, such as Korean, Manzu, Mongol, Uigur, Tibetan, Yi,
Zhuang, Dai, ... etc.  (some extra-territorial negotiations needed) So
one day, major cultural archives can all be digitized, cross referenced,
and index searched, not only over the time (historical correlations), but
over the space (inter-communal correlations) as well; and start to
demonstrate the usefulness, in solving mystries (what is Li Bai's
original Turkic name?), clearing myths (Shangrila where?), finding
origins of words or expressions (many of foggy regional, peripheral, or
external origin), studying the evolution and migration of dialect groups,
...  etc.  (I wonder how Bernhard Karlgren did this without PC; kicked
off by Sven Hedin?)

The electronic Han text processing is still immature and evolving.  But,
the June Fourth has passed only two years.  I am not sure whether the
present climate is ready for this quibble yet.  However, long hesitation
is probably not good either.  Some people are not as patient.  I like to
see discussions (from linguistic perspective), so that it can evolve
further for the better.

Probably I blow a different tune in this open forum.  But, no blasphemy
or counter-revolution was intended.  Only like to see that the mainland
language policy, as a whole, would move in a better direction, and be more
efficient for every endusers (kind of the copylefted GNU spirit); for
everybody has to survive the ISO.  So then, there is a better foundation
toward the next century.  A good foundation is very important, as I was
told.  It is not an easy job; but probably not much harder than moving
the American measure toward decimal, I guess.  After five hundred years,
Cristoforo Colombo has barely reached Cathay.  I appreciate the progress
the ASCII has brought to the Han text processing.

Happy Holidays.  Now, your turn, please.
(step down the soap box, go get some drink)

============================================================================
Mao: (straight, right arm half raised, stern) Rebel with Cause!
James Dean:             ..... (casual, smile) ..... hn? ..........
Lin Yutang: ... Chinese ... is R4D1H3S3.
Chewbacca: (hoarse) ... R2D2 !! ... hhhrrrrr ... hhhrrr .....
(by the distant Valhalla commune,
a Maitreya/MiLeFo type:) ..... HoHoHo! ..... HoHoHo! .....



Appendix:
-----------------------------------------------------------------------------
From: henstock@ec.ecn.purdue.edu (Peter V Henstock)
Newsgroups: sci.lang.japan
Subject: JIS <-> Guo Bao Cross referencing
Date: 8 Dec 91 19:48:32 GMT

I have been following the threads of Japanese kanji and Chinese hanzi
comparisons.  Does anyone know of a list which cross references the
kanji and hanzi?  There are several standards of codes for both the
kanji and hanzi and many of the characters are used in both languages
though some simplifications have occurred in both languages.  I realize
that there may not be a 1:1 correspondence for all characters, but has
such a correspondence been made?

Thanks in advance,

--Peter
.
-----------------------------------------------------------------------------

From CCNET-L@uga.cc.uga.edu Tue Dec 17 06:52:34 1991
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.61/5.10) with SMTP id AA04291; Tue, 17 Dec 91 06:52:27 -0500
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 3577; Tue, 17 Dec 91 06:30:44 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 0012;
 Tue, 17 Dec 91 06:30:43 EST
Date:         Tue, 17 Dec 1991 05:03:48 CST
Reply-To: Jianxun Ding <jding%CS.TAMU.EDU@uga.cc.uga.edu>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: Jianxun Ding <jding%CS.TAMU.EDU@uga.cc.uga.edu>
Subject:      Re: GB and Big5
Comments: To: ccnet-l@uga.cc.uga.edu
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
Status: RO

The following is a paragraph extracted from ISO/IEC DIS10646 (1991)
which tries to define an encoding for all characters on the world.
Hope this paragraph provides some information.

        The Chinese national body is in the process of revising
        and consolidating its national standards.  It is expected
        that the new Chinese standard will be completed by the
        time of IS pulibcation.  It will be identified in this
        clause.  This standard will include all the characters
        from GB 2312, GB 12345, GB 7589, GB 7590, GB 8569 and
        CNS 11645.

--Jianxun Ding

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 Tue Dec 24 11:54:46 1991
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.61/5.10) with SMTP id AA27602; Tue, 24 Dec 91 11:54:33 -0500
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 3572; Tue, 24 Dec 91 11:32:48 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 0175;
 Tue, 24 Dec 91 11:32:47 EST
Date:         Tue, 24 Dec 1991 11:30:28 -0500
Reply-To: Ya-Gui Wei <yawei%BRONZE.UCS.INDIANA.EDU@uga.cc.uga.edu>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: Ya-Gui Wei <yawei%BRONZE.UCS.INDIANA.EDU@uga.cc.uga.edu>
Subject:      Re:  End-of-line problem and transmission format
Comments: To: ccnet-l@uga.cc.uga.edu, ygz@cs.purdue.edu
Comments: cc: cnd-cm@bronze.ucs.indiana.edu, rzhu@watmath.waterloo.edu,
              xiaofei@ACSU.BUFFALO.EDU
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
Status: RO

Zhang Yun Gang,

You may want to know that CND-CM (HXWZ) has been relayed by
zw-list@bronze.ucs.indiana.edu in zW format. (Send a dummy msg
to zw-sub@bronze.ucs.indiana.edu for subscription).  The
conversion is done on Ultrix and there are people reading it
on PC and Mac. You are right that there has been no end of
line problems reported.

zw-list also relays HKU Chinese articles (native format: bta'ed
big5) converted to zW format.  It relayed Chpoem-l for a few
days but I took it off line because the volume of traffic there
was too big.  (Actually I haven't seen a HKU Chinese article
lately. Does anybody know why?)

Do you have a ready made HZ+zW optimizing conversion utility?
I would be interested in seeing that. (Pardon me for my ignorance,
I don't follow this newsgroup closely enough.)

  Ya-Gui Wei

From yih@BRL.MIL Mon Dec 30 15:54:18 1991
Received: from adm.brl.mil by sirius.ctr.columbia.edu (5.61/5.10) with SMTP id AA01437; Mon, 30 Dec 91 15:54:08 -0500
Received: from tbd2.brl.mil by ADM.BRL.MIL id aa19476; 30 Dec 91 15:51 EST
Date:     Mon, 30 Dec 91 15:49:48 EST
From: Yolin H u a n g <yih@BRL.MIL>
To: Yuan Jiang <yjj@ctr.columbia.edu>
Cc: Ned Walsh <walsh@cunixa.cc.columbia.edu>, ccnet-l@uga.cc.uga.edu
Subject:  Re: simplification; PinYin; GB
Message-Id:  <9112301549.aa27985@TBD2.BRL.MIL>
Status: RO

----- Forwarded message # 1:
From: Yuan Jiang <yjj@ctr.columbia.edu>
Date: Sat, 21 Dec 91 17:39:26 EST

Very good and informative article.  I'm no expert in this field.
I might have not understood your point well here. 

>The 'PinYin' system (Beijing, 1950's) is better than 'bopomofo'
)  But it is not without its pitfalls.  Since 'PinYin'
>  Such as in 'x', 's', and 'q', 'c', (each has a corresponding
>symbol in bopomofo), which are usually quite a hurdle to the
>uninitiated.  I suppose, it would make better sense for 'x', and 's' to
>use the same openning consonant followed by different vowels (for
>instance, one sharp (sii) one muted (si)).  Same for the 'q' and 'c' (for
>instance, one sharp (cii) one muted (ci); suppose there is probably no
>better choice than 'c' other than 'ts').  (And in combinations, some of

I agree "ts" is better than "c" for people who know English well.
To me the difference of "x" and "c" lies on consonant.  How can
you use "sii" for "xi"?  It's changing the vowel.

----- End of forwarded messages

thank you for your good comment, interest, and brief questions.

1) |< I agree "ts" is better than "c" for people who know English well.

It seems that among the major languages using the Roman alphabet
(English, Spanish, French, German, and Italian), PinYin itself functions
more closely along the English pronunciation than other.  Two reasons: i)
British has enjoyed a major influence on China, long since 19th century,
more than any other Roman countries. (e.g. the good old Custom and Postal
services were imported and built-up by British Sir Robert Hart for many
decades) So that, even after Communism, PinYin didn't use Cyrillic.  ii)
English is today by far the most widely circulated than any other.  And,
it is likely to stay that way for a long time to come.  So, I figure that
'ts' would be less confusing than 'c', even though the current 'c' is not
that bad.  In fact, 'c' in PinYin pronounces the same as in High German,
also close to that in Italian.

2) |< To me the difference of "x" and "c" lies on consonant.

You probably misunderstood my text.  I didn't mean any differently.  I
placed 'x' and 's' in one box, and placed 'q' and 'c' in another box.  By
that, I meant 'x' and 's' could share the same consonant; while 'q' and
'c' could share another (same) consonant.  I didn't mean 'x' and 'c' could
use the same consonant.

3) |< How can you use "sii" for "xi"?  It's changing the vowel.  

As explained in 2), I put 'x' and 's' in the same box, because they could
share the same consonant.  So, I figured that in order to use the same 's'
as consonant, we have to absorb the difference between the current 'x'
and 's' (which are syllabary in phonetics) into different vowels.  And, in
order to preserve the current 'si' pronunciation (such as in SiChuan, for
that I couldn't find anything close in English), we have to devise a new
vowel to make up the difference.  So, I suggested that we could use 'sii'
to replace 'xi' (such as in XiWang, which is close to English 'see' or
'sea'.)

I didn't know that this idea could be that hard to convey.  A little
discouraging.  Would you please talk to Ned Walsh?  See what Ned says.
He seems also to sit somewhere in Columbia, and is a successful but
good-humored linguist.

From CCNET-L@uga.cc.uga.edu Tue Dec 31 03:33:03 1991
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.61/5.10) with SMTP id AA06900; Tue, 31 Dec 91 03:32:50 -0500
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 9820; Tue, 31 Dec 91 03:31:46 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 7762;
 Tue, 31 Dec 91 03:31:45 EST
Date:         Tue, 31 Dec 1991 09:27:38 +0100
Reply-To: yang%VSOPF3.CERN.CH@uga.cc.uga.edu
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: yang%VSOPF3.CERN.CH@uga.cc.uga.edu
Comments: To: ccnet-l%uga.bitnet@MINT.decnet.cern.ch
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
Status: RO

Xiangjun write:
<"xi" to many English speaking people and to many Chinese sounds more
<close to shee(p) than see.
   Not true.
<...
<are usually quite a hurdle to the uninitiated...", which is true for
<non-Chinese as well as many non-Marderin speaking Chinese people (such as
 ^^^^^^^^^^^
   French-speaking people pronounce the "X" in PinYin very correctly.

  - Yuanxin

From walsh@cunixa.cc.columbia.edu Mon Dec 30 18:21:46 1991
Received: from cunixa.cc.columbia.edu by sirius.ctr.columbia.edu (5.61/5.10) with SMTP id AA03900; Mon, 30 Dec 91 18:21:37 -0500
Received: by cunixa.cc.columbia.edu (5.59/FCB)
	id AA02114; Mon, 30 Dec 91 18:21:14 EST
Date: Mon, 30 Dec 91 18:21:14 EST
From: Ned Walsh <walsh@cunixa.cc.columbia.edu>
To: Yolin H u a n g <yih@BRL.MIL>
Cc: Yuan Jiang <yjj@ctr.columbia.edu>, ccnet-l@uga.cc.uga.edu
Subject: Re: simplification; PinYin; GB
In-Reply-To: Your message of Mon, 30 Dec 91 15:49:48 EST
Message-Id: <CMM.0.90.0.694135274.walsh@cunixa.cc.columbia.edu>
Status: RO

Hi,

Some comments....

Pinyin vs. Wade-Giles----
     I'd say this is about six of one, a half-dozen of the other.
True, uninitiated readers won't know what to make of Wade-Giles's
voicing marks (which are supposed to be open-single-quotes ` ), but
then there's no q/x/c/zh/i problem either.  Also, its habit of
hyphenating compounds helps reduce hyphenation mistakes (I cringe
whenever I see the New York Times hyphenate Beijing after the j).  On
the whole, though, it seems to me Americans come up with something
closer to the Mandarin pronunciation if they're guessing from pinyin.
The biggest problem left unresolved by both systems is the final -r
sound--it's really hard to get students to understand that Wade-Giles
shih and pinyin shi are pronounced something like "sher".

What would I have done if I were making pinyin?
1. used sh for x, ts for c, ch for q
2. used r for i in zhi, chi, and shi
3. used r for ri
4. used z for i in si and ci (sz and tsz) (maybe not such a hot idea?)
5. used yu for u-umlaut 6. used j for zh
But this is like saying I would like to spell beautiful "byutiful"? or
someone from Boston saying he wants to spell car "cah"?

The developers of bopomofo and pinyin, inspired by Sanskrit and
Japanese, did a fantastic job of systematically assigning
symbols/letter combinations to represent initials, medials and finals
(which had long since been analyzed by philologists using the fanqie
system).  Once you know the rules (and somewhat arbitrarily
standardized Mandarin pronunciations), you realize just how simple and
elegant a system pinyin is.  Of course it's not terribly practical in
terms of helping non-Chinese speakers come up with intelligible
pronunciations.  Not accurate pronunciations, mind you (that would be
impossible), just vaguely intelligible.  But oh well, people seem to
get by anyway.  I usually know what people (e.g. newscasters) mean, at
least.

I doubt the sii idea would work.  Makes me want to say "see".  Aren't
x and sh are supposed to represent slightly different sh sounds?--like
the sch/sh distinction in German--plus x is always followed by the
medial i or u.  Isn't pinyin si is a rather different phoneme,
starting with an s sound and ending with a z sound?  Not an sh sound
at all.  And I don't see how pinyin c resembles High German c (plain
old hard-k sound, no? or are you thinking of ch, which has a gutteral
throat-clearing k sound?  neither of which approaches the Mandarin
tip-of-the-tongue ts sound) or how it resembles the Italian c sound
(like a soft English ch sound).

I feel madness setting in just thinking about all this. :) The more I
consider it, the more I feel pinyin is just fine, that no matter what
romanization methods you adopt there will be problems.  It's easiest
just to teach pinyin pronunciation to those who really need to know it
and let everyone else wing it, no?

/Ned

From CCNET-L@uga.cc.uga.edu Mon Dec 30 20:19:10 1991
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.61/5.10) with SMTP id AA04371; Mon, 30 Dec 91 20:18:56 -0500
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 9021; Mon, 30 Dec 91 20:18:10 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 2868;
 Mon, 30 Dec 91 20:18:08 EST
Date:         Mon, 30 Dec 1991 20:17:54 -0500
Reply-To: xiangjun%MICROSOFT.COM@uga.cc.uga.edu
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: xiangjun%MICROSOFT.COM@uga.cc.uga.edu
Subject:      Re: simplification; PinYin; GB
Comments: To: ccnet-l@uga.cc.uga.edu
Comments: cc: walsh@cunixa.cc.columbia.edu
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
Status: RO

I am not an expert either, but forgive me to comment a little
from what I feel intuitively though others might have thought
about it already:

|and 's' (which are syllabary in phonetics) into different vowels.  And, in
|order to preserve the current 'si' pronunciation (such as in SiChuan, for
|that I couldn't find anything close in English), we have to devise a new
|vowel to make up the difference.  So, I suggested that we could use 'sii'
|to replace 'xi' (such as in XiWang, which is close to English 'see' or
|'sea'.)

|>The 'PinYin' system (Beijing, 1950's) is better than 'bopomofo'
|)  But it is not without its pitfalls.  Since 'PinYin'
|>  Such as in 'x', 's', and 'q', 'c', (each has a corresponding
|>symbol in bopomofo), which are usually quite a hurdle to the
|>uninitiated.  I suppose, it would make better sense for 'x', and 's' to

"xi" to many English speaking people and to many Chinese sounds more
close to shee(p) than see.  Whenever someone hesitates to pronouce "Xiang"
in my name and be scared by X, I tell them to try to think "Xiang" as
"Shiang".  After that, they can pronounce it quite well.  Although it is
not exactly the same, this pronunciation sounds much more closer and easier
to be corrected if he/she to want be exactly right ("move your toung a
little bit forward", then "you have to add the tone" to scare them
more :-).)

[Coincidentally, I just taught a coworker to pronounce her Chinese dog's
name I just gave TODAY in the middle of this message!  She wants the name
to mean "little bandit" or little "little thief".  I gave it "xiao-fei",
a name I think much better than "xiao-tou" :-).  This little Chinese "shizi"
(Shih Tzu) puppy steals every thing ... Of course I suggest she use
"shiao-fei" to regiester as the dog's name for other's convenience to
pronouce it.]

I understand that it might be that this sh(i) was suggestednot for x(i)
because of "shi" had already been used for a different pronunciaction.  But
we can distinguish the two by shii for xi and shi for itself when they are
used alone, or we can change i in the original shi for the following reason.

Another big problem for many people is that they tried to pronounce "i"
in zhi, chi, shi, zi, ci, and si as "i" pronouced in other usual places
while the pronunciation of "i" here is not consistant with its pronunciation
in other places.  We can choose a different way to specify the vowl
there to avoid the confususion.  ("Shih Tzu" is not more helpful than
"shi zhi" in pronunciation though ... ).


With either solution above, "xi" can be "shi" and "xiang" can be replaced by
"shiang" or "shiiang", "qi" by "chi" and "qiang" by "chiang" or "chiiang",
etc.  This system may not exactly correspond to bopomofo, but if the changes
were to solve the problem that "(some of the symbols in pinyin)
are usually quite a hurdle to the uninitiated...", which is true for
non-Chinese as well as many non-Marderin speaking Chinese people (such as
my Cantonese speaking relatives), and since changing x to si is already
changing the existing pinyin system, why not change more to solve more
problems altogether.

Any better way for another big problem that hurdles many, i.e.,
"z" and "zh"?  I still remember the funny way Tom Brok??? on NBC news to
pronounce Zhao Ziyang two years ago.

(Then again, people can argue that PinYin is a different system than
English or any other language system. No one should expect to
pronounce it correctly without learning it, just like with any other
foreign language. The problem is that Pinyin is now being used for Chinese
names in English as well in other languages for ordinary non-Chinese
speakers to use.  I feel it is unlikely that pinyin will have any major
change in China for the purpose for Chinese to learn it
easily after it is used this way for years, and I see little benefits
of changes if Pinyin is only used in China.  The argument has to be the
its international usage and ease for communication which will
benefit all. Or even for econamy benefits such as product and company
names.  Most Japnese brand names seem both uniquely and can be easily
pronouced by people in other countries.  This may not a good reason from
linguistists' point of view but then an official system like pinyin
will not likely to be changed to another one for purely accademic
reasons :-).

-xiangjun

From CCNET-L@uga.cc.uga.edu Sat Jan  4 13:08:06 1992
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.61/5.10) with SMTP id AA09609; Sat, 4 Jan 92 13:07:54 -0500
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 8534; Sat, 04 Jan 92 13:06:57 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 5249;
 Sat, 04 Jan 92 13:06:55 EST
Date:         Sat, 4 Jan 1992 13:06:13 -0500
Reply-To: Rupert Zhu <rzhu%WATMATH.WATERLOO.EDU@uga.cc.uga.edu>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: Rupert Zhu <rzhu%WATMATH.WATERLOO.EDU@uga.cc.uga.edu>
Subject:      About "Pure GB" Transmission
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
Status: RO

      As Yongguang Zhang pointed out, we discussed the possible choices
of coding and transmission matters in CCNET-L during early 1991. We carefully
considered the advantages and disadvantages of "pure GB" and "popular GB".

Popular GB:
^^^^^^^^^^^
Advantage: 1) This coding is most widely used inside/outside China.
           2) The work of technical support could be minimized if
              we adopt this scheme.
Drawback:  1) The files is binary and require preliminary processing (uuencode)
              before transmitting in network;
           2) The uuencoding step prevents on-line reading.  (one need to
              do uudecode before reading.)
           3) Uuencoding incurs an overhead of 35 percent in file size.

Pure GB:
^^^^^^^^
Advantage: 1) Direct transmission;
           2) Almost no overhead for transmission purpose.
           3) This may be the ultimate direction for Chinese communication
              in future.
Drawback:  1) Pure GB transmission is based on the assumption that
              a) all ASCII printable characters can be transmitted correctly;
              b) all Chinese characters can be coded using a combination of
                 two printable chars.  So the size of Chinese character set
                 could not be larger than  9025 (i.e., 95 * 95).
           2) Considering the possible enlargement of GuoBiao coding standard
              in future,  There seems no guarantee that the total number of
              Chinese characters will still remain within 9025.
           3) The currently existing schemes have not become a widely accepted
              standard, major Chinese wordprocessors do not handle pure GB.
              (So some preliminary processing like conversion may still be
              needed.)
           4) We (HXWZ editors) lack the expertise to judge the technical
              design of the current schemes.  No authoritative agency has
              made an evaluation on the topic.  We feel a little unsafe
              to go into it blindly.
           5) Using pure GB method will certainly require much much more
              work for technical support, which we cannot afford by now.

Comparing pure GB and popular GB schemes, we feel that the latter is easier
and much safer.  The 35 percent overhead in file size is tolerable for
now and in near future.  We are quite confident that this scheme can work
for a fairly long period, during which we are still waiting for the new
development on technology and standard.

To avoid causing confusions to thousands of novice user/readers, we intend
to keep the current scheme stable until a technically more advanced
scheme become mature and widely accepted.

The above is just my personal (non-expertise) opinions.


-- Rupert Zhu

From CCNET-L@uga.cc.uga.edu Sat Jan  4 14:08:32 1992
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.61/5.10) with SMTP id AA09798; Sat, 4 Jan 92 14:08:06 -0500
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 8664; Sat, 04 Jan 92 14:07:02 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 6051;
 Sat, 04 Jan 92 14:07:01 EST
Date:         Sat, 4 Jan 1992 14:04:50 -0500
Reply-To: Rupert Zhu <rzhu%WATMATH.WATERLOO.EDU@uga.cc.uga.edu>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: Rupert Zhu <rzhu%WATMATH.WATERLOO.EDU@uga.cc.uga.edu>
Subject:      EOL Conversion for Mac Users  (forward)
Comments: To: CCNET-L@UGA.BITNET, CHPOEM-L@UBVM.cc.buffalo.edu
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
Status: RO

The following message tells us what's going on with Mac machines and how
to make an easy conversion to solve the end-of-line problem.  Thanks
to Huangxin Wang for the knowledgeable advice.         --- Rupert Zhu


--------------------- Start of Forwarded Message ------------------------

From: wang@pennmess.physics.upenn.edu ( Huangxin Wang)
To: rzhu@watmath
Subject: Re:  Standardization --- end-of-line problem with MAC

Hi, Rupert,

	Sorry I didn't reply your question earlier.  I use Mac all the time,
and it reads files created on PC or UNIX without any problem.  The problem
occurs only when I edit file on Mac and send it to other users on PC or
UNIX.  I think I have an idea and solution what's going on:

(1)  text file created on Mac end line with a single <CR>;

(2)  Mac has no problem reading text file with end-of-line sign as <CR> or
<LF> or <CR><LF>;

(3)  If one upload the text file created on Mac to UNIX in text mode, then
<CR> will be changed to <LF>;  If the upload is in binary mode, <CR> is not
changed thus it will cause problem on UNIX;

(4)  Similar thing happens at download:  in text mode:  <LF>-><CR>,
thus PC's <CR><LF> become <CR><CR> (that's why at one time I complaint
about double <CR> in the HXWZ files), but in binary mode, everything is
unchanged, <CR><LF> is shown up the same as a <CR>, but <LF> won't
messed up the two byte Chinese code (since Mac's script system can
recognize the beginning and ending of a script, thus allow the mixing
of single byte and multiple byte language text freely)

The solution for the Mac users is:

(1)  Downloading:  for all text GB file I got by uudecode the mail, I wrote
a small c program to check whether it end with <CR><LF> or <LF> (supposedly
I would never receive any file with a single <CR> since the transmission
already taking care of this); then I decide whether to download it in text mode
(<LF>) or binary mode (<CR><LF>);

(2)  Uploading a text file created on Mac:  Always use text mode in
transmission; then filter the file through your "addcr" program to make it
<CR><LF>.

I guess some people have problem with single <LF> file is some Chinese viewer
or word processor assume that all characters are double-byte, thus when a
single byte <LF> comes up, it screw up the following Chinese text.  Obviously
this is a very bad assumption.

Regards

Huangxin Wang

------------------------- End of Forwarded Message -----------------------

From CCNET-L@uga.cc.uga.edu Sat Jan  4 14:18:52 1992
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.61/5.10) with SMTP id AA09850; Sat, 4 Jan 92 14:18:39 -0500
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 8676; Sat, 04 Jan 92 14:17:38 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 6220;
 Sat, 04 Jan 92 14:17:36 EST
Date:         Sat, 4 Jan 1992 14:16:41 -0500
Reply-To: Rupert Zhu <rzhu%WATMATH.WATERLOO.EDU@uga.cc.uga.edu>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: Rupert Zhu <rzhu%WATMATH.WATERLOO.EDU@uga.cc.uga.edu>
Subject:      Propose a Standard for End-Of-Line
Comments: To: CCNET-L@UGA.BITNET, CHPOEM-L@UBVM.cc.buffalo.edu
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
Status: RO

                 A Uniform Approach for End-Of-Line
                 ==================================

      After E-mail communications with several MacIntosh user/experts, I
feel it is feasible to propose the following "standard":

(1) Different platforms (systems) may have their own design for end-of-line,
    but a "standard format" is necessary for network communication.

(2) The Standard:  All end-of-line mark should contain an LF (ASCII 10).
                   It may also contain another character in addition to
                   the LF.
                   (Under this standard a single LF or a pair CR/LF is
                   valid, but a single CR is invalid.)

(3) It is each netter's responsibility to make conversions at his/her own
    site, if necessary, to conform to the above proposed standard.
    (UNIX users and MS-DOS users do not need any conversion, while some
    Mac users may need.  Wang Huangxin's message provided an easy way
    for such conversion for Mac users.)

(4) All conversion programs will assume that the above proposed standard
    is followed.

Hopefully, this "standard" will eliminate the current confusion in the
"Chinese Poems Exchange Network".

Thank you for your attention!


-- Rupert Zhu
   January 4, 1992
========================================================================

From CCNET-L@uga.cc.uga.edu Thu Jan 16 15:33:56 1992
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.61/5.10) with SMTP id AA01653; Thu, 16 Jan 92 15:33:41 -0500
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 3209; Thu, 16 Jan 92 15:32:37 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 5786;
 Thu, 16 Jan 92 15:31:34 EST
Date:         Thu, 16 Jan 1992 14:29:11 -0600
Reply-To: kai%IASTATE.EDU@uga.cc.uga.edu
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: kai%IASTATE.EDU@uga.cc.uga.edu
Subject:      readnews help
Comments: To: CCNET-L@uga.cc.uga.edu
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
Status: RO

Hi, netters:
 Please help me. I am having trouble using the readnews utility.
   Specially, I want use the readnews utility to read Chinese articles on non-X
 window terminals, like VT100, by the command:

         b2g -b <gbfile> | readnews > <ascii file>
   So I downded the readnews.c from ahkcus.org from the path /pub/unix. And I
 got it compiled
on my machine (DECstation 5000/200) running X window).
   However, when i execute the command, it doesn't work for me. It goes like
 this:

          why% b2g -b <gbfile> |readnews
          why% No file given

          why% readnews <big5file>
          why% segmentation fault

Any pointer?
Thanx in advance.

Kai

From CCNET-L@uga.cc.uga.edu Wed Jan 22 12:18:34 1992
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.67/5.10) with SMTP id AA21164; Wed, 22 Jan 92 12:18:28 -0500
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 6496; Wed, 22 Jan 92 12:17:35 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 6022;
 Wed, 22 Jan 92 12:17:25 EST
Date:         Wed, 22 Jan 1992 16:55:00 GMT
Reply-To: Wind In His Hair <DANNY%LEVA.ICF.LEEDS.AC.UK%VTVM2.CC.VT.EDU@uga.cc.uga.edu>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: Wind In His Hair <DANNY%LEVA.ICF.LEEDS.AC.UK%VTVM2.CC.VT.EDU@uga.cc.uga.edu>
Subject:      GB, GB2PS and GB tables
Comments: To: CCNET-L%UGA.BITNET@VM1.NODAK.EDU
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
Status: RO

Dear all,

  thankyou for all help given regarding decompressing and untarring
files;  I now have a working version of GB2PS which seems to be very
useful.

  I am hoping to get an electronic copy of the GB spec.  I have a copy of a
file which I'm printing out.  The file is introduced as follows :

 `The following is a pinyin index to the GB code, encoded in the `zW' format.
 The data is taken from a HyperCard Chinese dictionary stack that I have been
 working on and has released two previous versions.
  The data is formated in the following way.  We first have a line with the
 pronunciations, they are the PinYin, the Wade-Gile, and the Yale.  The we have
 the lines starting with the tone expressed as a digit, followed by the
 characters in GB code.'

  It claims to be PINYIN.DATA from Ed Lai (at the top of page 1).  I am
unsure as to how this file tells me anything about the GB code; can anyone
enlighten me ?

  Also can anyone tell me if there is a version of the GB spec available via
anonymous ftp anywhere ?

Thank you,

Danny
+++++

Danny Cox, CADDETC, University Of Leeds, 171 Woodhouse Lane, Leeds, LS2 3AR, UK
Phone (010-532) 334457 Internet : DANNY%LEVA.ICF.LEEDS.ACUK@NSFNET-RELAY.AC.UK;
BITNET : DANNY%LEVA.ICF.LEEDS.AC.UK@CUNYVM.CUNY.EDU

From CCNET-L@uga.cc.uga.edu Wed Jan 22 12:34:59 1992
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.67/5.10) with SMTP id AA21221; Wed, 22 Jan 92 12:34:51 -0500
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 6573; Wed, 22 Jan 92 12:33:31 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 7012;
 Wed, 22 Jan 92 12:33:02 EST
Date:         Wed, 22 Jan 1992 12:38:00 EST
Reply-To: Huangxin Wang <wang%PENNMESS.PHYSICS.UPENN.EDU@uga.cc.uga.edu>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: Huangxin Wang <wang%PENNMESS.PHYSICS.UPENN.EDU@uga.cc.uga.edu>
Subject:      Re:  GB, GB2PS and GB tables
Comments: To: DANNY%LEVA.ICF.LEEDS.AC.UK%VTVM2.CC.VT.EDU@uga.cc.uga.edu
Comments: cc: CCNET-L@uga.cc.uga.edu
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
Status: RO

pinyin.data give you an index between pinyin and GB.  It simply lists
all the chinese character in GB for a pinyin.  One of the application I
wrote using this table is a little fun program call "Randpy" (or ADrandpy
on Macintosh) which randomly display chinese characters on the screen, with
its pinyin.

If you mean GB table is the table to give you a bitmap of Chinese character
for each GB, many Chinese editor/viewer have it.  E.g., GB2PS has such
a big table with the bitmap in PostScript format.  Usually GB table has
not information about this pinyin of each character, that's why Ed Lai's
table is quite useful.

		Huangxin Wang ~{Muh+vN~}, University of Pennsylvania

From CCNET-L@uga.cc.uga.edu Wed Jan 22 14:45:06 1992
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.67/5.10) with SMTP id AA22068; Wed, 22 Jan 92 14:45:02 -0500
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 7059; Wed, 22 Jan 92 14:00:04 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 1438;
 Wed, 22 Jan 92 14:00:03 EST
Date:         Wed, 22 Jan 1992 13:58:06 EST
Reply-To: liu9yong%ATHENA.MIT.EDU@uga.cc.uga.edu
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: liu9yong%ATHENA.MIT.EDU@uga.cc.uga.edu
Subject:      about cclib.16, etc
Comments: To: ccnet-l@uga.cc.uga.edu
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
Status: RO

Hi, everyone!

I would like to know the format of cclib.16 and cclib.24. I have very
little knowledge of Chinese coding and would also like to know about
the it. Would someone be kindly enough to give me some pointers?

Thank you.

AL

From CCNET-L@uga.cc.uga.edu Wed Jan 22 14:45:08 1992
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.67/5.10) with SMTP id AA22073; Wed, 22 Jan 92 14:45:07 -0500
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 7304; Wed, 22 Jan 92 14:34:49 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 3868;
 Wed, 22 Jan 92 14:34:47 EST
Date:         Wed, 22 Jan 1992 13:31:00 CST
Reply-To: L0K1416%TAMZEUS.BITNET@uga.cc.uga.edu
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: L0K1416%TAMZEUS.BITNET@uga.cc.uga.edu
Subject:      Printing GB files on laser printer.
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
Status: RO

Hi , I just wish to find out how can I print a GB file on a XEROX 4050 laser
printer (this printer does not support postscript printing).Can any kind soul
please enlighten me,thanks in advance.

KWOK LIH =====> L0K1416@zeus.tamu.edu

From CCNET-L@uga.cc.uga.edu Wed Jan 22 16:28:29 1992
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.67/5.10) with SMTP id AA22993; Wed, 22 Jan 92 16:28:23 -0500
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 8612; Wed, 22 Jan 92 16:26:15 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 3822;
 Wed, 22 Jan 92 16:26:14 EST
Date:         Wed, 22 Jan 1992 15:26:00 CST
Reply-To: WNI%UOKUCSVX.BITNET@uga.cc.uga.edu
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: WNI%UOKUCSVX.BITNET@uga.cc.uga.edu
Subject:      Convert GB to Postscript files
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
Status: RO

Hi,
  Is there any converting programs (for MSDOS) which could convert GB file
to Postscript file?  I noticed some gb2ps.tar.z in several ftp sites, is that
true the they only work on unix system?  Any help will be appreciated.
Thanks                             Weiting

From CCNET-L@uga.cc.uga.edu Thu Jan 23 13:55:06 1992
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.67/5.10) with SMTP id AA03065; Thu, 23 Jan 92 13:55:03 -0500
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 3483; Thu, 23 Jan 92 05:11:53 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 5748;
 Thu, 23 Jan 92 05:11:51 EST
Date:         Thu, 23 Jan 1992 05:11:38 -0500
Reply-To: Jianguo.Hong%CDC2.THERMODYNAMIK.MASCHINENBAU.UNI-HANNOVER.DBP.DE@uga.cc.uga.edu
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: Jianguo.Hong%CDC2.THERMODYNAMIK.MASCHINENBAU.UNI-HANNOVER.DBP.DE@uga.cc.uga.edu
Subject:      TianMa to GB
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
Status: RO

Hi,
I use TianMa 2 plus and want to convert the text to GB file. Unfortunately
it does not convert correct.
1. Does anyone have experience with converting file
     from TianMa to GB ?
2. Which code is the TianMa-file?
3  Is there any program for MSDOS system, which could  convert the
    TianMa file to  GB-file?

Thanks!

J.H

From CCNET-L@uga.cc.uga.edu Sat Jan 25 17:07:39 1992
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.67/5.10) with SMTP id AA08792; Sat, 25 Jan 92 17:07:24 -0500
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 7039; Sat, 25 Jan 92 17:06:17 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 4259;
 Sat, 25 Jan 92 17:06:14 EST
Date:         Sat, 25 Jan 1992 17:01:04 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:      bopomofo alphabet. suggestion
Comments: To: ccnet-l@uga.cc.uga.edu
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
Status: RO

To demonstrate the feasibility for an improved alphabetization for the
syllabary bopomofo, posted to CCNet-L earlier,

1) an ETen phrase.box (modified from the pinyin.box introduced by Carlos
McEvilly in Nov 91, with about 6k+ Big5 script)

			92py100.box

is prepared, zipped in 92py.zip, and uploaded to ahkcus.org
[192.55.187.25] for your scrutiny.

The usage is similar, enter

	etinmd /q		to clear the RAM, and then
	etinmd /ph=92py100.box	to read the phrase.box into RAM;

as listed in 92py1.bat.

And use Ctrl-Shift, Ctrl-Space, or Ctrl-Alt-Space to select input mode.

If key-in the regular PinYin[50's], there will be a pointer to the
modified input.

2) There is also a
			92py200.box.

In which, {jr cr sr r} is used instead.  And all the multiplicities of i, u,
and ui are further singularized:
			"i y yi" => "i",
			"u w wu" => "u",
			"ui wei" => "ui", 	plus
			"u Umlaut" => "v".	(< Ned Walsh)
The usage is similar.


The contents of 92py.zip are:

 Length  Method   Size  Ratio   Date    Time   CRC-32    Name
 ------  ------   ----  -----   ----    ----   ------    ----
   1120  Implode    791  29%  01-24-92  23:55  8645aea4  readme
   8980  Implode   4156  54%  01-24-92  23:49  d9bf7968  bopomofo.abc
  68959  Implode  35751  48%  01-18-92  10:50  ae03cd5e  92py100.box
     35  Shrunk      34   3%  01-24-92  23:58  5855adc0  92py1.bat
  70987  Implode  36850  48%  01-20-92  21:51  00525d38  92py200.box
     35  Shrunk      34   3%  01-24-92  23:59  61d89105  92py2.bat
 ------          ------  ---                             -------
 150116           77616  48%                             6

The file "bopomofo.abc" is appended bellow.


Please give it a try.
Please comment, - ? or +, to the CCNet-L@uga.cc.uga.edu.

Thanks.

Yolin Huang, yih@brl.mil
--------------------
ETen is a trademark of the ETen Information System Co., Ltd.

============================================================
bopomofo.abc:
------------------------------------------------------------
bopomofo alphabetization suggestion
===================================

The syllabary bopomofo [NanJing, 1910's] was romanized to the current PinYin
[BeiJing, 1950's], with a diligent one-to-one correspondence.  But, somehow
in a Great Leap Forward manner with insufficient alphabetical analysis, such
that it still retains some syllabic nature, despite of its alphabetical
appearance.  The result is that while the phonetic values are somewhat clear
at the syllabary bopomofo level (with FanQie), they are only implicit
(i.e. ambiguous) at the alphabetical level.

With the following Table 1, it can be seen that "i" and "u" have multiple
phonetic values.  And "j q x" and "z c s" are separate only to imply a
different "i" or "u" pronunciation.  This duo-set can be simplified to a
uni-set, and followed by different vowels, as displayed in Table 2.

Table 1. ------------------------------------------------------------
	j q x		i(yi, y)		u(yu, u:)	<= (extreme
(and	bi di li mi ni pi ti)			(lu: nu)	lip forms)

	z c s r		   i   e   a   o   u(wu w)
(and	f g h k w)

unused: v
---------------------------------------------------------------------
Table 2. ------------------------------------------------------------
		(syllabic)	(alphabetical)
				the suggested new phonetic matrix

		same		same
		vowel		vowel

	ji	zi	  |	ji	jee
		   zhi	  |		   <jree>jhee
			  |
same	qi	ci	  |	ci	cee
consonant	   chi	  | 		   <cree>chee
			  |
	xi	si	  |	si	see
		   shi	  |		   <sree>shee
			  |
	(i)	(i)	  |	(i)	(ee)
		   ri	  |		     ree
			  and ---------
			  bi di li mi ni etc.
---------------------------------------------------------------------

The "ee" has to be given, since it was pulled out of the "zi ci si"
syllabary implication.

"j" signifies an initial, with closed teeth, but without rounded lips like
in English.  A symbol with a slightly different phonetic definition.  The
lips are unstressed.

"c" = "ts", but shorter to type.  A closed teeth frictional initial, with
air-flow (aspiration).  Similar to High German (Centrum), or Italian
(ciao).  The lips are also unstressed.

The "h" is to represent the "JuanSheYin", with tongue rolled upward
(retroflex), somewhat like in the initial for an English "r" but not
rolling.  Hence, some would like to add "r" to it.  A set of {jr cr sr r}
would make great sense in its consistent implication of the intrinsic "r".
I am also inclined toward this {jr cr sr r}.  But, it would probably cause
more confusion than {jh ch sh r}, because of the wide publicity of ch and
sh.  No serendipity from Sri Lanka yet.  The lips are again unstressed with
"jh ch sh", unlike in English ch sh.

=====

The other confusion is in the pronunciation in the following (group 1):

bian, dian, jian, juan, lian, mian, nian, pian, qian, quan, tian, xian,
xuan, yan, yuan

where the "an" is pronounced differently from the following (group 2):

chuan, chuang, cuan, duan, guan, guang, huan, huang, jiang, kan, kang, kuan,
kuang, liang, luan, nan, nang, niang, nuan, pan, pang, qiang, ruan, san,
sang, shan, shang, tuan, yang, ShaanXi, XiAn

In bopomofo syllabary with FanQie, the "an" in group 1 could be passable.
Because only either the initial or the final part of a syllabary is
significant, since a syllabary is phonetically not finer resolved.  But in
alphabetical, the "an" in group 1 is actually pronunced closer to "en",
whereas the "a" in group 2 is consistent with the rest of PinYin[50's].  So,
a revision to "en" is suggested.

=====

The "u"=>"oo" idea has been discarded, because there are many "uo"
pronunciations.

The "u-umlaut" is to be consistently denoted by "yu"

Then, the major vowels are
		i ee e a o u yu

The "i a o u" are similar to High German.  "e" more relaxed than in High
German.  "yu"=u Umlaut.  "ee" is unique to North China HanYu pronunciation
(majority, Court standard, with pastoral inter-mixing, but not necessarily
older than some Southern minority HanYu dialects.)  The ee size is longer.
But, since it is the same e typed twice, this revision will not slow down
the key-in that much.

=====

In this way, I only consolidated the multiplicity, trimed the fat so to
speak, and reduced the confusion.  The purpose is to reduce the existing
headache, not to make up a new beast.  The rest of PinYin[50's] is quite
accurate.

The only multiplicities left are: i=y=yi, u=w=wu, and ui=wei; retained for
convenience.  Some would like to further consolidate these to one unique
symbol: "i y yi" => "i", "u w wu" => "u", "ui wei" => "ui"; plus use "v" or
"y" for "u Umlaut".  It can further increase the type-in speed.  But it is
probably more mnemonic than colloquial.

A list of suggested revision is given in the following:

Table 3. ------------------------------------------------------------
PinYin[50's]	revision

bian		bien
chi		chee
ci		cee
dian		dien
jian		jien
ju		jyu
juan		jyuen
jue		jyue
jun		jyun
lian		lien
lue		lyue
luu		lyu
mian		mien
nian		nien
nuu		nyu
nue		nyue
pian		pien
qi		ci
qia		cia
qian		cien
qiang		ciang
qiao		ciao	similar to Italian
qie		cie
qin		cin	-/\/-> China !
qing		cing
qiong		ciong
qiu		ciu
qu		cyu
quan		cyuen
que		cyue
qun		cyun
ri		ree
shi		shee
si		see
tian		tien
w=u=wu
xi		si
xia		sia
xian		sien
xiang		siang
xiao		siao
xie		sie
xin		sin
xing		sing
xiong		siong
xiu		siu
xu		syu
xuan		syuen
xue		syue
xun		syun
y=i=yi
yan		yen
yu=u-Umlaut
yuan		yuen
za		ja
zai		jai
zan		jan
zang		jang
zao		jao
ze		je
zei		jei
zen		jen
zeng		jeng
zha		jha
zhai		jhai
zhan		jhan
zhang		jhang
zhao		jhao
zhe		jhe
zhen		jhen
zheng		jheng
zhi		jhee
zhong		jhong
zhou		jhou
zhu		jhu
zhua		jhua
zhuai		jhuai
zhuan		jhuan
zhuang		jhuang
zhui		jhui
zhun		jhun
zhuo		jhuo
zi		jee
zong		jong
zou		jou
zu		ju
zuan		juan
zui		jui
zun		jun
zuo		juo

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

==========

The adventages of this modified alphabetization over PinYin[50's]:

The unnerving "z q x" are removed.  So
ZhouKouDian 	=>	JhouKouDien;
QuYuan 		=> 	CyuYuen,
XiShi 		=> 	SiShee,
CiXi 		=> 	CeeSi,
SiChuan 	=> 	SeeChuan,
XiAn 		=> 	SiAn,

Since they are on the left extreme of the keyboard, absense of "z q x"
will also increase the key-in speed.

The phonetic affinity is explicit and clear, for instance: between
	jyu, nyu, syu, yu,	or
	jyuen, cyuen, syuen, yuen,	or
	bi, ci, di, i, ji, li, mi, ni, pi, si, ti, etc.;
whereas "i" and "ee" are made unique and clear, their difference explicit.

It doesn't deviate too much from the existing PinYin[50's] rules.  Major
phonetic rules are kept intact.  So very easy to adapt to.  Veteren students
of PinYin[50's], having spent aeons under candle light and having won thick
glasses already, probably don't want to bother.  But, for those just have a
taste of PinYin, it can help maintain the serenity, and increase the
efficiency.  Here, a one-to-one correspondence to the PinYin[50's] is
maintained, so won't cause too much turbulence.

Most multiplicities are reduced.  Fairly accurate, and highly consistent
phonetics.  Even though it makes no difference to the machine; it reduces
the confusion to the user, reduces the load to the mind, so the thought
stream flows much better.  Hence, it can increase the key-in speed.  (I
guess, the kids must have long questioned about the phonetic inconsistency
in PinYin[50's].  But, weren't the kids always being told to shut up and
stay put?  When grown up, like trained elephant tied to an wood stock, good
memory but don't raise questions any more.  However, frequent wrong
spellings in PinYin[50's] reveal a commonly strained memory, albeit
well-trained.  Variation in pronunciation is another story.)

=====

The advantages of this over syllabary bopomofo:

If familiar with syllabary bopomofo, and confident with pronunciation, this
is easy to adapt to.  And there is no need to memorize a dedicated syllabary
bopomofo keyboard layout.  (Besides, it has no political side effects.)

Alphabetical has higher phonetic resolution than syllabary bopomofo, that is
what the Western scripts have struggled through from the Mesopotamian to the
Hellenistic quite a while ago.  I am not here advocating for any radical
alphabetization of the language.  But Roman alphabet is useful, since the
QWERTY keyboard is everywhere, and more and more people are getting familiar
with it.

It is easier to sort with existing computational utilities.  With catalogs
arranged in alphabetical manner, it is much faster to find what being looked
for than sorted with the syllabary bopomofo.  A good pronunciation education
is certainly essential.  Radicals and stroke counts are more reliable, but
much slower.  They can still be referenced when in doubt, and need be
provided as secondary indices somewhere.

From CCNET-L@uga.cc.uga.edu Sun Feb  2 21:26:31 1992
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.67/5.10) with SMTP id AA01862; Sun, 2 Feb 92 21:26:26 -0500
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 3816; Sun, 02 Feb 92 21:25:11 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 0675;
 Sun, 02 Feb 92 21:25:09 EST
Date:         Sun, 2 Feb 1992 21:22:45 EST
Reply-To: liu9yong%ATHENA.MIT.EDU@uga.cc.uga.edu
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: liu9yong%ATHENA.MIT.EDU@uga.cc.uga.edu
Subject:      Happy New Year and more
Comments: To: ccnet-l@uga.cc.uga.edu
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
Status: RO

Happy Chinese new year to every body on the net.

I want to take this opportunity to ask for some help on the format of
CCLIB.16 and CCLIB.24, please give me a short tutorial or any pointer
on where I can find information related to it. I thank you very much
for you kindly help.

This is my second call.

Alan

From CCNET-L@uga.cc.uga.edu Sun Feb  2 22:00:09 1992
Received: from ugav2.cc.uga.edu by sirius.ctr.columbia.edu (5.67/5.10) with SMTP id AA02009; Sun, 2 Feb 92 22:00:04 -0500
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 0147; Sun, 02 Feb 92 21:59:12 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 2097;
 Sun, 02 Feb 92 21:58:59 EST
Date:         Sun, 2 Feb 1992 21:46:23 EST
Reply-To: Hongde Luo <hongde@MS.UKY.EDU>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: Hongde Luo <hongde@MS.UKY.EDU>
Subject:      Re: Happy New Year and more
Comments: To: liu9yong%ATHENA.MIT.EDU@uga.cc.uga.edu,
              Multiple recipients of list CCNET-L
              <uga.cc.uga.edu!ATHENA.MIT.EDU!UGA.BITNET!CCNET-L@ms.uky.edu>
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
Status: RO

Here is a little bit information you may find helpful:

Here is my understanding of GB coding:

The 2-byte 8-bit GB code (with high bit set) is in the range
0xA1A1 to 0xF7FE. The second byte takes values from 0xA1 to 0xFE,
thus allowing 0xFE - 0xA1 + 1 = 0x5E (decimal 94) GB symbols.
The first byte is from 0xA1 to 0xF7, therefore there can be a total
of (0xF7 - 0xA1 + 1)*94 = 8187 valid GB codes.

In the GB table, HanZi starts from 0xB0A1, the possible total HanZi
is thus (0xF7 - 0xB0 + 1)*94 = 6768. The HanZi code between 0xB0A1
and 0xF7FE is divided into two parts, the first part between 0xB0A1
and 0xD7F9 is in PinYin order, while the second part between 0xD8A1
and 0xF7FE is in stroke (BuShou) order. There are five blank spaces
from 0xD7F to 0xD7FE. The total HanZi accommodated in the GB table
is therefore 6768 - 5 = 6763.

Calculations for getting bitmaps from GB fonts:
-----------------------------------------------

    word_index = (first_byte - 0xA1)*94 + (second_byte - 0xA1);
    byte_index = word_index * num_bytes;

where num_bytes is the number of bytes needed for one bitmap. A 16x16
font requires 32 bytes for each bitmap, and a 24x24 font requires 72
bytes for each bitmap.

byte_index gives the starting point of the bitmap in the font file.

In the BYX ziku, the range from 0xA8A1 to 0xAFFE is undefined. This
gives (0xAF - 0xA8 + 1)*94 = 752 empty spaces.

Therefore,

if (first_byte > 0xAF)
    word_index -= 752;
byte_index = word_index * 32;

--------------
Yuzhao Lu
Y.Lu@lut.ac.uk

--
****************  (606)-254-2331  **************  ---|  /  \  |  |   / --|--
* Hongde Luo             | Dept. of Compu. Sci.*   | / /~>   -+--+-  / ------
* 1325 Nancy Hanks Rd #8 | Univ. of Kentucky   *  ----/ X  \  |  |   | | \/ |
* Lexington, KY 40504    | Lexington, KY 40506 *  _- | /_\  /------- | ======
* *************  hongde@ms.uky.edu  ************   _/  |_| / /    \  |/|_L_\\

From CCNET-L@uga.cc.uga.edu Sun Mar 15 15:11:11 1992
Received: from ugav2.cc.uga.edu by sirius.ctr.columbia.edu (5.67/5.10) with SMTP id AA09487; Sun, 15 Mar 92 15:11:04 -0500
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 4692; Sun, 15 Mar 92 15:09:36 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 6897;
 Sun, 15 Mar 92 15:09:34 EST
Date:         Sun, 15 Mar 1992 15:07:45 EST
Reply-To: Ned Walsh <walsh@CUNIXA.CC.COLUMBIA.EDU>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: Ned Walsh <walsh@CUNIXA.CC.COLUMBIA.EDU>
Subject:      JIS to BIG5
Comments: To: CCNET-L@uga.cc.uga.edu
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
Status: RO

Is there a program to convert Japanese JIS files to Big5 or GuoBiao
code?

/Ned

From CCNET-L@uga.cc.uga.edu Tue Feb 12 17:46:43 1991
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.64/5.10) with SMTP id AA12304; Tue, 12 Feb 91 17:46:29 -0500
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 9071; Tue, 12 Feb 91 15:12:54 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 3357;
 Tue, 12 Feb 91 15:12:52 EST
Date:         Tue, 12 Feb 91 18:16:26 DNT
Reply-To: GUANGFAN XU <MST0B%VM.UNI-C.DK@uga.cc.uga.edu>
Sender: Chinese Computing Network <CCNET-L%UGA.BITNET@uga.cc.uga.edu>
From: GUANGFAN XU <MST0B%VM.UNI-C.DK@uga.cc.uga.edu>
Subject:      More about Traditional GB and Inst. Software, Ac. Si.
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
Status: RO

1) The traditional version of GB solved the n to 1 problem by modifying the
input method. The less frequently used traditional chrs were coded by ocuppying
the empty zones (Here I mean QuWei) which were either vacant or used by Russian
letters, etc. So you CANNOT directly convert simplified GB document to tradi-
tional GB. We can adapt the new GB convention though their Fonts are not FREE.
2) This new version uses so-called popular GB (with high bit set).
3) There are trading agents for Inst. Software outside China for promoting thei
r commercial products. It seems to me their agents are not very active.
4) The inst. has nearly sinilized all popular PC-based softares, such as PE,
AutoCAD, dBASE IV, and more.
5) The only trouble with their products is that MOST of them depend on their
Hardware products,i.e. LianXiangHanKa. This pieces of hardware has 1 MB RAM and
Video controller (The model V is compatible with VGA card). The package has ove
r 10 input methods. It has very good dictioary facility. Most important of all
the HanKa is nearly compatible with all commercial softwares without any modifi
cations. We tested NC, Pctools, Wordperfect, English version of dBASE IV, etc o
n this HanKa. All works well. You can even switch between English display and
Chinese by an inbuilt pull-down menu. It's 25 lines on VGA screen, but you can
set it to 12 lines to simulate CCDOS.
6) The HanKa can work with a printing program (resident) called GPS, which uses
Macro definitions to control different models of printers. Both HP laser II and
Canon laser printer are included in the GPS macro-driver files. We didn't
succeed in trying the Previewer because it requists much more RAM than we have
on our AT. Rumours say GPS is already out of date. The new package for proffe-
ssional Chinese Word process/typesetting is called ART. We are still waiting
for ART, so I can't say ay more.
7) I will try to collect more info about Inst. Software if there are no alter-
native channels since I know one of the trading agents in Europe. I hope I coul
d persude him to join the CCNET-L.

From CCNET-L@uga.cc.uga.edu Wed Mar 18 14:33:51 1992
Received: from ugav2.cc.uga.edu by sirius.ctr.columbia.edu (5.67/5.10) with SMTP id AA04894; Wed, 18 Mar 92 14:33:49 -0500
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 1738; Wed, 18 Mar 92 14:32:30 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 6046;
 Wed, 18 Mar 92 14:32:27 EST
Date:         Wed, 18 Mar 1992 14:30:00 EDT
Reply-To: JHUBBARD%SMITH.BITNET@uga.cc.uga.edu
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: JHUBBARD%SMITH.BITNET@uga.cc.uga.edu
Subject:      JIS to BIG5
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
Status: RO

I too am interested in a JIS<-->BIG5 (or GB) translation program. I wonder
if it would not be too difficult to take one of the existing BIG5<-->GB
translation programs (b2g by Fung Lee & Ricky Yeung, or TOGB/TOBIG by Guangfa
XU) and simply replace one of the tables with a JIS table. Especially as
JIS and GB are fairly close (I understand the layout of GB is modeled on the
JIS layout) it wouldn't seem too hard. I have a little student worker money
left, and would be happy to undertake such a project-- if the authors
mentioned above are "listening" what do you think? Neither of the above
programs are in the public domain as far as I can tell, but with permission
and a little info about the structure of the tables, maybe it would be
possible-- another giant leap for international-ism over nationalism!

If anybody has other ideas, or better yet, an already working program, I
would love to hear about it.

Jamie Hubbard, Smith College

From CCNET-L@uga.cc.uga.edu Wed Mar 18 17:12:07 1992
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.67/5.10) with SMTP id AA06730; Wed, 18 Mar 92 17:11:47 -0500
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 3352; Wed, 18 Mar 92 17:10:08 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 8505;
 Wed, 18 Mar 92 17:10:06 EST
Date:         Wed, 18 Mar 1992 14:06:28 -0800
Reply-To: Ed Lai <lai%APPLE.COM@uga.cc.uga.edu>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: Ed Lai <lai%APPLE.COM@uga.cc.uga.edu>
Subject:      Re: JIS to BIG5
Comments: To: CCNET-L@uga.cc.uga.edu
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
Status: RO

I am sure Fung Fung Lee and Ricky Yeung would not mind, but if they are on
this list, let them answer it.

As for the data, before you rush out to try to do it, I am sure that such
data already exists in the Unicode consortum. After all this is the basis of
their work on the unification of the Han characters. So try to see if you
can get it from them first.

/* Disclaimer: All statments and opinions expressed are my own */
/* Edmund K. Lai                                               */
/* Apple Computer, MS37-UP                                     */
/* 20525 Mariani Ave,                                          */
/* Cupertino, CA 95014                                         */
/* (408)974-6272                                               */
zW@h9cOi

From CCNET-L@uga.cc.uga.edu Thu Mar 19 05:20:41 1992
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.67/5.10) with SMTP id AA11949; Thu, 19 Mar 92 05:20:39 -0500
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 6015; Thu, 19 Mar 92 05:19:46 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 2687;
 Thu, 19 Mar 92 05:19:44 EST
Date:         Thu, 19 Mar 1992 11:15:53 +001
Reply-To: AG02009%MVS.UNI-C.DK@uga.cc.uga.edu
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: AG02009%MVS.UNI-C.DK@uga.cc.uga.edu
Subject:      Re: JIS <-> BIG5(GB)
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
Status: RO

 RE: JIS <->BIG5 (GB)
 00000001
 HI,
 00000002
 I AM GUANGFAN XU. I WROTE TOBIG5/TOGB (FOR PC) MAINLY BASED ON B2G BY
 00000003
 FUNG LEE & RICKY YEUNG. I THINK THEY GAVE PERMISSION TO PORT B2G TO
 00000004
 OTHER PLATFORM, WHICH I DID FOR MSDOS. SINCE I AM NOT A PROGRAMMER BY
 00000005
 PROFESSION, MY APPROACH WAS VERY PRIMITIVE. BY THE TIME I WROTE TOGB/
 00000006
 TOBIG, I HAD NO ACCESS TO UNIX SYSTEM MYSELF. THEREFOR I HAD TO BUILD
 00000007
 UP THE TRANSLATION TABLE OUT OF THE TAR FILE OF B2G. I WAS SORT OF
 00000008
 INTERESTED IN READING HKNEWS (IN BIG5) THEN, BUT GOT TIRED OF USING
 00000009
 HKREADNEWS/SHOWNEWS. I WANTED TO READ HKNEWS ON BYX. I USED PASCAL TO
 00000010
 BUILD THE TABLES (DOUBLE ENTRY ARRAY, LIKE TABLE(X,Y) ). THE ELEMENT OF
 00000011
 THE ARRAY IS DEFINED AS TWO-BYTE-STRING. SINCE I DON'T KNOW C, I HAD TO
 00000012
 USE PASCAL TO CREATE THE TRANSLATION SCHEME.
 00000013
 1) CHECK IF X BELONG TO BIG5 FIRST BYTE RANGE THEN CHECK IF Y BELONGS
 TO00000014
 BIG5 SECOND BYTE RANGE THEN OUTPUT TABLE(X,Y);
 00000015
    ELSE OUTPUT ORIGINAL X;
 00000016
 ELSE ASSIGN Y TO X
 00000017
 NEXT LOOP;
 00000018
 2) AFTER I HAD TOGB RUNNING, I SORTED THE TABLE BY SIZE OF THE
 ELEMENTS;00000019
 THE SORTED ELEMENTS WERE USED TO CONSTRUCT TABLE FOR TOBIG5;
 00000020
 TO DEBUG ERRORS IN TRANSLATION TABLES, I RELY ON HKREADNEWS TO READ
 BIG500000021
 CODE. I USED BYX TO BUILD THE ARRAY SECTION BY SECTION IN BIG5 ORDER.
 00000022
 IF ANYONE WANTS TO BUILD JIS <-> BIG5 (GB), I SUGGEST FOLLOWING
 PRIMITIV00000023
 APPROACH :))
 00000024
 IF YOU HAVE HANDY TOOLS FOR BIG5(GB) THAN JIS;
 00000025
 1) GET HARD COPY OF JIS SECTION BY SECTION
 00000026
 2) CREATE A BIG5(GB) FILE ON BIG5(GB) EDITOR THAT MAPS TO JIS SECTION
 00000027
 BY SECTION;
 00000028
 BUILD THE TRANSLATION SCHEME ACCORDING TO THE CHARACTERISTIC OF JIS
 00000029
 SO THAT YOU CAN DETECT JIS CODES FROM NON-JIS CODE;
 00000030
 THEN USE THE ARRAY (MATRIX) TO DO THE TRANSLATION;
 00000031
 IF YOU JNOW BETTER JIS THAN BIG5(GB), DO IT ANOTHER WAY AROUND;
 00000032
 GET A HARDCOPY OF BIG5(GB) SECTION BY SECTION;
 00000033
 AND DO THE MAPPING OF BIG5(GB) ON JIS EDITOR;
 00000034
 FOR GB<->BIG5, THERE IS NO NEED FOR GRAMMATIC DETECTION. TO DO JIS<->
 00000035
 BIG5(GB), YOU HAVE TO BUILD A FAIR GOOD SCHEME TO TRANSLATE NON-HANZI
 00000036
 JIS CODES TO UNDERSTABLY HANZI BIG5(GB). OF COUSE, YOU LEAVE THE
 JAPANES00000037
 LETTERS AS THEY ARE IN GB. I AM NOT SURE ABOUT BIG5.
 00000038
 I HOPE THIS CAN HELP.
 00000039

 00000040
 GUANGFAN XU, DENMARK
 00000041

 00000042
 P.S. DUE TO A HARDDISK CRASH LAST YEAR, I LOST MY TRANSLATION TABLES
 AND00000043
 RUN-TIME PROGRAMS. I HAVE A BACKUP COPY SOMEWHERE IN MY 500+ UNLABELED
 00000044
 DISKETTES. BUT IT TAKES A LOT OF TIME FOR ME TO LOCATE THE RIGHT ONE.
 00000045
 SO I CAN BE EXPECTED TO HAND OUT THE SOURCE CODE PROMPTLY UPON REQUEST.
 00000046
 AFTER ALL, THERE ARE SO MANY PROF. ON THE NETTERS. THEY CAN CREATE SOME
 00000047
 THING BETTER THAN MINE FOR SURE. :))
 00000048

From CCNET-L@uga.cc.uga.edu Tue May 12 21:58:11 1992
Received: from ugav2.cc.uga.edu by sirius.ctr.columbia.edu (5.67/5.10) with SMTP id AA15063; Tue, 12 May 92 21:58:01 -0400
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 6995; Tue, 12 May 92 21:55:55 EDT
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 6480;
 Tue, 12 May 92 21:55:52 EDT
Date:         Wed, 13 May 1992 10:53:50 JST
Reply-To: Bin Zhou <zhou@APPI.IIS.U-TOKYO.AC.JP>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: Bin Zhou <zhou@APPI.IIS.U-TOKYO.AC.JP>
Subject:      Re:  Help in transfering gb to big5
Comments: To: CCNET-L@UGA.BITNET, INTACC!jiali@sutgate.bitnetjp.ad.jp
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
Status: RO

Get "hc" from ftp@ahkcus.org:/src/unix.
Try it.

From CCNET-L@uga.cc.uga.edu Tue Jun 30 06:29:21 1992
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.67/5.10) with SMTP id AA26858; Tue, 30 Jun 92 06:29:15 -0400
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 9530; Tue, 30 Jun 92 06:27:25 EDT
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 4880;
 Tue, 30 Jun 92 06:27:24 EDT
Date:         Tue, 30 Jun 1992 11:25:08 BST
Reply-To: Yufan Hu <yufan@CS.KEELE.AC.UK>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: Yufan Hu <yufan@CS.KEELE.AC.UK>
Subject:      Re: Request to Yang Bo's ChiRK
Comments: To: CCNET-L@uga.cc.uga.edu
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
In-Reply-To:  <23012.9206300830@uk.ac.keele.seq1>; from "Wei Lin ~{AVgb~}" at
              Jun 30, 92 1:26 am
Status: RO

Wei Lin ~{AVgb~} write
>
> Yang Bo or other experts,
>
> 	Since most likely alt.chinese.text will be dominated by Hz
> postings, Could you add reading Hz files in your next release of
> ChiRK? This way, for those of us who are not fortunate enough to have
> Xwindow, we can pipe a.c.t postings to ChiRK. Seems the Hz encoding
> scheme is not hard to incorporate.  (But changing source codes for
> ChiRK is more than I can handle now. :-)
>

There is a program called 'hz2dos' comes with hz package which can convert
hz format to dos (actually gb) format. This can be used as a filter
in your pipe line before feeding to ChiRK.

-- Yufan

===========================================================================
|| JANET : yufan@uk.ac.keele.cs      ||  Yufan Hu,                       ||
|| BITNET: yufan%cs.kl.ac.uk@ukacrl  ||  Department of Computer Science, ||
|| other : yufan@cs.keele.ac.uk      ||  University of Keele, Keele,     ||
|| UUCP  : ...!ukc!kl-cs!yufan       ||  Staffordshire.  ST5 5BG.  U.K.  ||
||-----------------------------------------------------------------------||
|| Telephone: +44-782-621111 x 7357  FAX:  +44-782-713082                ||
===========================================================================

From CCNET-L@uga.cc.uga.edu Wed Jul  1 00:30:28 1992
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.67/5.10) with SMTP id AA07466; Wed, 1 Jul 92 00:30:23 -0400
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 3428; Wed, 01 Jul 92 00:27:09 EDT
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 2444;
 Wed, 01 Jul 92 00:27:07 EDT
Date:         Wed, 1 Jul 1992 14:28:35 +1000
Reply-To: Hongbo Ni <87P0786@CSDVAX.CSD.UNSW.EDU.AU>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: Hongbo Ni <87P0786@CSDVAX.CSD.UNSW.EDU.AU>
Subject:      HZ encoding for A.C.T ???
Comments: To: ccnet-L@uga.uga.edu
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
Status: RO

Dear CCNET users,

Mr Wei Yagui and Lin Wei has proposed to use HZ and zW format for post
Chinese text on A.C.T.

There is one problem with HZ encoding, each line of encoded file is very long,
specially for HXWZ. I am not sure if news system can handle those long lines.

On the other hand, Zw encoding is better. Each line of encoded file has same
length of 78 (something like uuencoded file, but much smaller with Chinese
file).

Hongbo

From CCNET-L@uga.cc.uga.edu Fri Jul  3 12:13:18 1992
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.67/5.10) with SMTP id AA04623; Fri, 3 Jul 92 12:13:06 -0400
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 2337; Fri, 03 Jul 92 12:11:06 EDT
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 6645;
 Fri, 03 Jul 92 12:11:02 EDT
Date:         Fri, 3 Jul 1992 10:48:10 -0500
Reply-To: "Ya-Gui Wei ~{QG9p~}" <yawei@BRONZE.UCS.INDIANA.EDU>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: "Ya-Gui Wei ~{QG9p~}" <yawei@BRONZE.UCS.INDIANA.EDU>
Subject:      Software Announcement (zW-HZ reader)
Comments: To: 87P0786@CSDVAX.CSD.UNSW.EDU.AU, Dan_Jacobson@ATT.COM,
              FTHOMAS@lear.sinclair.edu, Ming.Xie@sophia.inria.fr,
              WY@apmaths.uwo.ca, XUP@jii.afrc.ac.uk, YAN_CHENG@mtsg.ubc.ca,
              YWANG1@KENTVM.kent.edu, ZHANG%NRCHYD.NRC.CA@VM.NRC.CA,
              ZHANG@nrchyd.nrc.ca, artc@orl.mmc.com, ayao@casbah.acns.nwu.edu,
              boh@sfu.ca, ccnet-l@uga.cc.uga.edu, cnd-all@library.uta.edu,
              dli@eros.UVic.CA, etmax@ttacs1.ttu.edu, fanli@epas.utoronto.ca,
              guogang@iro.umontreal.ca, jiliu@copper.ucs.indiana.edu,
              juyoung@kiwi.ucs.indiana.edu, kfogel@occs.cs.oberlin.edu,
              lai@apple.com, lee@umunhum.stanford.edu,
              lin@willy.npl.washington.edu, nomura@me.uta.edu, qzd@tko.vtt.fi,
              rzhu@math.waterloo.edu, shen@iro.umontreal.ca,
              timmer@dutiws.tudelft.nl, txt15@po.CWRU.Edu, vlue@cadence.com,
              xjzhu@violet.waterloo.edu, ygz@cs.purdue.edu,
              yjj@ctr.columbia.edu, yongwang@eng.auburn.edu,
              yulin@ucs.indiana.edu, zhaoxin@convex.csd.uwm.edu
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
Status: RO

A package of programs for MS-DOS systems that reads zW/HZ coded Chinese
text is now available.  It is currently available in the following
anonymous ftp sites (login ftp, password anything, binary mode):

  cs.purdue.edu:pub/ygz/zW-hz/zwdos.zip  (curtesy of Zhang Yongguang)

You will need the MS-DOS program "pkunzip.exe" for unpacking the
package. (pkunzip should be available in ahkcus.org:src/pc/pkz110eu.exe.)


Program features:

  *  Read Chinese e-mail and news effortlessly. After loading the
software, you can use any of your ms-dos programs for Chinese. Your
programs should run just exactly as it would under ms-dos, except
that Chinese texts are automatically displayed as Chinese
characters without your intervention.

  *  High degree of compatibility with ASCII-based programs.

  *  Reads both zW and HZ codes, simultaneously.

  *  Runs on CGA, EGA, VGA, and Hercules monochrome graphic systems.
(Doesn't look very good on CGA though.)

  *  Small memory consumption - it takes only 27KB of memory (50KB
on CGA). If you use DOS5 or QEMM, you can load it into high
memory area so that it doesn't take up any DOS memory.

  *  Inteligent Chinese (pinyin) input. Most of the times you just
type in the pinyin and the program chooses the right character
among the homophones for you.

  *  Personal non-profit use is free of charge.


  Ya-Gui Wei  ~{N:QG9p~}

From CCNET-L@uga.cc.uga.edu Sat May  9 18:04:29 1992
Received: from ugav2.cc.uga.edu by sirius.ctr.columbia.edu (5.67/5.10) with SMTP id AA22533; Sat, 9 May 92 18:04:14 -0400
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 5643; Sat, 09 May 92 18:01:57 EDT
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 3045;
 Sat, 09 May 92 18:01:53 EDT
Date:         Sat, 9 May 1992 17:48:35 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:      [ecovingt:  Re: Spelling revisions]
Comments: To: ccnet-l@uga.cc.uga.edu
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
Status: RO

----- Forwarded message # 1:

From: ecovingt@sdcc13.ucsd.edu (Maiko Covington)
Newsgroups: sci.lang
Subject: Re: Spelling revisions
Date: 4 May 92 18:45:57 GMT
Organization: University of California, San Diego

In article <1992May4.134811.5050@watdragon.waterloo.edu>
 cpshelle@jeeves.waterloo.edu (cameron shelley) writes:
>cockburn@majors.enet.dec.com (Craig Cockburn) writes:
>>
>> Hi,
>> 	Does anyone have a list of which (preferably major) languages
>> regularly undergo spelling revisions ? I believe that Irish was reformed
>> in the 1950's, Scottish Gaelic in the 1980's, and that Dutch has spelling
>> revisions too. Does anyone know of any languages spoken in Europe
>> which have undergone major spelling revisions and when they took place?
>> Is it true that some languages which are phonetically spelt (ie Welsh)
>> do not undergo formal spelling revisions at all, but that all new words
>> are adapted to the phonetics of the language as the words arise?

	Japanese and Chinese have undergone writing reform too.
Japanese had major writing reform after WW2. This consisted of 3
things: (1) the spelling of words in kana was reformed, (2) the
number of kanji in "common use" was decreased, and (3) some of the
kanji were simplified.

JAPANESE:
	(1) Before the war, it was not true that when writing in kana
you just write down phonetically what you hear. Some sounds had
several written "spellings". For example, the sound "syou" (sounds
like "show" in English) could be written "syou (si + small yo + u)"
like it is now, or it could be written "se + u". The word for
"butterfly", which is pronounced "chou chou", was written "tefu
tefu". So, you had to basically memorize which spelling to use for
lots of words. This is confusing. After the war, the system we use
nowadays, or "gendai kana-dukai" (present kana usage) was made. In
the present day system, almost all words are spelled exactly as they
are pronounced. So, the syllable "syou" can ONLY be written "si +
small yo + u". There are a few exceptions, however. Most notably,
the particle pronounced "wa" which comes after a noun is written
with the kana for "ha", and the the particle sounds like "e" which
means roughly "to" is written with the kana for "he", and the "o"
particle which marks objects is written with the kana for "wo". We
are required to learn these 3 rules in first grade. Aside from
these, there are a few exceptions like "big", which is written
"ookii" and not "oukii", and similarly "far" is written "tooi" and
not "toui". But, over 99% of everything is written (in kana) exactly
how it is pronounced.
	When studying ancient literature though, we must read it in
the old spelling. The old spelling is now called "kyuu kana-dukai"
(old kana usage) or "rekisi-teki kana-dukai" (historical kana
usage). We are required to be able to READ it starting in 7th grade,
when we start reading ancient texts, but we are not required to be
able to WRITE in it.

(2) A group of about 2000 kanji (1945, I think) were reserved as
"jyouyou kanji" (common use kanji) and these are the kanji that are
now taught in schools up to the 9th grade (note: required education
in Japan goes up to 9th grade). If you know these, you are well set
to survive. You can read the newspaper, and signs on the street,
etc. BUT! These characters were reserved by the government, and so
stuff put out by the government will only use these, but there are
no restrictions on private publication at all. So, there are many
more characters than these used in magazines, books, signs, etc. I
know many more than 2000 characters just because I like to read a
lot, and the publisher of the novels I like to read happens to use
lots of characters. One interesting thing is, in Japan if there is
something that is not intended for children to read, they will not
put any pronunciation hints on the characters and they will use
obscure characters. It's pretty effective.

(3) Some of the characters were simplified. Most of these
simplifications are either a stylized form of the fast brush writing
style of the more complex character (for those in the know, these
are things like "gaku" (xue2 in Chinese)), or a part of the more
complex character made into an independent character (for those in
the know, these are things like "koe" (sheng1 in Chinese)). Some of
the characters were taken from slang forms of the character that
were just made official, and a few of them seem to have been dreamed
up by somebody, it shows NO relation to the original character at
all! But, in Japanese, most of the characters are in their original
forms.

CHINESE:
	I'm sure those more familiar with Chinese language can be
more helpful, but... As far as I know, many of the Chinese
characters were simplified in Mainland China (PRC) in 1949 with the
revolution. Actually I suspect it would take a few years for it to
become standardized, but I am not sure. Many more of the characters
were simplified than in Japan. When I read a Chinese book, it seems
to me that most of the characters are simplified, but maybe I am
just used to unsimplified characters. The characters were simplified
by the same methods used in Japan more or less, but... The Chinese
simplified characters and the Japanese simplified characters are not
necessarily the same. So, for some characters there are now three
forms - original, Japanese simplified, and PRC simplified. Do I feel
a headache coming on? ^_^
	The original forms of the characters are still used in
Taiwan, Hong Kong, and in most overseas Chinese newspapers I've
seen. The simplified ones are used in the PRC and in Malaysia (well,
I think so. Pirate Chinese music that was copied in Malaysia comes
with simplified characters in the lyrics). I do not know if the
characters you are required to know before graduating Chinese high
schools was standardized/reduced though. Anyone know?

	Well, this is just my input. I hope this was helpful.

	Maiko Covington		ecovingt@sdcc13.ucsd.edu


----- End of forwarded messages

From CCNET-L@uga.cc.uga.edu Mon May 11 15:32:24 1992
Received: from ugav2.cc.uga.edu by sirius.ctr.columbia.edu (5.67/5.10) with SMTP id AA03165; Mon, 11 May 92 15:32:18 -0400
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 1073; Mon, 11 May 92 15:29:56 EDT
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 0183;
 Mon, 11 May 92 15:29:53 EDT
Date:         Mon, 11 May 1992 15:29:40 -0400
Reply-To: Boon Kang <BOONKANG%BCSC02.BITNET@uga.cc.uga.edu>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: Boon Kang <BOONKANG%BCSC02.BITNET@uga.cc.uga.edu>
Subject:      [ecovingt:  Re: Spelling revisions]
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
Status: RO

 *** Reply to note of 05/11/92 09:42
 IMS Support,
 Transaction Services

 Simplied Chinese is being widely used in Singapore as well.  As a
 matter of fact, they teach only simplified Chinese (along with pinyin
 method) in schools. Malaysia probably does not have an official policy
 regarding the use of simplified Chinese in schools.

 Regards,                          ||  E-Mail:   BCSC02(BOONKANG)
 Boon Kang, B.C. Systems           ||            BCSC01(SC66159)
 4000 Seymour Pl, W169BLUE         ||  Phone:    604 389-3991
 Victoria, B.C. CANADA   V8X 4S8   ||  Fax:      604 389-3916

From CCNET-L@uga.cc.uga.edu Sat Aug  1 20:23:54 1992
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.67/5.10) with SMTP id AA24281; Sat, 1 Aug 92 20:23:35 -0400
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 8997; Sat, 01 Aug 92 20:21:21 EDT
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 0090;
 Sat, 01 Aug 92 20:21:19 EDT
Date:         Sat, 1 Aug 1992 20:20:20 EDT
Reply-To: XiaoFei Wang <xiaofei@EINSTEIN.PHYSICS.BUFFALO.EDU>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: XiaoFei Wang <xiaofei@EINSTEIN.PHYSICS.BUFFALO.EDU>
Subject:      Re:  Hanzi-table.hz and hanzi-table.gb
Comments: cc: -v@einstein.physics.buffalo.edu
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
Status: RO

A Chinese character can be coded using two ascii chars ( derived from
GB by droping its high bit ) and such scheme is called Hanzi.  Chinese
encoded in HZ can be transmitted via mail without going through the
uuencode/uudecode bussiness and can be read on line using proper
decoders. Please refer HZ.spec of Lee Fung Fung in the package HZ-2.0
available from ahkcus.org:./src/unix for exact info.

I have completed a table of the two ascii chars and the Chinese char
they represent from GB table ( a very trivial job ), and I call it
Hanzi table.  Same as GB table, it is divided as three parts:
1) Symbols
2) Easy words by alphabetic order
3) Difficult words by radicals.

The table can be used to enter Chinese Charaters by their HZ codes.  It
is useful for entering some symbols and very difficult characters which
may not be easy to do by other methods.

I have put the table in two formats:
HZ format: hanzi-table.hz
GB format: hanzi-table.gb
and put them to crl.nmsu.edu:./incoming

People who use yawei's zwdos may see an extra ~ in hanzi-table.hz
because yawei has not treated two ~'s as one ~ as described in HZ spec.
The problem will be fixed in the next release of zwdos.

It is a trivial job but since a number of people have shown interest, I
think it is better to make it complete. Sorry for wasting net resource.

From CCNET-L@uga.cc.uga.edu Mon Aug 24 21:45:33 1992
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.67/5.10) with SMTP id AA05338; Mon, 24 Aug 92 21:45:17 -0400
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 7038; Mon, 24 Aug 92 21:43:51 EDT
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 0217;
 Mon, 24 Aug 92 21:43:50 EDT
Date:         Mon, 24 Aug 1992 20:43:53 EST
Reply-To: Huijie <CHENH@UCS.INDIANA.EDU>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: Huijie <CHENH@UCS.INDIANA.EDU>
Subject:      Unicode Documents (FYI)
Comments: To: ccnet-l@uga.BITNET, trieu@DRILL.ME.UTORONTO.CA
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
Status: RO

Hi, There,

]From:	PO1::"trieu@DRILL.ME.UTORONTO.CA" "Trieu C. Chau" 24-AUG-1992 19:55:48.22
]Subj:	Encoding standards
]
]Can anyone direct me to a source of the official and/or tech-
]nical standards documents in electronic form (paper form
]wouldn't be bad either, but e is prefered).  I'm also search-
]ing for the proposed standards documents for Unicode.

Here is a message forwarded from one of my friends more than 3 months ago.
Hope this helps!  Please contact the agency mentioned in the text directly.

Huijie
======

Volume 2 of The Unicode Standard (containing the unified
Chinese/Japanese/Korean ideograph repertoire) is in the final pre-press
production phase.  The Unicode editor expects it to go to press by mid-May,
which would make it available about the end of June.  Orders can be placed
directly with Addison-Wesley at:  1-800-447-2226, or, Addison-Wesley
Publishing, Route 128, Reading, MA.  01867

By the way, Volume 2 is incomplete without also having Volume 1.  Volume 1
includes CJK phonetics and Symbols, hiragana, katakana, hangul, and various
CJK miscellaneous characters, as well as providing the explanation of the
overall Unicode architecture and the principles behind the "Han Unification"
of the Chinese/Japanese/Korean Ideographs found in Volume 2.  Below I've
appended an RLIN record for Unicode Vol.  1 (entered by the Xerox Research
Library -- Xerox is one of the members of the Unicode Consortium.)


 The Unicode standard : worldwide character encoding, version 1.0, volume 1 /
The Unicode Consortium. -- Reading, Mass. : Addison-Wesley, 1990, 1991.
 xx, 682 p. : ill ; 28 cm.

 ISBN 0201567881

 1. Computer software--Standards. I. The Unicode Consortium. II. Title.

 ID: CXRC92-B75                  CC: 9119       DCF: a
 CALL: QA76.76.D47U54 1990

From sol.ctr.columbia.edu!samsung!cs.utexas.edu!usc!apple!agate!qing@tantalum.cchem.berkeley.edu Thu May  3 17:19:25 EDT 1990
Article: 13717 of soc.culture.china
Path: sol.ctr.columbia.edu!samsung!cs.utexas.edu!usc!apple!agate!qing@tantalum.cchem.berkeley.edu
From: Yan Yong-Xin
Newsgroups: soc.culture.china
Subject: Alphabetic Chinese? II
Keywords: alphabetic, Chinese
Message-ID: <1990May3.063331.10433@agate.berkeley.edu>
Date: 3 May 90 06:33:31 GMT
References: Language Reform
Sender: usenet@agate.berkeley.edu (USENET Administrator;;;;ZU44)
Reply-To: qing@tantalum.cchem.berkeley.edu
Followup-To: Alphabetic Chinese?
Organization: University of California, Berkeley
Lines: 76
Status: RO


	Quite a few people expressed their opinion on whether chinese
should be alphabetized. Some of them are listed here: 
	1. x y z is better than jia2 yi2 bing3 for mathematics.
	2. the high illiteracy rate on mainland China is a proof
	   of the difficulty of Chinese language.
	3. Chinese has a different learning curve compared with English
	   More difficult at beginning, easier later on, because there
	   are more reusable parts.
	4. The only thing difficult in Chinese is remembering the exact
	   strokes of characters. Everything else is easy. Chinese has
	   the simplest grammar, and spoken language is no more difficult.
	5. It's much faster for Chinese students to be able to read newspapers
	   and books than for American students to do the same. Chinese 
	   students can read quite well at the age of 8 or 9. American kids
	   generally are not even close.
	6. Present difficulty of computerizing Chinese is not the fault of
	   Chinese language but the fault of the technology. In other words,
	   It is not because Chinese is incompatible with technology, but
	   the other way around. 
	......

	In my opinion, when "x,y,z" are used in mathematics, they are used
as symbols, not as English. The mathematical expressions form a language by
themslves. If someone thinks that the fact that "1,2,3" are used in math
instead of "one,two,three" means ancient India language is better than 
present day English, most of us probably will not agree. I do think some
symbols can be better than others. But that is a separate problem.
	Is literacy a good guage of the suppriority of a language? It is not.
It does not take into account how much effort it talk to reach the same level
of literacy. Fellow Netters use Taiwan and Japan as examples. There are plenty
of examples in mainland China. In Nantong, the city where I was born, 99% of
people between 13 and 35 are literate. In Qidong, the county where I finished
my elementary and middle school, the figure is at least 95%.
	Opinions 3 - 6 require more careful investigation. Language is a
multidimensional phenomenon. Some of the dimensions are:
	1. efficiency
	2. difficulty
	3. input
	4. output
	5. time dependence (learning curve)
	6. grammar

Thus we should ask: how difficult to be able to read? how difficult to be able
to write? how are difficulties distributed at each layer of grammar? what is 
the spatial efficiency?(how much paper or screen space is need for expressing
the same amount of information) What is the temporal output efficiency?...
In other words, every matrix element of the direct product of the dimensions
is a separate question.
	Strictly speaking, when I ask "Alphabetic Chinese?" I was comparing
present-day Chinese with a hypothetical "alphabetic Chinese" which has same
grammar same pronounciation and same everyellse except the script. Apparently
nobody including myself can make that comparison. So we should just compare
the real languages. English which certainly not the best an alphabetic lang-
uage can be, yet all of us know something about, can be our standard alpha-
betic language.
	I feel (not believe) that:
	1. Chinese character is more difficult to remember than English
	   to the exact form.
	2. scripts such as Chinese cannot in principle be made easier
	   than alphabetic language to remember the exact written form.
	3. Chinese character is more efficient to recognize.
	4. Alphabetic languages are intrisicly less efficient than two-dimension
	   scripts to recognize by human.
	5. Chinese context independent grammar is easier than English
	6. Alphabetic language can in principles have grammars that are
	   exactly as easy as languages using Square characters, but
	   inevitably at the cost in efficiency.
	7. Chinese is more suitable for voice recognition with technology
	   to be available in the near future.

The even numbered assertions are generalizations of odd-numbered ones. I have
some thoughts backing these assertions. It is already too long. I am sure you
guys have run out of patience.  What do you think?

						Yan Yong-Xin


From @cuvmb.cc.columbia.edu:CCNET-L@UGA.BITNET Sat Jun 16 10:11:11 1990
Received: from CUVMB.COLUMBIA.EDU (cuvmb.cc.columbia.edu) by sirius.ctr.columbia.edu (4.1/5.10) id AA02455; Sat, 16 Jun 90 10:11:06 EDT
Received: from CUVMB.COLUMBIA.EDU by CUVMB.COLUMBIA.EDU (IBM VM SMTP R1.2.1) with BSMTP id 5990; Sat, 16 Jun 90 10:10:26 EDT
Received: from PUCC.PRINCETON.EDU by CUVMB.COLUMBIA.EDU (Mailer R2.05) with
 BSMTP id 9735; Sat, 16 Jun 90 10:10:25 EDT
Received: from PUCC.BITNET by PUCC.PRINCETON.EDU (Mailer R2.08A) with BSMTP id
 3317; Sat, 16 Jun 90 10:10:44 EDT
Date:         Sat, 16 Jun 90 10:01:00 EDT
Reply-To: "J.B. WANG" <SPO_JWANG2%STEVENS.BITNET@cuvmb.cc.columbia.edu>
Sender: Chinese Computing Network <CCNET-L%UGA.BITNET@cuvmb.cc.columbia.edu>
From: "J.B. WANG" <SPO_JWANG2%STEVENS.BITNET@cuvmb.cc.columbia.edu>
Subject:      BoPoMoFo and PinYin
To: Multiple recipients of list CCNET-L <CCNET-L@uga>
Status: RO

Folks,

Thanks to Mr. Joseph Kuo at Steven's CS department, a BoPoMoFo and PinYin
(mainland version) mapping table is made available in
~/ch-series of anonymous, 192.12.216.114 (chiris.stevens-tech.edu) for
ftp. For those who have PostScript access, bopomofo.ps is sufficient.
bopomofo.pin is the ChText source, and bopomofo.txt is in GB format. In other
words, the ones who have ch-series installed only need bopomofo.pin, and
$chtext bopomofo.pin bopomofo.txt
will give you GB output, and
$chtex -w bopomofo.txt
will give you bopomofo.ps PostScript output.
Those who have only GB compatible software (such as Byx, or CCDOS) other than
ch-series, bopomofo.txt will be good. But I don't think you can view or
print it with Byx 1.1 and most versions of CCDOS software, because that
perticular section of BoPoMoFo symbols does not exist in these software.

Of course, this is mostly for people with Chinese educated in Taiwan, HongKong
or old China.


Sincerely yours,

J.B. Wang

From CCNET-L@uga.cc.uga.edu Tue Oct 16 12:16:21 1990
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.64/5.10) with SMTP id AA23268; Tue, 16 Oct 90 12:16:00 -0400
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 1600; Tue, 16 Oct 90 12:14:47 EDT
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 8751;
 Tue, 16 Oct 90 12:14:45 EDT
Date:         Tue, 16 Oct 90 01:35:29 MDT
Reply-To: mleisher%NMSU.EDU@uga.cc.uga.edu
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: mleisher%NMSU.EDU@uga.cc.uga.edu
Subject:      Excellent News!
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
Status: RO

I received email recently from Mr. Hiroshi Kuribayashi at OMRON who is
one of the developers of a network based Kana->Kanji conversion
system.  His letter says that a version has been developed for
Chinese!

*** The Chinese version of Wnn will be released with MIT's X11R5. ***

We have been using Wnn for Kana-Kanji conversion here for about four
months.  It is a very impressive program.  If the Chinese version is
as good as the Japanese version, we can look forward to the
development of some very good Chinese text processing tools!


Because the Chinese and Japanese conversion servers are being
distributed with X11R5, I am assuming that some interesting and useful
Chinese and Japanese Widgets and programs will be available.

From CCNET-L@uga.cc.uga.edu Tue Oct 16 16:35:24 1990
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.64/5.10) with SMTP id AA25179; Tue, 16 Oct 90 16:35:03 -0400
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 2275; Tue, 16 Oct 90 16:28:48 EDT
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 9688;
 Tue, 16 Oct 90 16:28:46 EDT
Date:         Tue, 16 Oct 90 14:19:58 MDT
Reply-To: mleisher%NMSU.EDU@uga.cc.uga.edu
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: mleisher%NMSU.EDU@uga.cc.uga.edu
Subject:      About conversion servers
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
Status: RO

I posted a message about a Chinese conversion server that will be
released with X11R5.  There were some questions about conversion
servers and X11.  Here is more detailed information about conversion
servers and so on.

The Wnn and cWnn conversion servers are Unix based programs that run
on one machine and wait for other programs to make connections with
it, across a network or from the same machine.

There are two major problems that arise when dealing computationally
with ideographic writing sytems: (1) word and phrase boundries are
ambiguous because there aren't any spaces to tell when one word/phrase
starts or ends, and (2) homonyms, words/phrases that sound similar,
but use different characters.

One solution is to gather statistical data on the frequency that a
phrase/word occurs in a certain position in a sentence.  This, along
with other disambiguating methods, is the way the Wnn conversion
server works.

In Japanese, the process of generating text is often done three steps:
(1) type in a Roman representation(Romaji) (2) convert that to the
intermediate phonetic form(Kana) and (3) convert the Kana into Kanji.
It's the third stage that presents difficulties computationally.  This
is where the conversion server comes in.  Going from step 1 to step 2
is easy because there is a clear, unambiguous mapping between Romaji
and Kana.

Given a program, somewhere on the network, that has some Kana to
convert to Kanji, the program makes a connection to the conversion
server, and passes the Kana.  The conversion server then does some
frequency checking, some syntactic processing to try and determine
things like word/phrase boundries, maybe a little sematic processing,
and then it builds a list consisting of a phrase or word with it's
homonyms, and sends it back to the program.  It is then up to the
program to work with what was returned from the conversion server.

In Chinese, the problem is similar, but a little more difficult.
There is a phonetic representation(BoPoMoFo/ZhuYinFuHao), but it
doesn't contain(as far as I know), computationaly, similar amounts of
information that is available in Kana. There exist many methods to do
the Chinese conversion(hundreds I believe).  One of the most prevalent
is Pinyin input; a Roman phonetic representation.  The cWnn conversion
server will peform the same tasks as the Wnn server does, probably
taking Pinyin as input(cWnn might be capable of other kinds of
conversions, but I haven't seen it yet, so I don't know).

(Abrupt subject change)

What is X11R5?  X11 is a freely available windowing system developed
for personal computer(recent), workstation, mini, and mainframe
systems.  X11 is a great vehicle for developing programs to deal with
text processing of non-Latin based writing systems.  It runs on many
different kinds of machines and operating systems.

You will notice that I have avoided talking about anything really
substantial, like text processors and fonts for Chinese and Japanese.

I didn't want to write about those because people are probably tired of
reading what I have written so far, and it's another "can of worms"
entirely.

Hope this helps.

From CCNET-L@uga.cc.uga.edu Thu Oct 25 09:02:10 1990
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.64/5.10) with SMTP id AA21205; Thu, 25 Oct 90 09:00:59 -0400
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 8759; Thu, 25 Oct 90 09:00:33 EDT
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 0272;
 Thu, 25 Oct 90 08:57:03 EDT
Date:         Thu, 25 Oct 90 03:57:24 MDT
Reply-To: mleisher%NMSU.EDU@uga.cc.uga.edu
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: mleisher%NMSU.EDU@uga.cc.uga.edu
Subject:      More B7 and G7 encoding info
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
Status: RO

going away now.  I fed the cat. - Zippy''

More information on my seven bit encoding scheme and background.

Disclaimer: I do not claim to be a representative of  any standards
            organizations, any official agency, or the MIT X
            Consortium.  This document is intended solely for purpose
            of gathering comments and possibly to introduce a seven
            bit encoding scheme for Chinese text into common usage.

[If you have comments or want a copy of the Compound Text Encoding
 standard document and/or the code for my seven bit encoding scheme,
 please send email to:
 Inernet: mleisher@nmsu.edu
 Bitnet : mleisher@nmsu.bitnet]

Subjects are in this order:

1. The Compound Text Encoding Standard.
2. Is a seven bit encoding standard for Chinese needed?
3. Why should we use the Compound Text Encoding standard?
4. The basics of Big5 and GuoBiao encoding.
5. The B7 and G7 seven bit encodings.



1. The Compound Text Encoding Standard.

   The MIT X Consortium wisely knew that there would be a time when
   people would want to mix languages in a single document.  This can
   lead to some very ambiguous situations in the text.

   The Compound Text Encoding standard was introduced with the X
   windowing system because the X windowing system contains many of the
   tools needed to write programs to work with multi-lingual text.

   The Compound Text Encoding standard introduces escape sequences that
   disambiguate mixed languages in one document.  This standard is based
   off of two existing International Standards Organization documents,
   ISO 2022 and ISO 6429(used for Control Sequence standards).

   It is important to note that the implied ISO 2022 starting state is
   assumed to be an 8-bit environment(see the Compound Text Encoding
   standard document for more details).

   The Compound Text Encoding standard has escape sequences defined for:

   ASCII
   7-bit ASCII graphics(ANSI X3.4-1968)
   JIS X0201-1976(reaffirmed 1984) Japanese 8-bit Alphanumeric-Katakana
   ISO 8859-{1,2,3,4} Latin alphabets 1 through 4
   ISO 8859-5 Latin/Cyrillic alphabet
   ISO 8859-6 Latin/Arabic alphabet
   ISO 8859-7 Latin/Greek alphabet
   ISO 8859-8 Latin/Hebrew alphabet
   ISO/IEC DIS 8859-9 Latin Alphabet No. 5
   GB2312-1980 (PRC) Chinese Hanzi Character Set
   JIS X0208-1983 Japanese Kanji Character Set, Level 2
   KS C5601-1987 Korean Graphic Character Set

   There are other escape sequences defined for:

   directionality
   (right-to-left or left-to-right text)

   non-standard encodings
   (non-ISO 2022 encodings, see "other coding systems" in ISO2022 doc,
    ISO registered "other coding systems" not used in Compound Text Encoding)

   extensions
   (for future extensions to the Compound Text Encoding standard by the X
    Consortium)

   other general control sequences
   (see the Compound Text Encoding standard document for more details)

2. Is a seven bit encoding standard for Chinese needed?

   Unfortunately, there are still many mail programs and terminal
   emulator programs in use that do not handle eight bit characters.
   This is rapidly changing, but until the world is reasonably sure that
   most systems can send and receive eight bit text, we should use a
   seven bit encoding system.

   There are many seven bit encoding schemes for Chinese that have
   appeared over the years, but none of them have gained popular usage.
   This is due to many reasons, but (I think) the two most important
   reasons are (1) the encoding scheme had a problem not forseen by the
   author and (2) people would prefer to use a scheme that has been
   designated as a standard by an official institution; insuring a stable
   and consistent standard.

   The GuoBiao 8 bit standard already exists, and the Big5 encoding is
   used so often, that it can be relied on not to make any sudden or
   significant changes.
   (I'm told that there is an attempt to make Big5 a ROC standard)

   These two encodings can be reliably used to form seven bit
   encoding standards.

3. Why should we use the Compound Text Encoding standard?

   The primary reason the Compound Text Encoding standard should be used,
   is stability.  It is based off of two internationally agreed upon
   standards documents(ISO 2022 and ISO 6429).

   Another good reason is that the X windowing system is now being used
   in many countries, and on many different kinds of machines.  It is
   becoming a de facto standard in many areas. For instance, the X
   windowing system recently became a US Government standard for user
   interface development.  All programs written under the X window
   system that use or work with multi-lingual text will probably use the
   Compound Text Encoding standard.

4. The basics of Big5 and GuoBiao encoding.

   At some time in the development of Chinese text encoding and
   processing methods, it was determined, that to represent the minimum
   set of Chinese characters needed for basic electronic text
   communication, two bytes would have to be used for each Chinese
   character.

   Both Big5 and GuoBiao use two bytes to represent one Chinese
   character.  However, they are a little different internally.

   A Big5 encoded Chinese character is defined as:

     Byte1 - has a value in the range 0xa1(161) through 0xfe(254)
     Byte2 - has a value in the range 0x40(64)  through 0x7e(126) or
                                      0xa0(160) through 0xfe(254)

     This encoding allows 14664 characters to be represented.

     In Big5 encoding, characters 0xa140 through 0xa3fe are used for
     symbols, Chinese numbers, an ASCII set, Greek, Roman numerals,
     and ZhuYinFuHao(not necessarily in that order).  The Chinese
     characters actually start at 0xa440.

   A GuoBiao encoded Chinese character is defined as:

     Byte1 - has a value in the range 0xa1(161) through 0xfe(254)
     Byte2 - has a value in the range 0xa1(161) through 0xfe(254)

     This encoding allows 8836 characters to be represented.

     In GuoBiao encoding, characters 0xa1a1 through 0xa3fe are used for
     symbols, Chinese numbers, an ASCII set, Greek, Roman numerals,
     Japanese Katakana and Hiragana, Russian, and BoPoMoFo(not
     necessarily in that order).  The Chinese characters actually
     start at 0xb0a1, and sometimes there are characters located in
     the range 0xaffb through 0xaffe.

5. The B7 and G7 encoding schemes.

   What is desirable in a seven bit text encoding scheme is to avoid
   ambiguity, avoid the use of control characters(with the exception of
   the escape character), avoid the possiblity of 0x00 occuring in the
   text, and represent the text as a sequence of printable characters,
   0x20 through 0x7e.

   Control characters, 0x01 through 0x1f, except 0x1b, should be avoided
   because of possible interpretation conflict with terminal emulation
   and mail programs.  The exception of 0x1b(the escape character) is
   because an unambiguous character is needed to introduce special
   sequences, and because the escape character has a long history of
   successfull use as a special sequence indicator.

   The 0x00 value is used to terminate strings in the C programming
   language.  It is possible that an occurrence of this value in the text
   could affect the interpretation of the text by functions and programs
   written in the C language.  There are other programming languages that
   interpret 0x00 in the same way.

   It is desirable to have the Chinese text represented as printable ASCII
   characters to avoid any possible misinterpretations on the part of any
   terminal emulator or mail program.

   The encoding scheme presented below meets these conditions.
   The seven bit representation of Big5 encoded Chinese text will
   henceforth be refered to as B7 and the seven bit representation of
   GuoBiao encoded Chinese text will henceforth be refered to as G7.

   B7 <-> Big5 conversion is problematic.  The second byte of the Big5
   encoded Chinese character can be 0x40 thru 0x7e or 0xa0 thru 0xfe.
   Three seven bit bytes are needed to represent a Big5 encoded Chinese
   character in B7, with one of the bytes being used to distinguish
   whether the second byte of the Chinese character was seven or eight
   bits.

   G7 <-> GuoBiao conversion only requires two bytes for the seven or
   eight bit representation.

B7 AND G7 ENCODING SPECIFICATION

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

* A Compound Text extended segment is defined as:
*
* SS: ESC % / N M L NAME STX
*
* Where N is the number of bytes needed to represent one displayable
* character, M and L are combined to form a 14 bit number to determine
* the length of the text, including NAME and STX, NAME is the name of
* the encoding system, and STX(STart of teXt) is the value 0x02.  The
* valid range of values for N are 0x00 thru 0x04, with 0x00 indicating a
* varible number of bytes. The most significant bits of M and L are
* always set.  The function used for determining the length of the
* text from M and L is: ((M - 128) * 128) + (L - 128).

B7 is defined as a slightly modified Compound Text extended segment
using 3 bytes per character because there is no registered standard.

B7 encoding will be defined as:

SS: ESC % / 3 * * BIG5 0x02
ES: ESC ( B

B7 encoding does not use M or L because there are no 0x00 valued bytes
allowed in the encoding, and the most significant bit of M and L are
NOT set, but they should be replaced with printable ASCII
characters(the asterisks in the SS mean any printable ASCII character).
To implement a strict Compound Text encoded extended segment for Big5
text, all that has to be done is calculate the M and L values when
encoding the string into B7 format.

Each B7 encoded Chinese character lying between the SS and ES will be
defined as:

Byte1: 0x21 thru 0x7e
       This value is calculated by subtracting 0x80(128) from the
       first byte of the Chinese character.

Byte2: 0x37 or 0x38
       This value is determined by the value of the second byte of
       the Chinese character.  If the second byte of the Chinese
       character is in the range 0x40 through 0x7e, this value should
       be 0x37(the character '7') and if the second byte of the
       Chinese character is in the range 0xa0 through 0xfe, this
       value should be 0x38(the character '8').

Byte3: 0x40 thru 0x7e
       If the second byte of the Chinese character is in the range
       0x40 through 0x7e, it should not change.
 or
       0x20 thru 0x7e
       If the second byte of the Chinese character is in the range
       0xa0 through 0xfe, this value is calculated by subtracting
       0x80(128) from the second byte of the Chinese character.

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

G7 encoding will be defined as:

SS: ESC $ ( A
ES: ESC ( B

Each G7 encoded Chinese character lying between the SS and ES will be
defined as:

Byte1: 0x21 thru 0x7e
       This value is calculated by subtracting 0x80(128) from the
       first byte of the Chinese character.
Byte2: 0x21 thru 0x7e
       This value is calculated by subtracting 0x80(128) from the
       second byte of the Chinese character.

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

From CCNET-L@uga.cc.uga.edu Mon Oct 22 21:05:13 1990
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.64/5.10) with SMTP id AA04451; Mon, 22 Oct 90 21:04:03 -0400
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 4073; Mon, 22 Oct 90 21:02:44 EDT
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 3386;
 Mon, 22 Oct 90 20:06:01 EDT
Date:         Mon, 22 Oct 90 17:44:58 MDT
Reply-To: mleisher%NMSU.EDU@uga.cc.uga.edu
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: mleisher%NMSU.EDU@uga.cc.uga.edu
Subject:      A proposal for a GuoBiao and Big5 seven bit encoding scheme
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
Status: RO

Below, I present what is hopefully, a reasonable, stable seven bit
encoding scheme for GuoBiao and Big5 encoded text.

Please alert me if I have left anything out or have something wrong.

[I have a program that implements the conversions between these
 encodings available.]

Send comments, bug reports, and code requests to:

Inernet: mleisher@nmsu.edu
Bitnet : mleisher@nmsu.bitnet

----------------------------- Article Start ----------------------

INTRO

In this article is presented an unambiguous and stable seven bit
encoding standard for Big5 or GuoBiao encoded Chinese electronic text.
It is based on the MIT X Consortium's "Compound Text Encoding 1.1"
standard specification.  The seven bit encodings are henceforth
refered to as B7 for seven bit encoded Big5 text and G7 for seven bit
encoded GuoBiao text.


WHY BIG5 AND GUOBIAO?

Big5, while not being an official standard, is probably used more
often than any other encoding scheme, especially in the Western world.

GuoBiao was officially registered by the PRC in 1980.

PROGRAMMING ISSUES

What is desirable in a seven bit encoding is, obviously, to represent
all of the text as seven bit values.  Although 0x00 is a valid value
in this range, it is desirable to avoid having this in the seven bit
text (for purposes of the C language and other 0x00 sensitive
systems).

B7<->Big5 conversion is problematic.  The second byte of the Big5
encoded Chinese character can be 0x40 thru 0xfe, or 190 possible
values, 127 of which are eight bit.  So three bytes are needed to
represent a Big5 encoded Chinese character in seven bits.  The first
byte of the Chinese character is treated the same way as it is in G7.
The second byte of the Chinese character is treated one of two ways:
if it is seven bits, don't change it, else if it is eight bits,
subtract 0x7e(127) from it.  This avoids having 0x00 occur in the text
and keeps the text seven bit.  Whether the second byte was seven or
eight bits, needs to be known for encoding/decoding purposes.

G7<->GuoBiao conversion is a simple process; inserting or
removing the start and end sequences, and setting and unsetting the
most significant bit.

B7 AND G7 ENCODING SPECIFICATION

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

* A Compound Text extended segment is defined as:
*
* SS: ESC % / N M L NAME STX
*
* Where N is the number of bytes needed to represent one displayable
* character, M and L are combined to form a 14 bit number to determine
* the length of the text, including NAME and STX, NAME is the name of
* the encoding system, and STX(STart of teXt) is the value 0x02.  The
* valid range of values for N are 0x00 thru 0x04, with 0x00 indicating a
* varible number of bytes. The most significant bits of M and L are
* always set.

B7 is defined as a slightly modified Compound Text extended segment
using 3 bytes per character because there is no registered standard.

B7 encoding will be defined as:

SS: ESC % / 3 * * BIG5 0x02
ES: ESC ( B

B7 encoding does not use M or L because there are no 0x00 valued bytes
allowed in the encoding, and the most significant bit of M and L are
NOT set.  To implement a strict Compound Text encoded extended segment
for Big5 text, all that has to be done is add the M and L values.

Each B7 encoded Chinese character lying between the SS and ES will be
defined as:

Byte 1: 0x21 thru 0x7e
Byte 2: 0x07 or 0x08   (the number of bits in byte 2 of the Chinese character)
Byte 3: 0x40 thru 0x7f (if byte 2 of Chinese character was 7 bits)
        0x01 thru 0x7e (if byte 2 of Chinese character was 8 bits
                        calculated by subtracting 0x7e from byte 2 of
                        the Chinese character)

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

G7 encoding will be defined as:

SS: ESC $ ( A
ES: ESC ( B

All bytes lying between the SS and ES will use 7 bits and have a value
0x21 thru 0x7e.

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

From CCNET-L@uga.cc.uga.edu Tue Oct 23 02:43:25 1990
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.64/5.10) with SMTP id AA05597; Tue, 23 Oct 90 02:42:10 -0400
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 4590; Tue, 23 Oct 90 02:41:10 EDT
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 7131;
 Tue, 23 Oct 90 02:40:55 EDT
Date:         Tue, 23 Oct 90 00:30:43 MDT
Reply-To: mleisher%NMSU.EDU@uga.cc.uga.edu
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: mleisher%NMSU.EDU@uga.cc.uga.edu
Subject:      The seven bit encoding proposal
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
Status: RO

Thanks to information from Pai Chou (chou@cs.washington.edu), I have
corrected my proposal.  I made an incorrect assumption about the range
of the second byte of a Big5 encoded character.  I should have done my
homework right the first time!

I'm including a modified proposal document below and wanted to add a
note about why the proposal is based on the Compound Text encoding
standard.

I chose the Compound Text encoding standard as a basis because the X
Windowing system has come very close to being a de facto standard for
the workstation world.  Whether it actually becomes an official
standard or not, it will probably be used quite a lot in the future.
This provides the proposed encoding standards a stable platform.  If
changes occur in the Compound Text encoding standard, I feel that it
can be reasonably assumed that they will be well thought out,
consistent, and logical.

------------------------- Article Begins -----------------------------

INTRO

In this article is presented an unambiguous and stable seven bit
encoding standard for Big5 or GuoBiao encoded Chinese electronic text.
It is based on the MIT X Consortium's "Compound Text Encoding 1.1"
standard specification.  The seven bit encodings are henceforth
refered to as B7 for seven bit encoded Big5 text and G7 for seven bit
encoded GuoBiao text.


WHY BIG5 AND GUOBIAO?

Big5, while not being an official standard, is probably used more
often than any other encoding scheme, especially in the Western world.

GuoBiao was officially registered by the PRC in 1980.

PROGRAMMING ISSUES

What is desirable in a seven bit encoding is, obviously, to represent
all of the text as seven bit values.  Although 0x00 is a valid value
in this range, it is desirable to avoid having this in the seven bit
text (for purposes of the C language and other 0x00 sensitive
systems).

B7<->Big5 conversion is problematic.  The second byte of the Big5
encoded Chinese character can be 0x40 thru 0x7e or 0xa0 thru 0xfe So
three bytes are needed to represent a Big5 encoded Chinese character
in seven bits.  The first byte of the Chinese character is treated the
same way as it is in G7, toggling the most significant bit on or off.
The second byte of the Chinese character is treated one of two ways:
if it is seven bits, don't change it, else if it is eight bits, simply
mask the most significant bit.  All of the seven bit characters then
lie in the printable character range.  It also needs to be recorded
that the second byte was seven or eight bits.

G7<->GuoBiao conversion is a simple process; inserting or
removing the start and end sequences, and setting and unsetting the
most significant bit.

B7 AND G7 ENCODING SPECIFICATION

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

* A Compound Text extended segment is defined as:
*
* SS: ESC % / N M L NAME STX
*
* Where N is the number of bytes needed to represent one displayable
* character, M and L are combined to form a 14 bit number to determine
* the length of the text, including NAME and STX, NAME is the name of
* the encoding system, and STX(STart of teXt) is the value 0x02.  The
* valid range of values for N are 0x00 thru 0x04, with 0x00 indicating a
* varible number of bytes. The most significant bits of M and L are
* always set.

B7 is defined as a slightly modified Compound Text extended segment
using 3 bytes per character because there is no registered standard.

B7 encoding will be defined as:

SS: ESC % / 3 * * BIG5 0x02
ES: ESC ( B

B7 encoding does not use M or L because there are no 0x00 valued bytes
allowed in the encoding, and the most significant bit of M and L are
NOT set, or needed.  To implement a strict Compound Text encoded
extended segment for Big5 text, all that has to be done is add the M
and L values.

Each B7 encoded Chinese character lying between the SS and ES will be
defined as:

Byte 1: 0x21 thru 0x7e
Byte 2: 0x07 or 0x08   (the number of bits in byte 2 of the Chinese character)
Byte 3: 0x40 thru 0x7e (if byte 2 of Chinese character was 7 bits)
        0x20 thru 0x7e (if byte 2 of Chinese character was 8 bits
                        calculated by subtracting 0x80(or masking the
                        most significant bit) from byte 2 of
                        the Chinese character)

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

G7 encoding will be defined as:

SS: ESC $ ( A
ES: ESC ( B

Each G7 byte lying between the SS and ES will use 7 bits and have a value
0x21 thru 0x7e.

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

From CCNET-L@uga.cc.uga.edu Thu Oct 25 18:01:13 1990
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.64/5.10) with SMTP id AA24234; Thu, 25 Oct 90 18:00:29 -0400
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 0364; Thu, 25 Oct 90 17:36:25 EDT
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 2868;
 Thu, 25 Oct 90 17:05:18 EDT
Date:         Thu, 25 Oct 90 14:03:40 -0700
Reply-To: Qing Zhang <qing%TANTALUM.CCHEM.BERKELEY.EDU@uga.cc.uga.edu>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: Qing Zhang <qing%TANTALUM.CCHEM.BERKELEY.EDU@uga.cc.uga.edu>
Subject:      The future of Chinese Computing
Comments: To: ccnet-L@uga.cc.uga.edu
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
Status: RO

In my opinion, the near future (1990-2000) looks like this:

On the input side, there will be 4 methods:

1. Blind code. This method allows unique determination of characters.
No selection process is need even on the single character level. What is
called mang2-da3. It will most likely be structurally based but speedy
typing requires heavy load of memorization. It has steep learning curve
if no other supplementary inputing methods are available.

2. Continuous Pin-Yin input. This means one types in PinYin of whole
sentences, the program will intelligently make a best guess. At present,
Byx 2.0 (XLBR) achieves 90% of accuracy on the character level (i.e. 90%
of characters, not 90% of sentences) when tones are used. For those
who used it for a month or more, this rate can get to 95% due to the
matching of dictionary and his writing style. The current mechanism used
is what I call Word-Statistics method, it is based on a rough
categorization of words according to their frequency and length.
Further inclusion of grammar and association relations can raise such
accuracy to 99.9%. World knowledge is required to take care the last
0.1 %.

3. Voice input. By this I mean continuous speech recognition. It
requires all the knowledge of Continuous Pin-Yin input plus sound
recognition.

4. All the other methods.

The success of speech recognition won't spell the demise of other
methods. Can you imaging a big office in which every one is talking
to his computer?

Blind code method may be made unique by government regulation or by
the overwhelming muscle of its proponents. But it is unlikely to
happen because one particular method is clearly superior than the
others.

On the output side, speech synthesis will be widely used.
the Chinese fonts will switch from present day
dot-metrix and outline fonts to intelligent fonts. Although small
fonts may still be dot-matrix based.

I don't like Adobe PostScript for two reasons: 1. It is a readable
English text which is inevitably inefficient. Who will acturally
write a article with PostScript? Who will edit a PostScript file?
In most cases, it is machine-generated and machine-processed and no
one will read them. Then, why not use a BINARY code in the first
place?  2. Its one font set allows less than 256 characters. This
should not be too difficult to change.

Another factor is that using PostScript may cost China too much foreign
currency. PostScript may not have any market share in China for a long
time. Having no existing established market share is a strong attraction
for someone to introduce something totally new.

I welcome comments and criticisms.

Yan Yong-Xin 1990.10.25

From CCNET-L@uga.cc.uga.edu Fri Oct 26 00:19:07 1990
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.64/5.10) with SMTP id AA25632; Fri, 26 Oct 90 00:18:25 -0400
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 1216; Fri, 26 Oct 90 00:17:28 EDT
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 0353;
 Fri, 26 Oct 90 00:17:11 EDT
Date:         Thu, 25 Oct 90 21:16:14 -0700
Reply-To: Ed Lai <lai%APPLE.COM@uga.cc.uga.edu>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: Ed Lai <lai%APPLE.COM@uga.cc.uga.edu>
Subject:      Re: More B7 and G7 encoding info
Comments: To: CCNET-L@uga.cc.uga.edu
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
Status: RO

>Unfortunately, there are still many mail programs and terminal
>emulator programs in use that do not handle eight bit characters.
>This is rapidly changing, but until the world is reasonably sure that
>most systems can send and receive eight bit text, we should use a
>seven bit encoding system.

However there is a question how well these programs handle ESC, in that
case it would defeat the whole purpose.

>The GuoBiao 8 bit standard already exists

This is a minor point, GuoBiao is a 7 bit standard, not 8 bit standard.
What is commonly consider to be GuoBiao is in fact the internal code of
CCDOS, which is a variant of GuoBiao, not GuoBiao itself.

In other words, the core of what is called G7 encoding is the actual GuoBiao,
so there is little disagreement on this.

>Three seven bit bytes are needed to represent a Big5 encoded Chinese
>character in B7, with one of the bytes being used to distinguish
>whether the second byte of the Chinese character was seven or eight
>bits.

However the 3 byte Big-5 encoding is more of a problem. Three bytes per
character is fairly wasteful. Both GB and Big-5 characters are divided into
two sets. The first set is in the front (e.g. in Big-5 it is 0xC6?? or less)
and is the more frequently used characters. The idea is that some system
may only want to put up level 1 and not level 2. Of course this is rather
silly because no system is known to do that. But we can take advantage of
this fact for more compact coding, use two bytes for level 1 coding (actually
it can be more than level 1, it can be as many can be fit into two bytes
encoding), one character of the first byte is reserved as an escape character
so that the rest can be coded as three byte. This way the weighted average
byte per character would be very close to 2 instead of 3 in the original
proposal.

/* Disclaimer: All statments and opinions expressed are my own */
/* Edmund K. Lai                                               */
/* Apple Computer, MS37-UP                                     */
/* 20525 Mariani Ave,                                          */
/* Cupertino, CA 95014                                         */
/* (408)974-6272                                               */
zW@h9cOi

From CCNET-L@uga.cc.uga.edu Sun Oct 28 11:22:56 1990
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.64/5.10) with SMTP id AA07764; Sun, 28 Oct 90 11:22:31 -0500
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 0437; Sun, 28 Oct 90 11:19:57 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 2876;
 Sun, 28 Oct 90 11:19:41 EST
Date:         Sun, 28 Oct 90 08:19:47 -0800
Reply-To: Ed Lai <lai%APPLE.COM@uga.cc.uga.edu>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: Ed Lai <lai%APPLE.COM@uga.cc.uga.edu>
Subject:      Re: New Chinese OS for Macintosh (6.03)
Comments: To: CCNET-L@uga.cc.uga.edu
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
Status: RO

>(1)  (a very serious one!)  New system use the GB code (the same as in
>CCDOS), while the old system (CH-4.3) use shift GB, so ALL my text
>files created by my old Chinese OS cannot read!!!   They are all
>displayed as junk characters, including the file names.

This indeed a serious problem. It annoys me so much that I have been
refusing to use Simplified 6.03, and I did not try to adopt Cihui
1.8 to the simplfied system until last night. However we should not
say the New system uses GB, it uses CCDOS GB or (HGB as Fung Fung Lee
calls it), but it is not pure GB. GB is 7 bit and not 8 bit. In
practice people need to modify GB to use it, both SGB and HGB are
such variation. The fact that you do not use HGB does not mean
you do not use the GB standard, using HGB is as much a variation
from pure GB as is SGB. HGB is the laziest way to do it, just set
all the high bits to distinguish it from ASCII. Then what about
high bit set in high byte and high bit clear in low byte, well,
that is reserved for GB 3 and higher. This means that when we uses
GB 3, they are mixed together with GB 1 and 2 and slightly ahead
of GB 1 and 2. What a brilliant choice.

Yet people misunderstand all these and think that HGB is the GB
standard, so if you are not using it you are not using the GB
standard. Then some fool at Apple come to the same conclusion
and switch over without any warning. Actually there is a good
reason to use SGB instead of HGB in the Mac. Mac text data is
8 bit and not 7 bit. There are all sort of symbols in the
high bit bytes, like copyright, TM, open quotation, end quotation
etc. In CH-4.3 they are reduced but there is still room for
a number of them. But now with HGB they are almost all elminated.

The sensiable solution would have been to keep using SGB, and
for compatiablity with the CCDOS world, you never directly
access their file from a disk anyway, so you have to go
through Apple File Exchange to get the file, and the conversion
can easily be make at that time. But sensiable solution is often
ignored in favor of stupid ones.

>        And now come back to the problem of the Chinese system 6.03:
>Does anyone write a utility to convert the old GB code (shift GB) to
>the new one?  Is there an easy way to convert my chinese file created
>on the old system?  I look at the AppldpF{le Exchange Utility, but
>there is nothing for this purpose.  Also, for text file, it might be
>easy to convert, but what about text in HyperCard?  (I think the
>convenient way is to write it as a FKey to convert a certain selection
>of text).

Actually the AppleFile Exchange that comes with 6.03 should do the
job for text file, but for non-text file that won't do you any good.
My solution as usual, is a CNVT for Clipboard Magician to do the
conversion from SGB to HGB.

/* Disclaimer: All statments and opinions expressed are my own */
/* Edmund K. Lai                                               */
/* Apple Computer, MS37-UP                                     */
/* 20525 Mariani Ave,                                          */
/* Cupertino, CA 95014                                         */
/* (408)974-6272                                               */
zW@h9cOi

From CCNET-L@uga.cc.uga.edu Mon Sep 14 23:33:28 1992
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.67/5.10) with SMTP id AA00976; Mon, 14 Sep 92 23:33:22 -0400
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 2252; Mon, 14 Sep 92 23:31:36 EDT
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.08 PTF008) with BSMTP id
 5510; Mon, 14 Sep 92 23:31:34 EDT
Date:         Mon, 14 Sep 1992 23:31:23 EDT
Reply-To: Cheng-yeh Yen <cyen@EE.ENG.OHIO-STATE.EDU>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: Cheng-yeh Yen <cyen@EE.ENG.OHIO-STATE.EDU>
Subject:      Chinese fonts
Comments: To: ccnet-l%uga.BITNET@ohstvma.ircc.ohio-state.edu
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
Status: RO

Hi,

    I don't know much about GB code and cclib.16.  But I know something
about Big-5 code and some Font file structure.

    Big-5 code use 2 bytes to present a Chinese character.  The range of
each byte is :
    High Byte : A1-FE
		8E-A0
		81-8D
    Low  Byte : 40-7E
		A1-FE
So, the normal Chinese fonts should start from A140.  But there are some
different types of fonts :
    Special  fonts : A140 - A38E	 408 characters
		     A3C0 - A3E0
    Standard fonts : A440 - C67E	5401 fundamental characters
		     C940 - F9D5	7652 characters
Normally we start from A440 ( _yi1_ "one" ).  Some Chinese system (like
ETen) put Chinese font in this order.  Below are two programs which can
transfer the "order" to big5 code and vice versa.

ToBig5( n, k1, k2 )
int	      n;
unsigned char *k1, *k2;
{
  *k1 = *k2 = 0;
  if( n>=0 && n<13094 ) {
    if( n>=5401 )  n+=408;
    *k1=n/157+164;
    *k2=n%157+64;
    if( *k2>=63+64 )  *k2+=34;
  }
}

FromBig5( n, k1, k2 )
int	      *n;
unsigned char k1, k2;
{
  int  n1, n2;

  if( k1>=164 ) {
    n1=k1-164;
    n2=k2-64;
    if( k2>=161 )  n2-=34;
    *n=n1*157+n2;
    if( *n>=5401 )  *n-=408;
  }
}

    After you have the "order" of the character, you can get it's bitmap
from the font files.  ETen system use 16x15 fonts, so each character is
30 bytes.  You can also get 24x24 fonts, and each character is 72 bytes.
Below is a small program to show the Chinese fonts under X-window.  This
program use XDrawPoints only.  If you like, you can use pixmap to do it.
You can use the same technique to show it on PC screen.  You can use
BIOS call : int 10h, function 10h (or 12h, I don't remember) to do it.
If you want the fastest speed, you can access video memory directly (start
from A0000h for VGA).

unsigned char font[13094][30];
unsigned char bit[8] = { 0x80, 0x40, 0x20, 0x10, 0x8, 0x4, 0x2, 0x1 };

xDrawCFont( n, x, y )
int  n, x, y;
{
  int	 i, j, k;
  XPoint xp[240];

  for( k=i=0; i<15; ++i ) {
    for( j=0; j<8; ++j )		  /*  First Byte   */
      if( font[n][i*2] & bit[j] )
	xp[k].x=x+j,  xp[k++].y=y+i;
    for( j=0; j<8; ++j )		  /*  Second Byte  */
      if( font[n][i*2+1] & bit[j] )
	xp[k].x=x+j+8,	xp[k++].y=y+i;
  }
  XDrawPoints(mydisp,mywin,mygc,xp,k,CoordModeOrigin);
}

----------------------------------------------------------------------
Cheng-yeh Yen                               cyen@ee.eng.ohio-state.edu
Dept. of Electrical Engineering
The Ohio State University                               679 Dreese Lab
2015 Neil Avenue                                     TEL:(614)292-6176
Columbus, OH 43210                                   FAX:(614)292-7596

From CCNET-L@uga.cc.uga.edu Tue Sep 15 19:27:52 1992
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.67/5.10) with SMTP id AA09711; Tue, 15 Sep 92 19:27:38 -0400
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 7093; Tue, 15 Sep 92 19:25:50 EDT
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.08 PTF008) with BSMTP id
 5843; Tue, 15 Sep 92 19:25:49 EDT
Date:         Tue, 15 Sep 1992 20:35:00 +8
Reply-To: CTTOMLAI%CPHKVX.BITNET@uga.cc.uga.edu
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: CTTOMLAI%CPHKVX.BITNET@uga.cc.uga.edu
Subject:      chinese fonts
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
Status: RO

re. C. Yen on BIG 5.

I'm no expert on GB. I got the following by digging up some materials.

In GB, characters are represented by 2 bytes. Legal values for both
the first byte and the second byte are 21 (hexadecimal) to 7E. "Characters"
with the first byte from 21 to 27 (inclusive) are alphabets, numerals and
symbols. Chinese characters are assigned first-byte values from 30 to 7E.
According to my source, first-byte values from 28 to 2F are not assigned.
Thus, character 3021 takes up the position for code point 2821 in cclib.16
(according to the same source). I have not taken a look at cclib.16 to confirm
this, though. (We must be careful because symbols like bo-po-mo-fo are
assigned code values within the first-byte range of 28 to 2F in some systems.)

And, C. Yen is right in saying that ETEN 16X15 fonts are represented each by
30 bytes. On the other hand, CCLIB.16 fonts are 16x16 and are each 32 bytes.

One thing about using GB codes is that in actual systems the
character codes are increased by 8080 to make them easy to recognise
as 2-byte units. For example, 3473 is actually represented as B4F3.

Tom Lai.

From CCNET-L@uga.cc.uga.edu Mon May 27 13:13:46 1991
Received: from uga.cc.uga.edu by sirius (5.61/5.10) with SMTP id AA15449; Mon, 27 May 91 13:13:39 -0400
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 0897; Mon, 27 May 91 13:11:32 EDT
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 9261;
 Mon, 27 May 91 13:11:30 EDT
Date:         Mon, 27 May 91 01:31:01 CDT
Reply-To: Jianxun Ding <jding%CS.TAMU.EDU@uga.cc.uga.edu>
Sender: Chinese Computing Network <CCNET-L%UGA.BITNET@uga.cc.uga.edu>
From: Jianxun Ding <jding%CS.TAMU.EDU@uga.cc.uga.edu>
Subject:      Re: GB code and telegraphy code
Comments: To: CCNET-L@uga.cc.uga.edu
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
Status: RO

> I heard a while ago that GB code set is from the standard PRC telegraph
> code set.  Is it true?

I remember that last year I posted a message about this issue.

The GB2312 (people call it "GuoBiao Code"; its official name is "Chinese Han
Characters Coding Set for Information Exchange -- Basic Set") was developed
in late '70s or early '80s. Its design was influenced by a Japanese JIS
standard.  It conforms to ISO 2022 (mainland China's GB 2311).  It has been
registed in the ISO and has its unique ESC sequences.  They are:

	G0:	ESC 2/4 4/1
	G1:	ESC 2/4 2/9  4/1
	G2:	ESC 2/4 2/10 4/1
	G3:	ESC 2/4 2/11 4/1

GB 2312 has 6763 "Han" characters, among which 3755 have been
classified as in the 1st level (more frequently used)  and
3008 in the 2nd level (less frequently used).  It also has 682
"non-Han" characters (A, B, C, ... , and other symbols).
The selecting policy was based on the character appearance frequencies
in the published materials in the  political, economical, and scientific
areas.  Thus it has some historical traces. For example, some
characters related to the '70s political terms were classified as
in the 1st level.

Three years ago, I heard that it was planned to establish the
1st and 2nd appendix sets to the GB 2312.  About 16,000 characters
will be chosen among 50,000 "Han" characters.

Chinese Telegram Standard Code is called "DianBao Ma".  It is not
what people usually call the GB code.

-- JianXun Ding
   Department of Computer Science
   Texas A&M University

From @uga.cc.uga.edu:ao-b@cis.ohio-state.edu Tue May 28 08:15:15 1991
Received: from uga.cc.uga.edu by sirius (5.61/5.10) with SMTP id AA03445; Tue, 28 May 91 08:15:08 -0400
Received: from cheops.cis.ohio-state.edu by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with TCP; Tue, 28 May 91 08:14:41 EDT
Received: from turtle.cis.ohio-state.edu by cheops.cis.ohio-state.edu (5.61-kk/5.910403)
	id AA15544; Tue, 28 May 91 08:14:55 -0400
Received: by turtle.cis.ohio-state.edu (5.61-kk/5.910403)
	id AA05758; Tue, 28 May 91 08:14:28 -0400
Date: Tue, 28 May 91 08:14:28 -0400
From: Benjamin Ao <ao-b@cis.ohio-state.edu>
Message-Id: <9105281214.AA05758@turtle.cis.ohio-state.edu>
To: CCNET-L@cis.ohio-state.edu, yjj%CTR.COLUMBIA.EDU@uga.cc.uga.edu
Subject: Re:  GB code and telegraph code
Status: RO

No, it's not true. GB uses hexdecimal code whereas the telegraphic code
uses decimal code, also both are 4 digit per character. The telegraphic
code starts with 0001 and increments by 1 for each new character. Except
for some supplimentary characters, the main body of the character set is
strictly ordered by radicals and number of strokes according to the
Kangxi Dictionary. There are over 8000 characters in this set. Since the
correspondence between each character and its telegraphic code is 1-to-1,
the convertion is trivial. I know some Chinese software allows for input
with telegraphic code, and was told Tianma was one example, but I'm not
sure about this.


From CCNET-L@uga.cc.uga.edu Mon Apr 22 08:24:46 1991
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.64/5.10) with SMTP id AA06962; Mon, 22 Apr 91 08:24:38 -0400
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 3729; Mon, 22 Apr 91 08:24:20 EDT
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 5804;
 Mon, 22 Apr 91 08:24:18 EDT
Date:         Mon, 22 Apr 91 11:46:35 +0200
Reply-To: bohn%UTRURT.UUCP@uga.cc.uga.edu
Sender: Chinese Computing Network <CCNET-L%UGA.BITNET@uga.cc.uga.edu>
From: bohn%UTRURT.UUCP@uga.cc.uga.edu
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
Status: RO

Last week there was a request for help with converting
files in GB code to BIG5 and the other way round.

In the August 1988 issue of the German language magazine
"Chinesisch & Computer" there was an article about a utility
named SINOCODE. I don't have any experience with the program
but I pass on the information anyway, maybe it is helpful to
somebody.

SINOCODE was developed at the University of Bremen/Germany.
It runs on PCs ***without!*** any Chinese operating system.

You can choose between the following conversions:

        1) GB 2312-80   -->     BIG5
        2) GB 2312-80   -->     IBM 555
        3) BIG5         -->     GB 2312-80
        4) BIG5         -->     IBM 555
        5) IBM 555      -->     BIG5
        6) IBM 555      -->     GB 2312-80

It is available for DM 100.-- at:

Urs Widmer
PC-Labor, MZH
Universitaet Bremen
2800 Bremen 33
Federal Republic of Germany

From CCNET-L@uga.cc.uga.edu Fri Apr 26 12:16:40 1991
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.64/5.10) with SMTP id AA18327; Fri, 26 Apr 91 12:16:28 -0400
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 1917; Fri, 26 Apr 91 12:16:15 EDT
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 5572;
 Fri, 26 Apr 91 12:16:12 EDT
Date:         Fri, 26 Apr 91 12:13:42 EDT
Reply-To: Rupert Zhu <rzhu%WATMATH.WATERLOO.EDU@uga.cc.uga.edu>
Sender: Chinese Computing Network <CCNET-L%UGA.BITNET@uga.cc.uga.edu>
From: Rupert Zhu <rzhu%WATMATH.WATERLOO.EDU@uga.cc.uga.edu>
Subject:      Bug-Detecting Program for GuoBiao Files
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
Status: RO

                         Bug-Detecting Program
                         =====================

       The bug-detecting program  gbdetect.c  is 100% accurate for GuoBiao
standard.  It can detect all kinds of ill characters in a GuoBiao file which
may hang a printer or an editor.  The following is a brief description.

(1) If no bug is reported by  gbdetect  program, then the file is absolutely
    safe for editing and printing.
(2) If some bugs are detected, the lines containing the bugs are put into the
    file  "file_name.err".
(3) If at least one of the bugs being found is fixable, a corrected version
    of input file will be created and put in file  "file_name.fix".  (Most
    common bugs are caused by out-of-range characters, and they are fixable.)
(4) There are some rare kinds of bugs which cannot be fixed by this program
    yet.
(5) Even if all the bugs are fixable, the technically corrected version
    may still not be literally correct.  Manual work may be needed on the
    file  "file_name.fix".

Prepared by: Rupert Zhu
For CND Chinese Magazine
April 25, 1991
------------------------------ CUT HERE -------------------------------

/*************************************************************
Program:  gbdetect.c
detect ill code in a GuoBiao file
Output lines with ill code in file  "filename.err"
Output corrected version in file "filename.fix", if fixable bug is detected.
Note: A Chinese character in GuoBiao coding consists of two bytes.
     Range of byte 1:  0xA1--0xA7, 0xB0--0xF7    (BYX and CCDOS)
     Range of byte 2:  0xA1--0xFE
     (Unused range of byte 1:  0xA8--0xAF, 0xF8--0xFE)
For usage, type  "gbdetect"  on command line (after compilation).
Author: Rupert Zhu.  April 25/1991.
Send suggestion or bug report to  <rzhu@watmath.waterloo.edu>
**************************************************************/

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <ctype.h>
#define  TRUE       1
#define  FALSE      0

char	*pgname;      /* name of this program  */
int	s_flag = FALSE;   /* command line flag for using stdin and stdout */
int	name_flag = FALSE;  /* indicate whether a file_name is provided */
int	cntrl_count = 0;       /*  no. of control char not '\n' or '\r' */
int	out_range_count = 0;   /*  no. of char between 0x80 and 0xA0 */
int	shift_count = 0;      /*  no. of char in range but at wrong position */
int	uneven_count = 0;     /*  no. of lines with odd number of high byte  */
int	bug_count = 0;         /*  total no. of bug characters  */
char	in_name[81];     /* input file name (with extension) */
char	out_name[81];    /* output file name (with extension .err) */
char	fix_name[81];    /* file for corrected text (with extension .fix) */
char	name[81];        /* file name (without extension */
FILE	*in_file;        /* file to be tested  */
FILE	*out_file;       /* file to hold error text */
FILE	*fix_file;       /* file to hold corrected version, if any */

void usage()
{
fprintf(stderr, "\t|----------------------------------------------------|\n");
fprintf(stderr, "\t| Usage:  gbdetect file_name                         |\n");
fprintf(stderr, "\t|     Lines containing bug is put in  file_name.err  |\n");
fprintf(stderr, "\t|     If any bug is detected, a corrected version    |\n");
fprintf(stderr, "\t|     is created and put in  file_name.fix           |\n");
fprintf(stderr, "\t| Example:  gbdetect  CM9104A.GB                     |\n");
fprintf(stderr, "\t|     Error text in file       CM9104A.err           |\n");
fprintf(stderr, "\t|     Corrected text in file   CM9104A.fix           |\n");
fprintf(stderr, "\t|----------------------------------------------------|\n");
exit(1);
}

/* this does the real detecting work */
void detect(void)
{
	unsigned char	c, buf[10240];
	int	i, even = TRUE, bug = FALSE;

	while ( fgets(buf, 10000, in_file) != NULL ) {
		bug = FALSE;
		i = 0;
		while ( ( c = buf[i] ) != '\0' )  {
			i ++;
			if ( iscntrl(c) && !isspace(c) ) {
				bug = TRUE;      /* ASCII control char */
				cntrl_count ++;
			}
			if ( ( c >= 0x80 && c <= 0xA0 ) || c >= 0xFF ) {
				bug = TRUE;      /* out of GuoBiao range */
				out_range_count ++;
			}
			if ( c >= 0 && c <= 0x7F ) {
				if (!even) {
					bug = TRUE;  /* un-even block */
					uneven_count ++;
				}
				even = TRUE;      /* reset at ASCII char */
			}
			if ( c >= 0xA1 && c <= 0xFE )
				even = !even;     /* paired off */
			if ( !even &&         /* c is first byte in a pair */
			    ((c>=0xA8 && c<=0xAF) || (c>= 0xF8 && c<=0xFE))) {
				bug = TRUE;     /* first byte out of range */
				shift_count ++;  /* misplaced second byte? */
			}
		}
		if (bug) {
			fputs(buf, out_file);
			fputc('\n', out_file);
		}
	}
	bug_count = cntrl_count + out_range_count + shift_count +uneven_count;
}

void fix(void)
{
	int	c;

	if ( cntrl_count || out_range_count ) {
		rewind(in_file);
		if ( (fix_file = fopen(fix_name, "w+b")) == NULL ) {
			fprintf(stderr, "File open failed\n");
			exit(1);
		}
		while ( ( c = fgetc(in_file) ) != EOF ) {
			if (isprint(c) || isspace(c) || (c>=0xA1 && c<=0xFE))
				fputc(c, fix_file);
		}
		fprintf(stderr, "\t|------------------------------------|\n");
		fprintf(stderr, "\t| A corrected version is created     |\n");
		fprintf(stderr, "\t| in file:       %-16.15s    |\n", fix_name);
		fprintf(stderr, "\t|------------------------------------|\n");
	}
	if ( shift_count || uneven_count ) {
		fprintf(stderr, "\t|-------------------------------------|\n");
		fprintf(stderr, "\t| Warning: Cannot completely fix the  |\n");
		fprintf(stderr, "\t|   file, whether or not a corrected  |\n");
		fprintf(stderr, "\t|   version is created                |\n");
		fprintf(stderr, "\t|-------------------------------------|\n");
	}
}

/* if -s flag, use stdin and stdout; otherwise, use the name provided */
void open_file()
{
	if ( s_flag ) {
		in_file = stdin;
		out_file = stdout;
	}
	else if ( !strcmp(in_name, out_name) || !strcmp(in_name, fix_name)) {
		fprintf(stderr, "\t|-------------------------------------|\n");
		fprintf(stderr, "\t| Warning: Input file should not have |\n");
		fprintf(stderr, "\t|          extension  .err  or  .fix  |\n");
		fprintf(stderr, "\t| Job aborted !                       |\n");
		fprintf(stderr, "\t|-------------------------------------|\n");
		exit(1);
	}
	else if (name_flag) {
		if ((in_file=fopen(in_name, "r+b")) == NULL)
			usage();
		if ((out_file=fopen(out_name,"w+b")) == NULL) {
			fprintf(stderr, "Cannot open out_file");
			exit(1);
		}
	}
}

/* report to user what is done */
void message()
{
	if (name_flag && !s_flag) {
		fprintf(stderr, "\t|------------------------------------|\n");
		fprintf(stderr, "\t| Input_file  =  %-16.15s    |\n", in_name);
		fprintf(stderr, "\t| Output_file =  %-16.15s    |\n", out_name);
		fprintf(stderr, "\t| Undue control characters =  %4d   |\n",
		cntrl_count);
		fprintf(stderr, "\t| Out of range characters  =  %4d   |\n",
		out_range_count);
		fprintf(stderr, "\t| Misplaced first byte     =  %4d   |\n",
		shift_count);
		fprintf(stderr, "\t| Un-even blocks           =  %4d   |\n",
		uneven_count);
		fprintf(stderr, "\t| Total Bug Characters     =  %4d   |\n",
		bug_count);
		fprintf(stderr, "\t| Job Well Done !                    |\n");
		fprintf(stderr, "\t|------------------------------------|\n");
	}
}

main(argc, argv)
int argc; char *argv[];
{
	int	i;
	char	*cp;

	if (argc <= 1 || argc >= 4)
		usage();
	pgname = argv[0];
	in_file = NULL;
	out_file = NULL;
	for (i=1; i<argc; i++) {
		cp = argv[i];
		if (*cp == '-') {  /* a flag */
			if (*++cp == 's') {   /* stdin, stdout  */
				s_flag++;
			}
		}
		else {         /* a file name argument */
			if ( name_flag == TRUE )
				usage();
			name_flag = TRUE;
			strcpy(in_name, cp);
			sscanf(in_name, "%[^.]", name);
			strcpy(out_name, "");   /* initialization */
			strcat(out_name, name);
			strcat(out_name, ".err");   /* use extension .err */
			strcpy(fix_name, "");   /* initialization */
			strcat(fix_name, name);
			strcat(fix_name, ".fix");   /* use extension .fix */
		}
	}
	if ( !name_flag && !s_flag )
		usage();
	else {
		open_file();
		detect();
		message();
		fix();
	}
}

/* This is written in standard C, instead of ANSI C, for maximum
   portability.  (Some old C compilers do not know ANSI C yet.)  */

From CCNET-L@uga.cc.uga.edu Tue May  7 05:27:46 1991
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.64/5.10) with SMTP id AA03707; Tue, 7 May 91 05:27:28 -0400
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 0311; Tue, 07 May 91 05:24:58 EDT
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 6444;
 Tue, 07 May 91 05:24:55 EDT
Date:         Tue, 7 May 91 03:22:01 MDT
Reply-To: mleisher%NMSU.EDU@uga.cc.uga.edu
Sender: Chinese Computing Network <CCNET-L%UGA.BITNET@uga.cc.uga.edu>
From: mleisher%NMSU.EDU@uga.cc.uga.edu
Subject:      Re: Poor Man's TeX fonts
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
Status: RO

Thanks for the reminder Mr. Bin Zhang :-)

OK folks.  It's Teusday, so my estimation was off a little, but I got
some things done.  Thanks go to Mr. Fung (and friend) of the FEL for
testing the original Big5 macro files (I've made a few spelling
changes).

One note about the Big5 macros:  Big5 Chinese can only be used in one
size because of the fact that there are 190 character in a Big5 row as
opposed to 94 in a GB row.  There wasn't enough room in each font to
make the larger size characters as well as the normal size characters.

I've added some more documentation that should help with generating
and installing the fonts and special instructions on how to set PMT up
in your own account.  All of Thomas Ridgeway's original documentation
has been kept.  The files "INSTALL" and "USE" give more detailed
information on installing and using Poor Man's TeX.  This
documentation is still a little sloppy, but it's a little more to the
point than what came before.  It'll get cleaned up more in the future.

In addition to the new documentation files, I've added sample files
showing the use of PMT with LaTeX files, and some samples that show
how to mix different fonts (e.g. Simplified and Traditional).  I've
also added conversion utilities for converting Chinese, Japanese, and
Korean text into a form PMT can use.  Currently, the PMT system works
with 8-bit GB and Big5 Chinese, EUC Japanese, and 8-bit KS Hangul.

Finally, the PMT system has been subdivided into directories to try
and make it more clear which files do what.

The new PMT system is available by anonymous ftp as:
crl.nmsu.edu:pub/misc/pmtex-1.1.tar.Z  [128.123.1.14]

The pre-built GB Simplified and Traditional Chinese fonts are
available as:
crl.nmsu.edu:pub/chinese/fonts/pmt-tfm/*  [128.123.1.14]
             pub/chinese/fonts/pmt-300pk/*

The pre-built Japanese fonts are available as:
crl.nmsu.edu:pub/japanese/fonts/pmt-tfm/*  [128.123.1.14]
             pub/japanese/fonts/pmt-300pk/*

The pre-built Korean fonts are available as:
crl.nmsu.edu:pub/korean/pmtex-korean-fonts.tar.Z  [128.123.1.14]

** NOTE:  All of the pre-built fonts are for 300dpi printers.

As always, if you have trouble with building, installing, or using the
system, please send me email.

-----------------------------------------------------------------------------
mleisher@nmsu.edu                      "I laughed.
Mark Leisher                                I cried.
Computing Research Lab                          I fell down.
New Mexico State University                        It changed my life."
Las Cruces, NM                     - Rich [Cowboy Feng's Space Bar and Grille]

From CCNET-L@uga.cc.uga.edu Fri May 17 09:00:54 1991
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.64/5.10) with SMTP id AA19228; Fri, 17 May 91 09:00:45 -0400
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 1272; Fri, 17 May 91 08:58:51 EDT
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 6146;
 Fri, 17 May 91 08:58:36 EDT
Date:         Fri, 17 May 91 06:42:56 MDT
Reply-To: mleisher%NMSU.EDU@uga.cc.uga.edu
Sender: Chinese Computing Network <CCNET-L%UGA.BITNET@uga.cc.uga.edu>
From: mleisher%NMSU.EDU@uga.cc.uga.edu
Subject:      Re: GB code and Bitmap file
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
Status: RO

YLu writes:

 >
 > There is a small utility called HKU readnews (Riky Yeung's?) which
 > can display Big5 code on an ASCII terminal using the bitmap file
 > 'chinese.16'. I am trying to modify the program so that it can display
 > GB code on a dumb terminal by using the BYX bitmap file 'ziku'. I
 > couldn't figure out exactly how a 2-byte GB code is related to the
 > corresponding bitmap. It should be a simple algorithm. I guess that
 > the format of 'ziku' is similar to that of 'chinese.16', which represents
 > a Chinese word by 32 bytes. The original readnews program can use
 > the bitmap 'ziku', but the output is not what's expected (a "dog"
 > is displayed as a "house", things like that).
 >

Here are the calculations for getting bitmaps from GB and Big5 fonts.

1. GB

   index = ((first_byte - 161) * 94) + (second_byte - 161)
   index = index * num_bytes

2. Big5

   index = ((first_byte - 161) * 190) + (second_byte - 64)
   index = index * num_bytes


Where num_bytes is the number of bytes needed for one bitmap.  A 16x16
font requires 32 bytes for each bitmap, and a 24x24 font requires 72
bytes for each bitmap.

The result of these calculations, index, gives the starting point of
the bitmap in the font file.
-----------------------------------------------------------------------------
mleisher@nmsu.edu                      "I laughed.
Mark Leisher                                I cried.
Computing Research Lab                          I fell down.
New Mexico State University                        It changed my life."
Las Cruces, NM                     - Rich [Cowboy Feng's Space Bar and Grille]

From CCNET-L@uga.cc.uga.edu Fri May 17 16:02:25 1991
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.64/5.10) with SMTP id AA22695; Fri, 17 May 91 16:02:11 -0400
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 3090; Fri, 17 May 91 16:00:26 EDT
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 1544;
 Fri, 17 May 91 16:00:24 EDT
Date:         Fri, 17 May 91 13:12:29 MDT
Reply-To: mleisher%NMSU.EDU@uga.cc.uga.edu
Sender: Chinese Computing Network <CCNET-L%UGA.BITNET@uga.cc.uga.edu>
From: mleisher%NMSU.EDU@uga.cc.uga.edu
Subject:      Re: ChinaStar/ETEN
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
Status: RO

Ned Walsh writes:
 > Speaking of ChinaStar...I typed up about 75 poems in ChinaStar, and
 > would now like to work on them using ETEN.  Any suggestions on how to
 > go about converting them?  I tried all the conversion possibilities I
 > could think of using ETEN's ETUTL program; none seemed to work, so I
 > assume ChinaStar uses its own proprietary coding system....But I'm new
 > to much of this and really don't know what I'm doing.  I'm willing to
 > go to a certain amount of trouble to design a conversion utility
 > between the two programs, if someone can describe to me in simple
 > language what needs to be done.
 >

OK.  The approach I would take is this:  first I would try to get some
kind of table of the ETEN layout.  The last ETEN manual I looked at
didn't have one of these, but they may have added one in later
manuals.  If I didn't have one, I would probably write a program that
generated all of the codes and "words" they map to.  This means
something like:

    for (i = 0xa1; i < 0xf7; i++) {
       for (j = 0x40; j < 0xfe; j++)
        printf("0x%02x%02x - %c%c\n", i, j, i, j);
    }

After breaking the output file into separate pages, I would print the
pages.

You may want to experiment with starting the loops at lower values and
anding them at higher values until you find out the exact range that
is available.

After doing the same thing with ChinaStar, you have two piles of paper
to compare.  Now the hard work begins.  Reading sequentially from one
printout, you look up each "word" in the other printout.  Since you
printed the code along with the "word", you can start building a
correspondence table; code xxxx in the ETEN printout matches code xxxx
in the ChinaStar printout.

Painful way to do it, but sometimes there seems no way around it.

The paper analogy could be transfered to computer: given one machine
running ETEN and one machine running ChinaStar, you could page through
each file you generated and start recording the correspondences.

Well, being lazy :-), this is the first method I thought about,
hopefully someone else has a better approach.
-----------------------------------------------------------------------------
mleisher@nmsu.edu                      "I laughed.
Mark Leisher                                I cried.
Computing Research Lab                          I fell down.
New Mexico State University                        It changed my life."
Las Cruces, NM                     - Rich [Cowboy Feng's Space Bar and Grille]

From CCNET-L@uga.cc.uga.edu Tue May 21 07:24:30 1991
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.61/5.10) with SMTP id AA08884; Tue, 21 May 91 07:24:18 -0400
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 0762; Tue, 21 May 91 07:22:40 EDT
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 4491;
 Tue, 21 May 91 07:22:38 EDT
Date:         Tue, 21 May 91 11:30:53 BST
Reply-To: YLu <Y.Lu%LUT.AC.UK@uga.cc.uga.edu>
Sender: Chinese Computing Network <CCNET-L%UGA.BITNET@uga.cc.uga.edu>
From: YLu <Y.Lu%LUT.AC.UK@uga.cc.uga.edu>
Subject:      GB code and bitmap
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
Status: RO

Here is my understanding of GB coding:

The 2-byte 8-bit GB code (with high bit set) is in the range
0xA1A1 to 0xF7FE. The second byte takes values from 0xA1 to 0xFE,
thus allowing 0xFE - 0xA1 + 1 = 0x5E (decimal 94) GB symbols.
The first byte is from 0xA1 to 0xF7, therefore there can be a total
of (0xF7 - 0xA1 + 1)*94 = 8187 valid GB codes.

In the GB table, HanZi starts from 0xB0A1, the possible total HanZi
is thus (0xF7 - 0xB0 + 1)*94 = 6768. The HanZi code between 0xB0A1
and 0xF7FE is divided into two parts, the first part between 0xB0A1
and 0xD7F9 is in PinYin order, while the second part between 0xD8A1
and 0xF7FE is in stroke (BuShou) order. There are five blank spaces
from 0xD7F to 0xD7FE. The total HanZi accommodated in the GB table
is therefore 6768 - 5 = 6763.

Calculations for getting bitmaps from GB fonts:
-----------------------------------------------

    word_index = (first_byte - 0xA1)*94 + (second_byte - 0xA1);
    byte_index = word_index * num_bytes;

where num_bytes is the number of bytes needed for one bitmap. A 16x16
font requires 32 bytes for each bitmap, and a 24x24 font requires 72
bytes for each bitmap.

byte_index gives the starting point of the bitmap in the font file.

In the BYX ziku, the range from 0xA8A1 to 0xAFFE is undefined. This
gives (0xAF - 0xA8 + 1)*94 = 752 empty spaces.

Therefore,

if (first_byte > 0xAF)
    word_index -= 752;
byte_index = word_index * 32;

--------------
Yuzhao Lu
Y.Lu@lut.ac.uk

From CCNET-L@uga.cc.uga.edu Tue Jun 25 13:26:41 1991
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.61/5.10) with SMTP id AA23894; Tue, 25 Jun 91 13:26:12 -0400
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 1652; Tue, 25 Jun 91 13:24:33 EDT
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 6193;
 Tue, 25 Jun 91 13:21:25 EDT
Date:         Sun, 23 Jun 1991 22:49:39 -0400
Reply-To: Stephen G Simpson <simpson%MATH.PSU.EDU@uga.cc.uga.edu>
Sender: Chinese Computing Network <CCNET-L%UGA.BITNET@uga.cc.uga.edu>
From: Stephen G Simpson <simpson%MATH.PSU.EDU@uga.cc.uga.edu>
Subject:      PINYIN --> BIG-5 (ETEN) table
Comments: To: ccnet-l@uga.cc.uga.edu, nada.kth.se@math.psu.edu
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
Status: RO

Hi Everybody,

I have constructed a PINYIN --> BIG-5 table based on the PHONETIC.TAB
file in the current version of the ETEN Chinese word processing
system, version 2.03.  The character coding in my table is the same as
in ETEN, i.e. a version of BIG-5.  The table appears to cover all of
the "more frequent" and "less frequent" BIG-5 characters.  To generate
the Pinyins, I used Ed Lai's PINYIN --> GB table, plus Fung F. Lee's
GB <--> BIG-5 conversion routines, plus some other routines I wrote
myself, plus some hand editing.

My table is available for anonymous ftp as
pub/simpson/chinese/py2big.tab on math.psu.edu [128.118.24.21].

My table cannot be more accurate than PHONETIC.TAB, but within that
limitation it should be pretty accurate.  I tried hard to find all the
errors.  If you find any more, please let me know.  I will incorporate
all corrections.

Steve

Stephen G. Simpson               simpson@math.psu.edu
Department of Mathematics        +1 814 863-0775
Pennsylvania State University
University Park, PA 16802

From CCNET-L@uga.cc.uga.edu Thu Jul 11 23:40:53 1991
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.61/5.10) with SMTP id AA24672; Thu, 11 Jul 91 23:40:30 -0400
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 5921; Thu, 11 Jul 91 23:40:28 EDT
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 4619;
 Thu, 11 Jul 91 23:40:23 EDT
Date:         Thu, 11 Jul 1991 23:37:23 -0400
Reply-To: Rupert Zhu <rzhu%WATMATH.WATERLOO.EDU@uga.cc.uga.edu>
Sender: Chinese Computing Network <CCNET-L%UGA.BITNET@uga.cc.uga.edu>
From: Rupert Zhu <rzhu%WATMATH.WATERLOO.EDU@uga.cc.uga.edu>
Subject:      Standards Related to Chinese Computing
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
Status: RO

                  Standards Related to Chinese Computing
                  ======================================

International Standards:
^^^^^^^^^^^^^^^^^^^^^^^
ISO-646  --- ISO 7-bit character coding set for information interchange
             (Date: 1983-07-01)
ISO-2022 --- ISO 7-bit and 8-bit character coding sets
             (Coding extension techniques)
             (Date: 1986-05-01)
ISO-4873 --- ISO 8-bit character coding set for information interchange
             (Rules and structure of codings)
ISO-6429 --- ISO 7-bit and 8-bit character coding sets
             (Modification mechanism for fonts equipments)


National Standards of China (Guo Biao):
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
GB-1988-80 --- Corresponds to ISO-646
GB-2311-80 --- Corresponds to ISO-2022
GB-2312-80 --- Chinese character coding set for information interchange
               (The basic set)
GB-5007-85 --- Set of Chinese (Song) fonts of 24 * 24
GB-5199-85 --- Set of Chinese (Song) fonts of 15 * 16
GB-6345-86 --- Set of Chinese (Song) fonts of 32 * 32
GB-7589-?? --- Chinese character coding set for information interchange
               (The second auxiliary set)
GB-7590-?? --- Chinese character coding set for information interchange
               (The fourth auxiliary set)

Compiled by: Rupert Zhu
Date:        July 11, 1991
--------------------------------------------------------------------

Note:  The information in this list is extracted from the book
       <<Zhong1 Wen2 Xin4 Xi1 Chu4 Li3 Ji4 Shu4>>, published in
       1990 in Beijing.
            These standards were mentioned in the book here or there,
       but the actual standards were not provided in the text.
            This list is incomplete.  Since the first and the third
       auxiliary set of GuoBiao coding were not mentioned in the book,
       I don't know the exact GuoBiao series number for them.  Also,
       some recent ISO standard seems not included in the list.
            More information about standards related to Chinese
       computing is welcome.  I will update this list from time to
       time.

Rupert Zhu
Dept of Combinatorics and Optimization
University of Waterloo
Waterloo, Ontario, Canada, N2L 3E5
====================================================================

From CCNET-L@uga.cc.uga.edu Sat Oct 10 11:06:06 1992
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.67/5.10) with SMTP id AA10417; Sat, 10 Oct 92 11:05:43 -0400
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 6004; Sat, 10 Oct 92 11:03:41 EDT
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.08 PTF008) with BSMTP id
 9004; Sat, 10 Oct 92 11:03:39 EDT
Date:         Sat, 10 Oct 1992 10:55:37 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: EUC
Comments: To: ccnet-l@uga.cc.uga.edu
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
Status: RO

|Date:         Wed, 7 Oct 1992 20:29:25 PST
|From:         "(Chang Fon-min)" <albert@mis.nsysu.edu.tw>
|Subject:      ABout EUC ( Extend Unix Code )

|	Did you had heard about the EUC code ? And can you give me some
|suggests about it ? Because I just understand it that is 2-4 bytes
|Chinese Code , but I really want to know more information about it ?

EUC is a fairly recent development for rendering the Han script (Kan Ji)
for 8-bit-wise computation in Japan.  There are software supporting this
code.  (Readers please correct me, if I was wrong.)

The following excerpt comes from Ken Lunde's compilation:

------------------------------------------------------------
2.2: EUC (EXTENDED UNIX CODE)
     EUC consists of four code sets, the primary code set (code set 0) which
is the ASCII 7-bit character set, and three supplemental code sets (code sets
1, 2, and 3) which can be specified by the user, and are usually used for non-
Roman characters. Code set 1 includes the characters of JIS X 0208-1990, code
set 2 is used for half-width katakana, and code set 3 is used for user-defined
characters. The following table lists the code specifications for all the code
sets of EUC.

                 DECIMAL            OCTAL              HEXADECIMAL
  Code set 0 (ASCII):
    first byte   033-126            041-176            21-7E
  Code set 1 (JIS X 0208-1990):
    first byte   161-254            241-376            A1-FE
    second byte  161-254            241-376            A1-FE
  Code set 2 (Half-width katakana):
    first byte   142                216                8E
    second byte  161-223            241-337            A1-DF
  Code set 3 (User-defined characters):
    first byte   143                217                8F
    second byte  161-254            241-376            A1-FE
    third byte   161-254            241-376            A1-FE
------------------------------------------------------------

Ken R. Lunde (lunde@adobe.com)'s extensive JAPAN.INF (version 1.2.) can
be found at

ucdavis.edu (128.120.2.1) in the pub/JIS directory, and at
msi.umn.edu (128.101.24.1) in the pub/nihongo directory.

in 3 parts:
  japan1.inf
  japan2.inf
  japan3.inf <- this part has all the appendices

size about 170K.

From CCNET-L@uga.cc.uga.edu Mon Oct 26 16:35:08 1992
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.67/5.10) with SMTP id AA07107; Mon, 26 Oct 92 16:35:00 -0500
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 6321; Mon, 26 Oct 92 16:31:13 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.08 PTF008) with BSMTP id
 4947; Mon, 26 Oct 92 16:31:11 EST
Date:         Mon, 26 Oct 1992 16:21:54 -0500
Reply-To: John McRae <jrm@CRUX2.CIT.CORNELL.EDU>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: John McRae <jrm@CRUX2.CIT.CORNELL.EDU>
Subject:      Code conversion software
Comments: To: ccnet-l <ccnet-l@uga.cc.uga.edu>, Ken Lunde <lunde@adobe.com>,
              "Richard F. Walters" <walters@tiger.eecs.ucdavis.edu>,
              Jon Wiederspan <jonwd@uwtc.washington.edu>,
              Jamie Hubbard <jhubbard@smith.BITNET>,
              Glenn Adams <glenn@ila.com>, Unicode List <unicode@sun.com>,
              Japanese Tchg + Inst'l Tech'gy <jtit-l@psuvm.BITNET>,
              Bill Tuthill <Bill.Tuthill@eng.sun.com>
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
Status: RO

Can anyone out there provide some guide as to what software now
exists for the conversion of data from one CJK-related character
code to another?  In addition, what tools for the creation of
such software (i.e., cross-referenced code tables and the like)
exists?

At the moment, I'm beginning to design a strategy for Cornell
to improve its treatment of CJK bibliographic records in our
various library collections.  Our original cataloguing is now
done through RLIN (Research Libraries Information Network),
using REACC (RLIN East Asian Character Code).  I do not think
this situation is likely to change in the immediate future,
nor am I recommending such a change.  However, I would like
to make it possible for us to download Cornell records from
the RLIN database and display them over the university's
fairly prodigious network system, using an appropriate
database package.  (I would be happy to learn whether RLIN
is planning to make such download and display capabilities
available from ordinary Macs and PCs, but that's another
topic.)

In order to display these bibliographic records, there would
have to be either a database that understands REACC, or some
process for converting records using REACC into Unicode (and
into a database program that understands Unicode) or, as a
stopgap measure until Unicode-capable database software is
on the market, conversion utilities to move the Chinese REACC
records into Big 5 format and the Japanese REACC records into
JIS (or shift-JIS) format.

I know there's a conversion utility for converting between
Guobiao and Big 5, but what about between REACC, Unicode,
Gig 5, and JIS?  And even if the conversion software does
not yet exist, don't the Unicode folks have cross-reference
tables to facilitate the creation of such software?

If you reply individually to me, I'll summarize to the ccnet-l
and Unicode lists.  If I get any response, that is...


==================================================================
John R. McRae
Assoc. Professor of East Asian Religions
Department of Asian Studies
Cornell University
Ithaca, NY  14853-2502
607/255-1328
fax:   -1686
e-mail:  jrm@crux2.cit.cornell.edu  (Internet)
         jrm@cornella.bitnet          (Bitnet)

P.S.  Mail sent to the jrm@cornella address will
automatically be forwarded to crux2.
==================================================================

From sol.ctr.columbia.edu!spool.mu.edu!agate!doc.ic.ac.uk!uknet!mcsun!news.funet.fi!ousrvr.oulu.fi!ousrvr.oulu.fi!tommi Sun Nov  1 17:06:50 EST 1992
Article: 1001 of alt.chinese.text
Xref: sol.ctr.columbia.edu soc.culture.china:71288 alt.chinese.text:1001
Path: sol.ctr.columbia.edu!spool.mu.edu!agate!doc.ic.ac.uk!uknet!mcsun!news.funet.fi!ousrvr.oulu.fi!ousrvr.oulu.fi!tommi
From: tommi@phoenix.oulu.fi (Tommi V Kaikkonen)
Newsgroups: soc.culture.china,alt.chinese.text
Subject: gb2pinyin filter
Message-ID: <TOMMI.92Nov1175859@phoenix.oulu.fi>
Date: 1 Nov 92 15:58:59 GMT
Sender: news@ousrvr.oulu.fi
Distribution: soc
Organization: Taidonkaari 1 E 36, 90570 Oulu, FINLAND
Lines: 93
Status: O

Ni hao! I have made one program which I would like to share with you all.
It is called gb2pinyin. This can be useful for producing for example
chinese GB (or hz2gb | gb2pinyin) text reading speech synthesizer
or learning how to pronounce some certain character.

You will need the TONEPY.tit input method dictionary from cxterm's
distribution package. If you don't have you, mail to me and I send it
to you.

A word of warning: This is a very alfa test release, I completly am
very beginner with chinese language and my program might be as well
worthless, but give it a try and send me comments!

Tommi Kaikkonen, tommi@phoenix.oulu.fi

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <malloc.h>

#define DICT "/usr/sbin/lib/cxterm/dicts/TONEPY.tit"

main()
{
  register int eka=0, toka=0, i=0;
  register char hz[4], **pipo=0;
  char **taulu=0, rivi[82];
  int rpit=0, tila=0, rraja=0;
  FILE *piffi=0;

  if ((piffi = fopen (DICT, "r")) == 0) {
    printf (stderr, "Error: unable to open pinyin dictionnary %s\n",
	    DICT);
    exit (-1);
  }
  if ((taulu = (char **)malloc (4096*sizeof(char *))) == 0) {
    printf (stderr, "Error: out of memory when allocating taulu\n");
    exit (-2);
  }
  pipo = taulu;
  while (1) {
    if (feof(piffi) || !fgets (rivi, 80, piffi)) {
      *pipo = 0;
      pipo[1] = 0;
      pipo[2] = 0;
      fclose (piffi);
      break;
    }
    rpit = strlen (rivi);
    rivi[rpit-1] = '\0';
    if (tila == 0) {
      if (!strncmp ("BEGINDICTIONARY", rivi, 9)) tila=1;
    } else {
      if (rivi[0] == '#') continue;
      if ((*pipo = (char *)malloc (rpit+8)) == 0) {
	printf (stderr, "Error: out of memory when allocating *pipo\n");
	exit (-3);
      }
      strcpy (*pipo, rivi);
      pipo++;
      if (++rraja >= 4096) {
	printf (stderr, "Error: out of memory when allocating *pipo...\n");
	exit (-4);
      }
    }
  }
  hz[2] = '\0';
  while (!feof (stdin)) {
    eka = getchar();
    if (eka < 0) break;
    if (eka & 128) {
      toka = getchar();
      if (toka < 0) break;
      hz[0] = (char)eka;
      hz[1] = (char)toka;
      for (pipo=taulu; pipo && *pipo; pipo++) {
	tila = 0;
	for (i=0; i<80 && (*pipo)[i] != '\t' && (*pipo)[i] != '\0'; i++);
	for (i++; i<80 && (*pipo)[i] && (*pipo)[i+1]; i+=2) {
	  if (hz[0] != (*pipo)[i] || hz[1] != (*pipo)[i+1]) continue;
	  else {tila=1; break;}
	}
	if (tila) {
	  for (i=0; i<80 && (*pipo)[i] != '\t'; i++) printf("%c", (*pipo)[i]);
	  printf (" ");
	  break;
	}
      }
    } else {
      printf ("%c", eka);
    }
  }
}


From CCNET-L@uga.cc.uga.edu Tue Nov 10 19:30:53 1992
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.67/5.10) with SMTP id AA12997; Tue, 10 Nov 92 19:30:45 -0500
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 4514; Tue, 10 Nov 92 19:26:58 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.08 PTF008) with BSMTP id
 4135; Tue, 10 Nov 92 19:26:53 EST
Date:         Sat, 7 Nov 1992 15:26:01 GMT
Reply-To: "Ross Paterson" <rap@DOC.IMPERIAL.AC.UK>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: "Ross Paterson" <rap@DOC.IMPERIAL.AC.UK>
Subject:      Unicode mapping tables
Comments: To: ccnet-l@uga.cc.uga.edu
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
Status: RO

The folks from Unicode have made two of their mapping tables available for
anonymous FTP.  They are in the directory pub/MappingTables on unicode.org.

To quote Asmus Freytag (VP Marketing, The Unicode Consortium):

> Unicode has a firm policy to NOT authorize redistribution of its
> tables by third parties.  While Unicode endeavours to get its
> mapping tables and similar implementation support into as many
> hands as possible, the Consortium feels that it is necessary
> to establish itself as the sole source of the "authorized" and
> "authentic" tables.  [...]
> This does not restrict the rights to share tables inside a company or
> organization nor the rights to incorporate the information present in
> the mapping tables in products supporting Unicode.

i.e. they'll get upset if you upload them to another FTP site.

One file, cjkxref.fix, gives a cross-referenced listing of various
standards for Hanzi.  The first 6 fields are:

1. Unicode: 4 hexadecimal digits
2. GuoBiao: S-rrcc, where S is one of
	0 = GB 2312-1980
        1 = GB 12345-1990
        3 = GB 7589-1987
        5 = GB 7590-1987
        7 = General use for Modern Chinese
        8 = GB 8565-1989
   and rr and cc are decimal numbers in the range 1-94, giving the row
   and column numbers.
3. BIG-5: 4 hexadecimal digits
4. CNS 11643-1986: L-XXXX (4 hexadecimal digits), where L is one of
	1 = Frequent characters
	2 = Less frequent characters
	E = extensions
   The first two levels are the two levels of BIG-5, minus the two
   characters C94A and DDFC, rearranged (in the same order) to fit in
   the range of graphic characters (A1-7E)
5. JIS:	S-rrcc, where S is one of
	0 = JIS X0208-1990.
	1 = JIS X0212-1990.
	I = IBM extensions (4 hexadecimal digits).
6. KSC: S-rrcc, where S is one of
	0 = KSC 5601-1987
	1 = some later standard

I don't know about the other 3.  Perhaps someone has the Unicode books?

The other file, namesall.lst, gives the Unicode standard names for the
non-Hanzi Unicodes.  The names of the Hanzi Unicodes are just their
Unicodes prefixed with "CJK UNIFIED IDEOGRAPH-".  Also omitted are the
thousands of precomposed Hangul blocks (which are probably the single
worst feature of Unicode, IMHO).

As has already been mentioned, the Hanzi set (variously called
UniHan, HCS or URO) unifies characters from various CJK standards.
Two characters seem to be unified if they have much the same form, but
simplified versions are not in general unified with the corresponding
traditional forms.  For example, the traditional (4 strokes) and
simplified (3 strokes) forms of the "grass" radical don't make for
different characters, but the two forms of the "speech" radical do.

Ross

From CCNET-L@uga.cc.uga.edu Tue Nov 17 12:56:06 1992
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.67/5.10) with SMTP id AA25565; Tue, 17 Nov 92 12:55:59 -0500
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 2931; Tue, 17 Nov 92 12:52:56 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.08 PTF008) with BSMTP id
 5043; Tue, 17 Nov 92 12:52:54 EST
Date:         Tue, 17 Nov 1992 12:56:07 +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

Hi everybody,
I just uploaded a convertion untility "sinocode.zip" and an info-file
on CJK-programms and utilities (cjk-prog.txt) to:

                   crl.nmsu.edu (128.123.1.14)
into the directory
                   /incoming

SINOCODE: converts between GB2312, BIG5 and JIS (also IBM555) in any
direction. The files come as a ZIP-file and a short sinocode.txt-file
with some information on usage. Everybody is wellcomed to use this
utility. Certainly there are still some omissions and mistakes in the
conversion tables. Any comment would be appreciated. The program does
not have intelligence to handle correctly one-to-many relations in
conversion, thus simplified to traditional conversion must be editied.

CJK-PROG: In this list I tried to collect as many information on as
many as possible cjk-programms and utilities. By now the list hase
grown to some 150 entries. The list also contains some addresses where
to get the software, also prices etc. With each piece of software I
tried to indicate: name of software, author, system and system requirements,
coding system used, input method, printers working with it, price,
availability of manual, where to get it (in case of freeware or shareware
also anonymous ftp sites), comments (if I myself or anybody else could
do some testing). For some software I could only provide some very marginal
information, I included it, because I thought it would still be useful
for people to get at least some hints where to look further.

If you think such a list useful and you like (or not) to use it, please
help me to update it. It is more work than I originally thought it would
be, but I still think it is helpful.

I would like to have more comments on the described software, so that the
novice user will profit more from such a list. At the moment it's more
a heap of accumulated and not well structured information.

Anyway, maybe you have some use for these two contributions

Urs

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

From CCNET-L@uga.cc.uga.edu Tue Dec  1 16:09:03 1992
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.67/5.10) with SMTP id AA18540; Tue, 1 Dec 92 16:08:49 -0500
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 1409; Tue, 01 Dec 92 16:05:46 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.08 PTF008) with BSMTP id
 0457; Tue, 01 Dec 92 16:05:44 EST
Date:         Tue, 1 Dec 1992 16:03:04 -0400
Reply-To: JHUBBARD%SMITH.BITNET@uga.cc.uga.edu
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: JHUBBARD%SMITH.BITNET@uga.cc.uga.edu
Subject:      SINOCODE Works Well for BIG5/GB --> JIS
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
Status: RO

I would like to extend a big THANK YOU to Urs Widmer for making his
SINOCODE program available. In addition to the many flavors of Chinese
code it translates, it also handles JIS code with no problems, as far as
my limited tests show. A major headache has been solved! One request, Urs:
since SINOCODE only handles EUC JIS, and DOS/V, Japanese Windows, etc. want
shift JIS, perhaps you could build in Ken Lunde's JIS.C code (which he
allows to be more-or-less freely used) to your program, thereby eliminating
one more step (JIS.C, or the compiled version thereof, handles conversion
among the various flavors of New-JIS, Old-JIS, Shift-JIS, EUC JIS, etc.).

At any rate, Thanks!  Jamie Hubbard

PS. SINOCODE is available at crl.nsmu.edu (128.123.1.14) under \pub\chinese.

From CCNET-L@uga.cc.uga.edu Thu Dec  3 10:02:27 1992
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.67/5.10) with SMTP id AA08112; Thu, 3 Dec 92 10:02:03 -0500
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 3562; Thu, 03 Dec 92 09:44:52 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.08 PTF008) with BSMTP id
 2649; Thu, 03 Dec 92 09:44:50 EST
Date:         Thu, 3 Dec 1992 14:37:42 GMT
Reply-To: Ross Paterson <rap@DOC.IMPERIAL.AC.UK>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: Ross Paterson <rap@DOC.IMPERIAL.AC.UK>
Subject:      Machine readable data
Comments: To: CCNET-L@uga.cc.uga.edu
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
Status: RO

I've just placed some data in a directory /incoming/hanzi-data on
crl.nmsu.edu.  Perhaps the directory could be moved to /pub/chinese.

Here is the README:

These are a number of files containing data about Hanzi.  The data is
incomplete and contains many errors -- I would appreciate suggestions,
corrections and additions, which I will incorporate into future versions.

Records end with linefeeds; fields are separated by tabs.

zidian - ASCII: [GB code, BIG-5 code, pronunciation, English meaning]
        This file was built by collating various partial relations,
        including GB/BIG-5 relations from Ed Lai's hypercard stacks,
        Fung F. Lee and Ricky Yeung's HC (some of which also comes from
        Ed Lai) and Urs Widmer's SINICODE, plus various input methods
        for both GB and BIG-5, some of which also derive from Ed Lai's
        hypercard stacks.  I've also checked a number of disagreements
        between the various sources and added a little data myself.

        The weakest part of the file is the English entries, which are
        taken from the file DOHERTY.SIN, from 'chinese.tar.Z' in the
        MetaFont distribution, and described as "the databank for some
        project in California".  The matching with character codes was
        mostly automated, based on pronunciation, radical and stroke
        count, so expect quite few errors.  And don't expect to understand
        Chinese words from these short character entries.

zidian.gb - ASCII/GB: [character, pinyin, English meaning]
        Automatically generated from 'zidian'.

zidian.b5 - ASCII/BIG-5: [character, pinyin, English meaning]
        Automatically generated from 'zidian'.

parts - ASCII: [character, radical, base character]
        This file gives analyses of characters into radicals and bases.
        The characters are represented by hexadecimal Unicodes; mappings
        to various CJK standards are available by anonymous FTP as

                unicode.org:/pub/MappingTables/cjkxref.fix

        Only the characters from GB0 and BIG-5 are covered so far, and
        800 of those are not yet done -- some are unanalysable, many
        I haven't got round to.  The radicals are the traditional 214,
        mostly as implied by the Unicode ordering; some are subdivided
        by adding various letters.  A base of '-' means empty; '?'
        means unknown.  A few of the bases are given as two characters,
        one for the traditional form of the whole character, and one
        for the simplified form.  At the end of the file are a few
        invented codes, starting with an 'X', for other common bases.
        Some of the analyses of GB characters used data from Ed Lai's
        GB hypercard stack.

radicals - ASCII: [radical, stroke count, extra strokes]
        This file gives stroke counts for the traditional ways of writing
        the various radicals.  Some radicals include a number of extra
        strokes that are normally included in the residue stroke count.

parts.gb - ASCII/GB: [character, radical, base character]
        Automatically generated from 'parts'.

parts.b5 - ASCII/BIG-5: [character, radical, base character, stroke count]
        Automatically generated from 'parts', with stroke counts mostly
        derived from the BIG-5 ordering.
--
Ross Paterson <rap@doc.ic.ac.uk>
Department of Computing, Imperial College, London SW7

From CCNET-L@uga.cc.uga.edu Fri Jan 29 08:36:54 1993
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.67/5.10) with SMTP id AA07916; Fri, 29 Jan 93 08:36:40 -0500
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 1929; Fri, 29 Jan 93 08:33:47 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.08 PTF008) with BSMTP id
 7918; Fri, 29 Jan 93 08:33:45 EST
Date:         Fri, 29 Jan 1993 11:58:16 GMT
Reply-To: Ross Paterson <rap@DOC.IMPERIAL.AC.UK>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: Ross Paterson <rap@DOC.IMPERIAL.AC.UK>
Subject:      Re: DO YOU KNOW IS10646 OR UNICODE
Comments: To: CCNET-L@uga.cc.uga.edu
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
Status: RO

Helena Wong <CSHWONG@CPHKVX.BITNET> asks:
>      Could anybody tell me about "the ISO/IEC DP10646 Multiple Octet Coded
> Character Set,  which now becomes International Standard IS10646".

[Maybe this should be in the FAQ list.]

ISO 10646 and Unicode began as competing standards.  The ISO philosophy
was approximately a disjoint union of national standards, yielding
a 32-bit code, while Unicode aimed at unifying identical characters
from different variants of the same script, to give a 16-bit code.
They have since been unified: ISO 10646 has two forms, a 32-bit form
and a 16-bit form.  The 16-bit form will be code-for-code identical with
Unicode, though some of the official names of characters differ.  It is
also a subset of the 32-bit form, the rest of which is so far undefined.
Perhaps it will be filled with presentation forms.

The overall layout of this unified 16-bit code is:

        0000 - 1FFF     Alphabets
        2000 - 2FFF     Symbols and Punctuation
        3000 - 4DFF     CJK Auxiliary
        4E00 - 9FFF     Unified Ideographs (20,902)
        A000 - DFFF     Reserved for future assignment
        E000 - FFFF     Restricted use

The only backward compatability is that 0000-00FF is identical to ISO
Latin-1, of which ASCII is the lower half.  (or maybe some non-Latin
alphabets are copies of existing standards at some offset.)

ISO standards are usually copyrighted and sold.  I don't know if this one
is available yet.  Unicode is fully described in

        "The Unicode standard : worldwide character encoding"
        (vols 1 & 2) the Unicode Consortium,
        Reading MA : Addison-Wesley, 1991-1992
        ISBN: 0-201-56788-1 (pbk. : v. 1)
        ISBN: 0-201-60845-6 (pbk. : v. 2)
        LC: QA76.76.C53U6

The volumes cost US$39.95 each.  Unicode is also making stuff available
for anonymous FTP; in unicode.org:pub/MappingTables/ you will find

        cjkxref.fix     a cross-reference between Unicode and various CJK
                        standards for Hanzi.  (Look through the CCNET-L
                        archive from last November for messages about
                        the format of this file.)
        namesall.lst    a list of official names of other characters.

In metis.com:pub/csmaps/ are more cross-reference tables, including CJK
punctuation, etc, but not checked as thoroughly as the above files.

There have also been some some proposals for variable-length encodings
of Unicode and ISO 10646.  One of them, UTF-FSS, is used as the standard
format of text files in Plan-9, an experimental next-generation Unix.
In this coding, existing ASCII files are also UTF files.  For more info,
see research.att.com:research/memo/utfman.{ps,asc} (log in as netlib).
--
Ross Paterson <rap@doc.ic.ac.uk>
Department of Computing, Imperial College, London SW7

From CCNET-L@uga.cc.uga.edu Sat Jan 30 21:32:10 1993
Return-Path: <CCNET-L@uga.cc.uga.edu>
Received: from uga.cc.uga.edu by ifcss.org (4.1/IFCSS-Mailer)
	id AA01494; Sat, 30 Jan 93 21:31:55 CST
Message-Id: <9301310331.AA01494@ifcss.org>
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 2466; Sat, 30 Jan 93 22:30:20 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.08 PTF008) with BSMTP id
 5905; Sat, 30 Jan 93 22:30:11 EST
Date:         Sat, 30 Jan 1993 22:23:25 EST
Reply-To: Yolin H u a n g <yih@BRL.MIL>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: Yolin H u a n g <yih@BRL.MIL>
Subject:      [glenn:  Re: What are the Character Sets?]
Comments: To: ccnet-l@uga.cc.uga.edu
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
Status: RO

  If you haven't seen this, here is a message about several codes for Han
script.  Among these, also more on the "EUC" code asked about earlier on
CCNet.  Quite a mind-boggling plethora.  Are they really in use?  What's
their respective relation to each National Standard?  What's the
advantage?  The variable length encoding is probably not that
straightforward to program.  But, thought software workers might find
this message useful.
  Glenn posted quite a few fine articles there on Usenet.  Hope he got
enough sleep.

----- Forwarded message # 1:

From: glenn@wheat-chex.ai.mit.edu (Glenn A. Adams)
Newsgroups: comp.std.internat
Subject: Re: What are the Character Sets?
Date: 16 Jan 93 20:51:05 GMT
References: <1j8knlINNf1j@flop.ENGR.ORST.EDU>
Organization: MIT Artificial Intelligence Laboratory
Lines: 317

In article <1j8knlINNf1j@flop.ENGR.ORST.EDU> crowl@jade.CS.ORST.EDU (Lawrence
 Crowl) writes:

>EUC

 Extended Unix Code, an ISO2022 8-bit compliant portmanteau encoding which
 is divided into four codesets (0-3), each of which serve as containers for
 different character set repertoires.

 Two encoding forms are defined in EUC systems, a variable length multibyte
 encoding intended primarily for interchange, and a fixed length encoding
 primarily intended for processing.  The variable length encoding is called
 a "multibyte character"; the fixed length encoding is called a "wide
 character," here wide means >8bits (nominally speaking).

 The multibyte encoding works as follows:  if bit7 of the first byte is
 zero, then it is a single byte encoding in codeset 0; if bit7==1 &
 byte0 != 0x8e|0x8f, then it is a multibyte encoding in codeset 1; if
 byte0 == 0x8e, then a multibyte encoding in codeset 2 follows; if
 byte0 == 0x8f, then a multibyte encoding in codeset 3 follows.  The
 single shift bytes, 0x8e and 0x8f, are called SS2 and SS3 in ISO2022
 terminology.

 Given that codesets can be mapped to different character repertoires,
 EUC is not a single character reperoire, but encodes families of repertoires;
 that is, there is not just one EUC encoding, but as many as you like.
 There are at least five common EUC encodings that I'm aware of:

 EUC-C  Chinese (PRC) Euc               Multibyte Length        Widechar Length
  codeset 0     ASCII                           1                       2
  codeset 1     GB 2312 1980                    2                       2
  codeset 2     undefined                       -                       -
  codeset 3     undefined                       -                       -

 EUC-H  Han (Taiwanese) Euc
  codeset 0     ASCII                           1                       4
  codeset 1     CNS 11643 1986 (plane 1)        2                       4
  codeset 2     CNS 11643 1986 (planes 2-255)   4*                      4
  codeset 3     undefined                       -                       -

 EUC-JX Japanese Euc
  codeset 0     ASCII                           1                       2
  codeset 1     JIS X 0208 1983                 2                       2
  codeset 2     JIS X 0201 1976                 2*                      2
  codeset 3     undefined                       -                       -

 EUC-JX Japanese Extended Euc
  codeset 0     ASCII                           1                       2
  codeset 1     JIS X 0208 1983                 2                       2
  codeset 2     JIS X 0201 1976                 2*                      2
  codeset 3     JIS X 0212 1990**               3*                      2

 EUC-K  Korean Euc
  codeset 0     ASCII                           1                       2
  codeset 1     KS C 5601 1987                  2                       2
  codeset 2     undefined                       -                       -
  codeset 3     undefined                       -                       -

 *includes one byte for the single shift code (0x8e or 0x8f)
 **recently added to EUC-J form an extended EUC-JX (I'm not sure what
   this is being called officially)

 As is clear from the above, there is not just one EUC encoding; nor is
 their one uniform set of EUC multibyte widths or one uniform wide character
 width ala Euc.  This can lead to difficulties in environments which wish
 to interoperate between different Euc platforms, especially since nothing
 in an Euc character string indicates which version of Euc applies.

>ISO 646

 =ASCII

>ISO 2022

 "Information processing -- ISO 7-bit and 8-bit coded character sets --
  Code extension techniques"

 A set of mechanisms whereby 7-bit and 8-bit encodings may be extended to
 incorporate characters not normally representable in a single 7-bit or
 8-bit encoding.

 7-bit extensions are achieved through the use of Escape (ESC), Shift-Out (SO),
 Shift-In (SI); 8-bit extensions are achieved through the use of these 7-bit
 extension mechanisms along with Locking-Shift Two (LS2), Locking-Shift Three
 (LS3), Single-Shift Two (SS2), and Single-Shift Three (SS3).  The semantics
 of these mechanisms and 37 different escape sequences are defined by this
 standard in order to achieve a generalized extension mechanism.

 The extensions supported by this standard revolve around three types of
 mechanisms: announcements, designations, and invocations.  Announcers are
 used to make explicit default assumptions and to provide information about
 what follows; designations are used to associate character repertoires
 with particular control mechanisms (invocation sequences); and invocations
 are the use of particular control or escape sequences to enable a mapping
 between a designated character repertoire and a set of codepoints (character
 code element values).

 The designation and invocation mechanism of ISO2022 is general enough to
 support multibyte encodings and arbitrary "other coding systems".  This
 "other coding system" allows for the incorporation of any kind of encoding
 system,  e.g., ISO10646 UCS2 (Unicode) or UCS4, in an ISO2022 conformant
 encoding string.  Both returnable and non-returnable other coding systems
 are supported.  [Returnable means that one can escape out of the other
 coding system without having to understand the other encoding system itself.
 ISO10646 UCS2 and UCS4 require the non-returnable mode since the means
 by which a return is implemented requires the recognition of the escape
 sequence ESC 2/5 4/0 (the three octets 0x33 0x25 0x40), e.g., this sequence
 would occur if the two ISO10646 UCS2 characters DIGIT THREE (0x0033) and
 FORMS UP HEAVY AND DOWN HORIZONTAL LIGHT (0x2540) occurred on a big endian
 machine, or if the characters SQUARED APAATO (0x3300) and HANGUL SYLLABLE
 LIEUL-YE-DIGEUD (0x4025) occurred on a little endian machine.  In contrast,
 all of the proposed UTF encoding forms of ISO10646 can use a returnable
 mode, since they preserve escape sequences.  It might be fair to say that
 an ISO2022 parser *could* be taught to recognize the invocation of certain
 other encoding systems, like ISO10646 UCS2 and UCS4; this is possible since
 the other coding system invocation sequences are known a priori.  In this
 case, the parser could switch its escape sequence parser to use 2-byte or
 4-byte encodings, by means of which it could recognize the 2-byte or 4-byte
 form of the return escape sequence: for UCS2 -- 0x0033 0x0025 0x0040; for
 UCS4 0x00000033 0x00000025 0x00000040.  The registry for ISO2022, ECMA,
 has already assigned invocation and designation sequences for ISO10646
 UCS2, UCS4, and UTF-1 encodings.]

>ISO 6937

 ISO6937-1

 "Information processing -- Coded character sets for text communication --
  Part 1: General Introduction"

 ISO6937-2

 "Information processing -- Coded character sets for text communication --
  Part 2: Latin alphabetic and non-alphabetic graphic characters"

 ISO6937-2 AD 1

 "Information processing -- Coded character sets for text communication --
  Part 2: Latin alphabetic and non-alphabetic graphic characters Addendum 1"

 ISO6937-3

 "Information processing -- Coded character sets for text communication --
  Part 3: Control Functions for Page-image Format"

 ISO6937-7

 "Information processing -- Coded character sets for text communication --
  Part 7: Greek graphic Characters"

 ISO6937-8

 "Information processing -- Coded character sets for text communication --
  Part 8: Cyrillic graphic Characters"

 A series of standards developed by ISO/TC97 which, among others, represents
 the needs of Library and Bibliographic communities.  Both 7-bit and 8-bit
 encodings are provided according to ISO2022 encoding techniques and ISO6429
 control function definitions.

 One difference from ISO6937 and other character sets like ISO8859-* is its
 explicit use graphical symbol composition by means of combining characters,
 in particular, characters which represent diacritics, accents, and other types
 of non-spacing marks.

 ISO6937 differs from ISO10646 (& Unicode) in its use of combining characters
 in two different ways:

  (1) it uses a prefix rather than a postfix encoding of combining characters;
      i.e., a combining character precedes the base character to which it
      is applied; and

  (2) it explicitly limits (and specifies) all combinations which may occur
      (ISO10646 does not limit combinations).

>ISO 8859

 A series of 8-bit character sets which conform to ISO2022 8-bit
 encoding techniques.  There are currently six parts which cover various
 Latin script based alphabets (with more on the way); there is one
 for Greek, one for Cyrillic, one for Hebrew, and one for Arabic.  All
 of these incorporate ISO646 as the G0 encodings (2/0 through 7/14).

 ISO Latin1 is another name for ISO8859-1.

>ISO 10646

 "Information technology -- Universal Multiple-Octet Coded Character
  Set (UCS) -- Part 1: Architecture and Basic Multilingual Plane"

 accepted in June 1992, to be published in 1993.

 Basic multilingual plane (BMP) is derived from Unicode 1.0 with some minor
 additions and changes.  Defines two encoding forms UCS2 and UCS4, for
 universal character set 2-byte form, and universal character set 4-byte
 form.  UCS2 is equivalent to UCS4 with the upper 16 bits equal to zero
 in the UCS4 form.  Only 31-bits of UCS4 are usable for encoding, the MSB
 is reserved and MBZ.

 The goal of the ISO10646 basic multilingual plane is to support the
 encoding of of written languages on a world-wide scale.

 No characters are currently defined in ISO10646 outside of the basic
 multilingual plane.

>JIS

 One of any number of Japanese Industrial Standards produced by the
 Japanese Standards Association, such as JIS X 0201, JIS X 0208, JIS X 0212.
 JIS X 0201 (1976) defines two 7-bit character sets and an 8-bit character
 set.  The first 7-bit character set is equivalent to ASCII except for code
 position 5/12, which has the YEN SIGN instead of BACKSLASH and code
 position 7/14, which has an OVERSCORE isntead of TILDE; the second 7-bit
 set contains Katakana symbols in what is called the "hankaku" or half-
 width form (as compared with the normal width of a Kanji glyph, which
 is called "zenkaku," or full-width form).  The 8-bit set is the union
 of the two 7-bit sets, with the hankaku katakana located in the G1
 space (10/0 through 15/15) of which only 10/1 through 13/15 are used.

 JIS X 0208 (1983) defines a set of 6353 Kanji characters, 169 Kana
 characters, 166 Latin, Greek, and Cyrillic characters, 10 numeral
 characters, 147 special characters, and 32 ruled line element characters,
 a total of 6877 characters.  The characters are organized according to
 "wards" which are blocks of 94 characters that are easily mapped into
 the ISO2022 G0 code set (2/1 through 7/14 = 94 codepoints).  Kanji
 characters in this standard are divided into two sets: 2965 level 1
 Kanji, and 3388 level 2 Kanji.  The two different levels are ordered
 according to different principles:  level 1 is ordered phonetically,
 level 2 is ordered by radical and stroke count, with ties in radical
 and stroke count broken by onyomi phonetic order.  The phonetic order
 applied to level 1 Kanji operates by choosing a representative "On-Kun"
 an onyomi (Japanized Chinese pronunciation) or kunyomi (indigenous
 Japanese pronunciation); ties in "On-Kun" are broken by ordering by
 onyomi alone followed by kunyomi alone; further ties are broken by
 radical order then stroke count.  All JIS X 0208 require two bytes
 for their encoding; JIS X 0208 is designated and invoked in an 7-bit
 ISO2022 conformant string by the escape sequence ESC 2/4 4/2; in an
 8-bit ISO2022 conformant string, it is designated by the same escape
 sequence, and invoked by Shift-In (SI).

 JIS X 0212 (1990) defines a set of nearly 6,000 additional kanji which
 were not included in JIS X 0208.  These kanji are ordered like those
 of level 2 in JIS X 0208, i.e., by radical, stroke count, then onyomi.

>Runic

 A cute name given by AT&T Plan 9 designers to ISO10646 UCS2 (Unicode)
 fixed width 16-bit encodings.  These 16-bit encodings are there called
 "runes".  [I really hate cute names that give absolutely no information
 and are misleading.  In my opinion, this term should not be used for
 this purpose, particularly since ISO10646 UCS2 (Unicode) will eventually
 have the actual Rune characters included.]

>UCS-2
>UCS-4

 See above under 10646.

>UTF

 UCS Transformation Format.  The first such format, defined in Annex F
 of DIS 10646-1.2:1992(E).  Nowadays called UTF-1 to distinguish it from
 other transformation formats.

>UTF-2

 File System Safe UTF (FSS-UTF), an alternative transformation format defined
 by Ken Thompson, and used in the Plan 9 operating system.

>Unicode

 A character set defined and promoted by Unicode, Inc., a non-profit
 consortium of computer hardware and software manufacturers, library
 and bibliographic organizations, information service providers, and
 individual members.  Unicode is derived from earlier work in the design
 of multilingual software support done by Xerox and Apple Computers.

 The Unicode Worldwide Character Set Standard, Version 1.0, Volume 1 was
 published by Addison Wesley in the fall of 1991 at a time when the first
 draft of DIS10646 was being voted on; the vote failed and discussions of
 a merger began, with the subsequent production of the second draft of
 10646 in December 1991 which used Unicode 1.0 as a basis for the basic
 multilingual plane.  Volume 2 of the Unicode standard, containing the
 Han character encodings of Unicode 1.0, was published by Addison Wesley
 in late summer 1992.  Subsequent to the successful vote for the second
 draft of DIS10646 in June 1992, Unicode 1.0.1 was published as an addendum
 to Unicode 1.0; Unicode 1.0.1 is a proper subset of the ISO10646 basic
 multilingual plane.  Unicode 1.1 is scheduled for release in the near
 future as a technical report which makes Unicode code for code identical
 to the basic multilingual plane of ISO10646.

 Unicode has the goal of encoding the characters needed to support the
 representation of all the written languages of the world, including those
 no longer written today.  It also had the goal of supporting interoperability
 with imporant existing character sets; consequently, Unicode is a superset
 of most character sets used in computer systems today worldwide.  As
 defined by the Unicode standard, a character code element constitutes a
 16-bit unsigned integral value in the range 0x0000 through 0xffff; somewhat
 more than half of these 65,536 code elements are now assigned to characters
 from nearly 25 different scripts.  A small number of scripts are not yet
 represented by Unicode, but have draft encodings which are now being
 reviewed by concerned parties:  Burmese, Ethiopic, Khmer, Sinhalese,
 and Tibetan (the Tibetan encodings in Unicode 1.0 will be removed by
 Unicode 1.1 because they were removed from ISO10646 pending further study).
 A number of other scripts used by relatively small communities or by
 historical writing systems, such as the vertical Mongolian script, Cree,
 Cherokee, Egyptian, etc., are being studied for further inclusion in a
 future version of Unicode.

 Two important features of Unicode are its unification of Chinese, Japanese,
 and Korean uses of Han characters (hanzi/kanji/hanja) into a single collection
 of unified CJK characters, and its support for the arbitrary combination of
 non-spacing marks in order to create novel or unusual (i.e., hard to
 ascertain) graphical symbol composites (an extremely imporant feature for
 bibliographic uses and for representing minority alphabets).

Glenn Adams
Cambridge, Massachusetts


----- End of forwarded messages

From CCNET-L@uga.cc.uga.edu Tue Feb  2 17:54:04 1993
Return-Path: <CCNET-L@uga.cc.uga.edu>
Received: from uga.cc.uga.edu by ifcss.org (4.1/IFCSS-Mailer)
	id AA23741; Tue, 2 Feb 93 17:53:58 CST
Message-Id: <9302022353.AA23741@ifcss.org>
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 3613; Tue, 02 Feb 93 18:52:22 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.08 PTF008) with BSMTP id
 2911; Tue, 02 Feb 93 18:52:19 EST
Date:         Tue, 2 Feb 1993 15:50:53 PST
Reply-To: Roger Hart <hartr@NICCO.SSCNET.UCLA.EDU>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: Roger Hart <hartr@NICCO.SSCNET.UCLA.EDU>
Subject:      Hanzi conversion utilities
Comments: To: CCNET-L@uga.cc.uga.edu
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
Status: RO

I need to convert EACC code to BIG5 code.  I have found a conversion table
cjkxref.fix which has lists corresponding codes for EACC, BIG5, UNICODE,
etc.  What I need now is to find a program (hopefully on unix) that
will make the substitutions using that table.  Can anyone offer any
suggestions??

Thanks,

Roger Hart
UCLA

From CCNET-L@uga.cc.uga.edu Thu Feb 11 21:00:38 1993
Return-Path: <CCNET-L@uga.cc.uga.edu>
Received: from uga.cc.uga.edu by ifcss.org (4.1/IFCSS-Mailer)
	id AA16728; Thu, 11 Feb 93 21:00:29 CST
Message-Id: <9302120300.AA16728@ifcss.org>
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 8481; Thu, 11 Feb 93 21:58:25 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.08 PTF008) with BSMTP id
 4948; Thu, 11 Feb 93 21:58:22 EST
Date:         Thu, 11 Feb 1993 21:48:34 EST
Reply-To: Yolin H u a n g <yih@BRL.MIL>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: Yolin H u a n g <yih@BRL.MIL>
Subject:      Re:  EACC (NC Z 39.64) to BIG5 converter
Comments: To: ccnet-l@uga.cc.uga.edu
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
Status: RO

{ I am looking for a utitlity that will map the three-byte code used by
{ libraries (EACC or NC standard Z 39.64) to BIG5.  Any platform--unix,
{ mac, or pc--is fine.

  I was going to say, cjkxref.fix is definitely a better place to start.
And there are excellent programmers around.  But, since most CCNet people
don't have access to EACC database (?), and therefore won't find the
need, and won't spend their time and headache over it.

  Now, here is (first) an evangelium (kind of): the Bell Lab "Plan 9"
action team has just announced an utility (see below) to map between
several different code sets around their UTF code (which seems to be a
derivative/ variant of the Unicode).  So that, the AT&T's lead in the
world multi-lingual computer market is secured.  However, their
understanding of Big5 seems to have come from the cxterm, and haven't got
it right yet (all the codings are such a blackbox; can't really blame
ZYG).  Looks like, the correction will take a while to reach there.
  This seems to be byfar the most versatile mapping utility.  If all
major EACC-users, schools, organizations inundate them with ernest-worded
petitions with authoritative underwritings, they might turn their head
and add EACC into this utility, and it will become the most versatile yet.

  Then, the bad news is that, I can't still make this piece to work
right; either it's still too buggy, or I was too dizzy at the moment.

  But, cjkxref.fix is still the better.  Maybe several major schools can
put together a project, and get funding to work on a good mapping utility,
carousel around all the codes covered in cjkxref.fix table; can learn
from good graphic format converters, such as imtools; suppose there is
this code mapping tool cmt, such that

        cmt -in eacc -out b5 < text.eacc > text.b5

And cmt -h will give all the formats it can handle.

  Maybe the National Endowment for the Arts will consider this to worth
more than bizarre picture shows ...

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

From: andrew@research.att.com
Date: Tue, 9 Feb 93 01:06 EST

        The Plan 9 utility for translating between character sets
is now available by anonymous ftp from research.att.com in the
file dist/tcs.shar.Z. It requires ANSI/ISO C and comes with some
regression tests and a manual page. it understands the following
character sets (output from tcs -lv):
        utf     UTF encoding from XOPEN
        utf1    UTF encoding from 10646
        ascii   7-bit ASCII
        8859-1  Latin-1 (Western and Northern Europe, including German and Itali
an)
        latin1  ISO 8859-1
        8859-2  Latin-2 (Eastern Europe except Turkey and the Baltic countries)
        8859-3  Latin-3 (The Mediterranean Area and South Africa; obsolete)
        8859-4  Latin-4 (Scandinavia and the Baltic countries; obsolete)
        8859-5  Part 5 (Cyrillic)
        8859-6  Part 6 (Arabic)
        8859-7  Part 7 (Greek)
        8859-8  Part 8 (Hebrew)
        8859-9  Latin-5 (Turkey, Western Europe including Scandinavia)
        kio8    KIO-8 (recommended)
        kio8x   KIO-8 (alternate)
        cyr1    mystery DOS Cyrillic encoding
        jis     XJIS
        big5    Big 5 (HKU)
        gb      GB2312-80
        unicode Unicode 1.0

share and enjoy.

                        andrew hume

From CCNET-L@uga.cc.uga.edu Fri Feb 12 08:58:18 1993
Return-Path: <CCNET-L@uga.cc.uga.edu>
Received: from uga.cc.uga.edu by ifcss.org (4.1/IFCSS-Mailer)
	id AA26406; Fri, 12 Feb 93 08:58:11 CST
Message-Id: <9302121458.AA26406@ifcss.org>
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 2050; Fri, 12 Feb 93 09:55:37 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.08 PTF008) with BSMTP id
 2901; Fri, 12 Feb 93 09:55:34 EST
Date:         Fri, 12 Feb 1993 15:51:55 +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>
Subject:      EACC-conversion
Comments: To: ccnet-l@uga.bitnet
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
Status: RO

Hi everybody,
there seems to be quite a lot of questioning about EACC-code conversion
to other coding scheems. Since I have made a convertion utility for
GB-2312,JIS,KIS,BIG-5 I would like to extend it to handle EACC.
I have already here the xref-file from UNICODE, which contains all
the necessary code mappings. What I would need is a (short) document
coded as EACC with a partial translation into a more common coding
scheem (for verification). Only with such a *real* thing at hand I
would like to begin my venture.

Thanks in advance
Urs

PS.: What I mean. please send me a short file.

From @UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU Mon Feb 22 10:22:23 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 AA14692; Mon, 22 Feb 93 10:22:01 CST
Message-Id: <9302221622.AA14692@ifcss.org>
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 6678; Mon, 22 Feb 93 11:18:22 EST
Received: from UGA.BITNET (NJE origin LISTSERV@UGA) by UGA.CC.UGA.EDU (LMail
 V1.1c/1.7e) with BSMTP id 5100; Mon, 22 Feb 1993 11:18:21 -0500
Date:         Mon, 22 Feb 1993 11:20:03 -0500
Reply-To: "D-P Deng (O-516-282-2197,~{5K6,F=~})" <deng@BUNNY.RHIC.BNL.GOV>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: "D-P Deng (O-516-282-2197,~{5K6,F=~})" <deng@BUNNY.RHIC.BNL.GOV>
Subject:      gb2pinyin.c
Comments: To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
Comments: cc: tommi@phoenix.oulu.fi
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
In-Reply-To:  Your message of "Sat,
              20 Feb 93 00:55:48 EST." <9302200611.AA08829@bunny.rhic.bnl.gov>
Status: RO

I received a few request to find the source codes for gb2pinyin. I enclose
README file from Tommi, the author. It's best to put it some archive sites. I
checked ahkcus.org and ifcss.org, it's not there.

Have fun.

Dong-Ping

README
gb2pinyin lets usual ASCII characters to pass-by, but the characters
over 128 (decimal) will be translated according to their tone pinyin
pronounciation. Tone pinyin is a way to write spoken chinese with
roman characters.

1. Configure the following line in gb2pinyin.c for your local system
#define DICT "/usr/sbin/lib/cxterm/dicts/TONEPY.tit"

2. run make

3. Enjoy!

4. Mail (bug reports;-) to tommi@phoenix.oulu.fi

Tommi

From @UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU Sun Feb 28 11:08:11 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 AA25942; Sun, 28 Feb 93 11:08:05 CST
Message-Id: <9302281708.AA25942@ifcss.org>
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 6104; Sun, 28 Feb 93 12:03:23 EST
Received: from UGA.CC.UGA.EDU (NJE origin LISTSERV@UGA) by UGA.CC.UGA.EDU
 (LMail V1.1d/1.7f) with BSMTP id 8905; Sun, 28 Feb 1993 12:03:20 -0500
Date:         Sun, 28 Feb 1993 12:05:11 -0500
Reply-To: "~{QG9p~}" <yawei@BRONZE.UCS.INDIANA.EDU>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: "~{QG9p~}" <yawei@BRONZE.UCS.INDIANA.EDU>
Subject:      Re: Classification and Techniques of Chinese Character System on
              DOS
Comments: To: ccnet-l@uga.cc.uga.edu
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
Status: RO

Thanks to Mr. Xu Yueheng for the very informative article posted
to CCNET.

I just have two points to raised concerning ZWDOS.

(1) The HZ Chinese code used in ZWDOS and other software packages
is not really a new standard. It differs from CCDOS in the way
it distinguishes Chinese codes and ASCII codes, but the Chinese
code used in HZ and ZWDOS is exactly GB2312.

(2) ZWDOS is not just BIOS compatible with MSDOS. It also allows
direct access to the text mode video buffer. This is essential
since most MSDOS application programs writes directly to the
video buffer. Since this is a software implementation the scrolling
speed will not be as good as ASCII scrolling (on Hercules video
cards the scrolling speed is comparable to ASCII though), but
it is video direct access-compatible with MSDOS programs.


Finally, I am a little curious about how the government controls
what type of system is sold on the market. I read on People's Daily
about the ban on non-standard systems, and now I hear it from
Mr. Xu again.  Mr. Xu also says this ban is "by law".  Does Mr.
Xu has more detail about this?  Which Chinese law is being applied
to this ban, specifically? and How?  Does this ban apply only to
Chinese character coding, or does it apply to other technologies and
products as well?  (I can't imagine a law is written to single
out the character coding standard for protection.)

I think it is not wise to enforce official standards by law.
It can only inhibit technological advancement and market competition.
It takes time for a standard to be formulated and adopted, which
means it is impossible for a standard to include the latest
technological advances and innovations. I can understand the
desire to have systems being compatible with each others, but
there are other better ways of achieving this, inhibiting
innovation is too high a price to pay for compatibility.


  Ya-Gui Wei

From @UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU Thu Apr  1 08:40:23 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 AA11854; Thu, 1 Apr 93 08:40:08 CST
Message-Id: <9304011440.AA11854@ifcss.org>
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 7251; Thu, 01 Apr 93 09:36:28 EST
Received: from UGA.CC.UGA.EDU (NJE origin LISTSERV@UGA) by UGA.CC.UGA.EDU (LMail V1.1d/1.7f) with BSMTP id 7959; Thu, 1 Apr 1993 09:36:26 -0500
Date:         Thu, 1 Apr 1993 09:37:31 EST
Reply-To: FARZ000 <FARZ%NMUMUS.BITNET@uga.cc.uga.edu>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: FARZ000 <FARZ%NMUMUS.BITNET@uga.cc.uga.edu>
Subject:      New Software Announcement: HC 3.0
Comments: To: CCNET-L@UGA.CC.UGA.EDU
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
In-Reply-To:  In reply to your message of TUE 30 MAR 1993 22:04:26 EST
Status: RO

I've made an announcement on the network.  Since I don't subscribe to
CC-NET, would you please post it to CC-NET for me, thanks.  -Ricky


Software Release Announcement: Hanzi Converter 3.0
==================================================

Hanzi Converter (HC) 3.0 is now available for ftp on ifcss.org.  This
version supports the showing of multiple mappings; and the conversion
table has been revised and many corrections have been made.

unix version
    ifcss.org:software/unix/hc-30.tar.Z

mac version (this is a lazy version, doesn't have the usual Mac GUI):
    ifcss.org:software/mac/convert/hc-3.0L.hqx

dos version
    ifcss.org:software/mac/convert/hc-30.zip



hc(1)                    USER COMMANDS                      hc(1)



Name
     Hanzi Converter, hc - convert a GB file to a BIG-5 file,  or
     a BIG-5 file to a GB file

Syntax
     hc -m _ m_ o_ d_ e -map _ m_ a_ p_ p_ i_ n_ g [ -t _ t_ 1 _ t_ 2 ... ] < fi
le

Description
     The program converts a GB file to a BIG-5 file, or  a  BIG-5
     file  to  a  GB  file.   GB (GuoBiao) refers to the standard
     implementation of "GB2312-80" of Mainland  China,  in  which
     the  two bytes representing a GB code have their most signi-
     ficant bit set to 1.  BIG-5 refers to the Big Five  standard
     published  in  1984  by  Taiwan's  Institute for Information
     Industry. Currently, most popular Chinese systems  and  pro-
     grams use either GB or BIG-5.

     The possible options are

     -m   Conversion mode, either g2b or b2g, for GB to BIG-5, or
          BIG-5 to GB, respectively.

     -map Mapping mode, either one, all, or allbutsymbols.  Since
          the  mapping  between GB and BIG-5 is not unique, users
          may request the translation to return  the  first  map-
          ping,  all  the mappings, or all the mappings for hanzi
          but only one mapping for symbols (e.g.  there  are  two
          "comma" glyphs defined in BIG-5).

     -t _ f_ i_ l_ e_ s
          Specify the hanzi conversion table files, usually  just
          "hc.tab" as described below.


Conversion Table File Format
     The table file contains newline-terminated mapping  entries.
     Each  entry is a two-byte GB code followed by a list of two-
     byte BIG5 codes.  Each entry line cannot exceed 256  charac-
     ters.   Users may build their own separate table files.  The
     bundled conversion table file is called "hc.tab".


Copyright
     Copyright (C) 1988,1989,1990,1993  Fung  F.  Lee  and  Ricky
     Yeung

     All Rights Reserved.

     This program and the  table  file  are  NOT  in  the  public
     domain.

     You may copy and distribute verbatim  copies  of  hc  source



                Last change: March 12 1993                   1






hc(1)                    USER COMMANDS                      hc(1)



     code  files,  table  file(s), and documentation files as you
     receive it for non-commercial purposes.

     If you wish to incorporate parts of hc into other  programs,
     write  to  the authors.  We have not yet worked out a simple
     rule that can be stated here, but we will often permit this.

     This software is provided "as is" without  warranty  of  any
     kind,  either  expressed or implied, including, but not lim-
     ited to, the implied warranty of fitness  for  a  particular
     purpose.


Authors
     Ricky Yeung and Fung F. Lee

Bugs
     Bug   reports   and   comments    should    be    sent    to
     Ricky.Yeung@eng.sun.com or lee@umunhum.stanford.edu


Disclaimer
     This software is provided "as is" and the  authors  disclaim
     all  warranties with regard to this program and the correct-
     ness of the mapping table file.

     This software has no connection with our employers.

From mleisher@NMSU.Edu Tue Apr  6 21:26:19 1993
Return-Path: <mleisher@NMSU.Edu>
Received: from NMSU.Edu (dns1.NMSU.Edu) by ifcss.org (4.1/IFCSS-Mailer)
	id AA28042; Tue, 6 Apr 93 21:24:42 CDT
From: mleisher@NMSU.Edu
Received: from pylos (pylos.NMSU.Edu) by NMSU.Edu (4.1/NMSU-1.18)
	id AA02061; Tue, 6 Apr 93 20:23:49 MDT
Date: Tue, 6 Apr 93 20:23:49 MDT
Message-Id: <9304070223.AA02061@NMSU.Edu>
Received: by pylos (4.1/NMSU)
	id AA27800; Tue, 6 Apr 93 20:23:48 MDT
To: soft-authors@ifcss.org
Subject: Re: Extending HZ
Status: RO

Almost forgot.  For info on Japanese coding, I have a file called
'japan.inf' by Ken Lunde that describes most of the major Japanese
encodings.

crl.nmsu.edu:pub/japanese/japan.inf  [128.123.1.18]

-----------------------------------------------------------------------------
mleisher@nmsu.edu
Mark Leisher
Computing Research Lab                    "Elegance is not optional!"
New Mexico State University                  -- Attributed to Richard O'Keefe
Box 3CRL, Las Cruces, NM  88003

From lai@apple.com Wed Apr  7 12:06:40 1993
Return-Path: <lai@apple.com>
Received: from apple.com by ifcss.org (4.1/IFCSS-Mailer)
	id AA03515; Wed, 7 Apr 93 12:04:24 CDT
Received: by apple.com (5.61/7-Aug-1992-eef)
	id AA02130; Wed, 7 Apr 93 10:02:45 -0700
	for soft-authors@ifcss.org
Date: Wed, 7 Apr 93 10:02:45 -0700
From: Ed Lai <lai@apple.com>
Message-Id: <9304071702.AA02130@apple.com>
To: soft-authors@ifcss.org
Subject: Re: Extending HZ
Status: RO


If you consider the number of printable character, then HZ scheme can
be used to cover 96*96=9216 characters for every two byte pair. That is
not enough to cover all of big-5 code. So for big-5 code three bytes are
needed at least in some cases.

Pai Chou in TaipeiTerm uses 3 bytes for every big-5 char and it actually
works quite well.

However, a lot of the big-5 characters are almost never used. And if it
is an extension of HZ it is better to be upward compatiable. I think the
people who wants big-5 code is more interested in reading traditional
character. They can do it to some extent now with a gb traditional font.
The problem are those n:1 mapping of simplified to tradtional characters.
So really the idea is to extend the gb, using the unused character space
in gb to include these muliple mapping tradtional characters.

Fung Fung Lee had discussed this issue before and called it extended GB,
so I would leave it to him to discuss it again. I just want to add a few
suggestions. I think there is a PRC standard that came after gb80 that
cover this problem, so that can be used. If not, we may pick some
commerical system like TianMa that let you switch between simplied
and traditional font. It is likely that they are already using such an
extended gb characters set and we can adopt it.

If it is felt that it is still necessary to cover the rest of the Big5 code,
then we can have an escape character so that the Big5 code with no
GB/extended GB equivalent will have a 3 (or maybe 4) bytes
representation.

To summarize again, we can have an extended gb character set that we are encourage to use.

1. For people who want to keep using simplied character, if they use
existing software, they may miss a few characters, but often it can be corrected just by using a slightly larger font file. The various HZ
software can be upgraded to remap these characters either because
it is more space efficient than a bigger font file, or in the case where
it is not practical to have a larger font file (e.g. the software is
depending on the Chinese system to display the characters).

2. For people who want to read it as traditional character, they can
use an extended gb font file in traditional character.

3. For people who want to use extened HZ from a Big5 system, when
the file is displayed, it will be converted from extended GB to Big5.
When they want to post from a Big5 system, the code will be
translated from Big5 to extended GB.


/* Disclaimer: All statments and opinions expressed are my own */
/* Edmund K. Lai                                               */
/* Apple Computer, MS37-AS                                     */
/* 20525 Mariani Ave,                                          */
/* Cupertino, CA 95014                                         */
/* (408)974-6272                                               */
zW@h9cOi


From yawei@bronze.ucs.indiana.edu Wed Apr  7 12:55:57 1993
Return-Path: <yawei@bronze.ucs.indiana.edu>
Received: from bronze.ucs.indiana.edu by ifcss.org (4.1/IFCSS-Mailer)
	id AA04052; Wed, 7 Apr 93 12:52:25 CDT
Message-Id: <9304071752.AA04052@ifcss.org>
Received: by bronze.ucs.indiana.edu 
Date: Wed, 7 Apr 1993 12:50:38 -0500
From: ~{QG9p~} <yawei@bronze.ucs.indiana.edu>
To: lai@apple.com, soft-authors@ifcss.org
Subject: Re: Extending HZ
Status: RO


An extended GB scheme would certainly add more characters. I've
heard that China already has extended the GB table to include
more characters (GB level 2?), just never seen any detail about
it.

One problem with an extended GB scheme is that it probably 
won't support simultaneous simplified and traditional character
displays.

An extended HZ scheme can have a lot of room to play if you
are willing to consider other tilde- sequences.  We may, for
example, use ~{ for GB2312 (as we do now), use ~( for Big-5,
etc.  Since there are a max possible 92 tilde- sequence to
be exploited, an extended HZ scheme can support a max of
   92x94x94 = ~800,000
characters!  This is about 12 times more than Unicode can
accomodate.:-)

 Ya-Gui


From chou@cs.washington.edu Wed Apr  7 21:16:27 1993
Received: from june.cs.washington.edu by ifcss.org (4.1/IFCSS-Mailer)
	id AA09977; Wed, 7 Apr 93 21:12:32 CDT
Received: by june.cs.washington.edu (5.65b/7.1ju)
	id AA14489; Wed, 7 Apr 93 19:11:27 -0700
Date: Wed, 7 Apr 93 19:11:27 -0700
From: chou@cs.washington.edu (Pai Chou)
Return-Path: <chou@cs.washington.edu>
Message-Id: <9304080211.AA14489@june.cs.washington.edu>
To: soft-authors@ifcss.org
Subject: Re: Extending HZ
Cc: chou@cs.washington.edu
Status: RO

>>Date: Wed, 7 Apr 93 10:02:45 -0700
>>From: Ed Lai <lai@apple.com>
>
>>Pai Chou in TaipeiTerm uses 3 bytes for every big-5 char and it actually
>>works quite well.
>
>Since Pai Chou (chou@june.cs.washington.edu) is on this list
>(soft-authors@ifcss.org), perhaps he can give us a brief introduction
>to his "T3" code.

Hi everybody,

Here is the documentation file for Taipei-100 and the T3 code.
Sorry I have a paper deadline on Monday, so I can't promise
to reply mails promptly.

Pai

(September 3, 1990)

Encoding Format: T3
-----------------------

Design Considerations
---------------------

   The 3-byte "T3" encoding is designed for 2-byte BIG-5
encoding.  This encoding method satisfies several criteria:

1 Only printable ASCII characters are used (i.e. [$20-$7E]).
   In effect, line feeds and escape characters are preserved.

2 Given any line without the knowledge of surrounding lines,
   the terminal emulator can always correctly display Hanzi.
   This is important for text editors, where you can be jumping
   back and forth between lines.

3 Maintain character integrity.  That is, one ASCII contributes
   to exactly one Hanzi's encoding, but never to more than one.

4 To comfortably cover the entire BIG-5 range (13051 chars)
   without using a lookup table or very complicated encoding
   method (such as variable-length Huffman encoding, etc).
   No complex mathematical operations are required: the most
   complex operation is multiply by 5, which can be synthesized
   using an add and a shift.

   To satisfy the first criterion, we can use at most 95 different
values per character.  Two ASCII's can therefore represent
95**2 = 9025 different Hanzi, which is not enough for the entire
set (13051) -- which violates criterion #4.  This does not even
include any escape sequences to distinguish Hanzi from Romazi.

   One attempt to satisfy criterion #2 is to have an escape
sequence to signify either Hanzi or Roman mode that follows
until another escape sequence or upon reaching the end of
the line.  However, to satisfy criteria #3, and #4, each Hanzi
requires three ASCII's to encode anyway, so the extra escape
sequences will waste space.

   My solution is to use two characters as escape characters:
` and ^.  I avoided ~ because the UNIX mail program uses it
as an escape character for invoking commands from the mail
message.  ` and ^ are not used frequently in regular mail or
news messages.  To make encoding easier, since `_^ are
three consecutive ASCII characters, _ is not used either. 
This results in 95-3 = 92 different values for the remaining
two bytes following the `^ escape.  Therefore, a total of
92**2 = 8464 different values can be represented.  But since
there are two escape characters, they can also contribute to
the encoding as well.  As a result, the total number of
representable characters using the three-character sequence
= 8464 * 2 = 16928.  In reality, the T3 format uses only 89
different values for the first byte, so a total of 89 * 92 * 2
= 16376 can be represented, which is still comfortable for BIG-5.



Encoding format
----------------

   A Big-5 encoding consists of two bytes. 
The first byte has the range of $A1-$F9, or 89 different
values.  It can easily be assigned to its own byte.
The algorithm is

=============
var
(* import *)
    bs: char;  (* higher byte's source *)
(* export *)
    bt: char;  (* higher byte's target *)

   bt := bs - $A1 + $21;
   if bt >= '^' then bt := bt + 3;
=============

   The second byte, however, is trickier.  The range of the
second byte is $40-$7E, $A0-$FE, with a few last-digit F's
missing.  But let's just treat them as if the range were
$40-$7F, $A0-$FF.

   The lower-order nibble can stay where it is.

   The upper nibble has the range [4,5,6,7,A,B,C,D,E,F], or 10
different values.  Since each ASCII can hold at most 92 values,
92 / 16 = 5.75.  It can represent at most 5 different values in
the upper nibble.

   The solution comes from the use of two different escape
characters.  Nibbles in the set [4,5,6,7,A] are assigned the
` escape, while those in [B,C,D,E,F] get ^.

The set [4,5,6,7,A,B,C,D,E,F] get mapped to [0,1,2,3,4,5,6,7,8,9],
modulo 5, and multiplied to the lower nibble.

The algorithm is
=============
var
  (* Import *)
      BS: char;  (* Lower byte's source *)
  (* Export *)
      BT: char;  (* Lower byte's target *)
      BE: char;  (* escape byte *)
  (* Utility *)
      LN, HN: integer; (* lower and upper nibble *)
 
      LN := AND( BS, $F );
      HN := AND( SHIFT_RIGHT(BS, 4), $F );
      if HN > $7 then HN := HN - 6 else HN := HN - 4;
      BT := OR( LN, Shift_Left( (HN mod 5), 4) ) + $21;
      if BT >= '^' then BT := BT + 3;
      if HN >= 5 then BE := '^' else BE := '`';
=============


To Map from ASCII to BIG-5 is not difficult.

var
  (* import *)
   T0, T1, T2: char; (* 3-byte encoding *)
  (* export *)
   B0, B1: char;  (* 2-byte BIG-5 encoding *)
  (* utility *)
   HN: integer; (* higher nibble *)

(* first, you should make sure it's a legal sequence *)
   if (T0 in ['`', '^'])
      and (T1 in [$21..'^'-1, '`'+1..$7E])
      and (T2 in [$21..'^'-1, '`'+1..$7E]) then begin

     if T1 > '`' then B0 := T1 - $3 - $21 + $A1 else B0 := T1 - $21 + $A1;
     if T2 > '`' then B1 := T2 - $3 - $21 else B1 := T2 - $21;
     HN := AND( Shift_Right( B1, 4 ), $F );
     if T0 = '^' then HN := HN + 5;
     if HN <= 3 then HN := HN + 4 else HN := HN + 6;
     B1 := OR( Shift_Left( HN, 4 ),  AND( B1, $F) );
  end;


Using T3 code in Taipei-100
--------------------------

Taipei-100 does the conversion between Big5 and T3 on the fly,
for every character typed or displayed.
When you type normally, you probably are not aware of this
translation until you do backspace, or when you move the
cursor to the middle of a Hanzi in a text editor such as vi or
emacs.  This is because to delete a Hanzi, you must kill three
bytes on the UNIX side; similarly, to move the cursor over a
Hanzi, you must move it three times on the UNIX side.

   Taipei-100 makes it explicit in these situations.  It displays
the Hanzi as the three bytes that UNIX sees when the cursor
is in the middle of the three-byte sequence.

   For example, suppose you typed

   [ H1 ]  [ H2 ]  [ H3 ]  [ H4 ]  [ H5 ]  [ H6 ] |
    gong1   xi3     fa1     cai2    hong2   se4
   which says Congratulations and Be Prosperous (for the new year)
         so (Give Me the)  Red  Color ...;  | denotes the cursor.

  Oops - you meant to type "red envalope" (hong2bao1).  The last Hanzi
is represented on the UNIX side by ^&S, so when you backspace
once, you see

    [ H1 ]  [ H2 ]  [ H3 ]  [ H4 ]  [ H5 ] ^ &|
    gong1   xi3     fa1     cai2    hong2

where the last S was deleted.  This way, you see that you need
to delete two more characters to erase the entire Hanzi.
Finally, after deleting two more ASCII's, you can type the
correct character over, and you get the correct result.


   There is one case where you might need to hit backspace
four times.  When the last character is a backslash, which can
be used as the "quoting" character in UNIX, the first backspace
gets quoted (replacing the backslash), and the next three
backspaces actually erase the characters.

   When you run a text editor (vi, emacs), if the cursor is not at
Hanzi boundaries, then the character gets displayed as the
three byte sequence, but it is restored as soon as the cursor
moves to Hanzi boundaries.  For example,

     [ H1 ] [ H2 ] ` 5|P  [ H4 ]


shows the cursor (|) in the middle of the third Hanzi.


vi-mouse and emacs-mouse
---------------------------

  Taipei-100 makes the 3-byte sequence explicit to the user
when the cursor is placed in the middle of a Hanzi.  This lets
the user know how many more characters to delete or move.
However, this could become a dread to the user, because the
computer must recompute and update the screen every time
the cursor is moved.  It slows down the response time, and
switching between the 3-byte sequence and Hanzi can be
confusing if not annoying.

   To alleviate this problem, I implemented vi-mouse and
emacs-mouse.  By simply clicking the mouse at the desired
target location, Taipei-100 generates the cursor-movement
commands to place the cursor there.

   Vi-mouse is invoked by holding down the command-key
(clover) while clicking the mouse button.  YOU MUST BE IN THE
_INSERT_MODE_ in vi.  This is particularly useful when editing
Hanzi, because it places the cursor at Hanzi boundary.

   Emacs-mouse is invoked by holding down the Option key
while clicking the mouse button.  If you hold down both
the Command-key and the Option-key, then Taipei-100
generates vi-mouse commands.

   Unfortunately, Taipei-100's cursor-mouse commands do
not always place the cursor accurately when the line is
indented (i.e. begins with a blank or a tab), or if you use
line numbers in vi.  There is no solution to this problem.



From yawei@bronze.ucs.indiana.edu Wed Apr  7 23:51:14 1993
Return-Path: <yawei@bronze.ucs.indiana.edu>
Received: from bronze.ucs.indiana.edu by ifcss.org (4.1/IFCSS-Mailer)
	id AA11283; Wed, 7 Apr 93 23:46:43 CDT
Message-Id: <9304080446.AA11283@ifcss.org>
Received: by bronze.ucs.indiana.edu 
Date: Wed, 7 Apr 1993 23:42:38 -0500
From: ~{QG9p~} <yawei@bronze.ucs.indiana.edu>
To: mcpong@cs.ust.hk, soft-authors@ifcss.org
Subject: Re:  HBF Std v1.0
Status: RO


So I guess the HBF business is done for now.  Hope you guys
are ready for something different.

The following proposal is for a HZ-like spec for mixing
ASCII, GB, Big-5, and possibly others in the same documents.

An example of the mixed text would look like,

    aaa~{gbgbgbgb~(b5b5b5b5~+B5~(b5b5b5b5b5b5~}aaaaaa

I am hoping that big-5 can be cleanly divided into two sections,
where the most frequently used characters are in one section
and the less frequently used ones in the other.  This is quite
important.  (The "B5" in the above example represents the less
frequently used section, switching to it requires two sets of
2-byte escapes, requiring a total of 6 bytes for the character.)

More detail follows.

  Ya-Gui

--


      A Proposal To Extend the Current "HZ" Specification
   To Accommodate Other East Asian Coding Standards (Draft 1.0a)


                         Ya-Gui Wei
                       April 07, 1993


The "HZ" representation (Fung Fung Lee, 1990) of GB2312 Chinese text
has been implemented in various software packages under different
platforms, and tested in the usenet newsgroup "alt.chinese.text" and
various other forums with considerable success. This proposal seeks
to expand the specification to _simultaneously_ accommodate other
East Asian coding standards under an umbrella scheme that is
analogous to the original "HZ" scheme.

This proposal is first posted to soft-authors@ifcss.org to solicit
comments, and may be posted to other forums at a later time.


  * ESSENSE of "HZ"

The "HZ" standard defines a way of integrating ASCII characters with
GB2312 Chinese characters (represented as two printable ASCII
characters). The following ASCII sequences are defined as special:

   ~{    --  escape from ASCII to GB2312
   ~}    --  escape from GB2312 to ASCII
   ~~    --  the ASCII character ~
   ~\n   --  line continuation

"HZ" further stipulates that an ASCII new line sequence serves
as an automatic escape back to ASCII. Furthermore, the ~\n line
continuation sequence is permitted in the ASCII context only.


  * CONSOLIDATION OF CODES

I hereby propose to extend the "HZ" specification to create a
Consolidated Collection of East Asian Coding Standards (CCEACODE,
hereafter), to allow for the simultaneous transport of text of the
different languages or coding standards.

Briefly, all the remaining tilde- sequences of "HZ" will be defined as
special under CCEACODE, which will be used as escape signals for
transition among East Asian Language (EAL, hereafter) code blocks,
as well as between EAL code blocks and ASCII.

CODE BLOCKS: Code Blocks of 93 rows-by-94 columns will be defined
by CCEACODE, with each character within an code block represented
by two printable ASCII characters. 

If two consecutive characters are from the same code block, no
special attention is needed. If two adjacent characters are
from different code blocks, a special tilde- sequence is inserted in
between to signal the transition between code blocks.

For example, if ~{ is used for transition into GB (Chinese) text,
and ~[ is used for transition into Japanese JIDOS text, and ~} is
used for transition into ASCII text, then examples of mixed ASCII,
GB and JIDOS text may look like:

      aaaa~{gbgbgbgb~[jijijiji~}aaaa
      aaaa~[jijijiji~{gbgbgbgb~}aaaa



  * PROPERTIES

- Large Code Space. CCEACODE can accommodate 92 code blocks, with
each block having 93 rows, and each row having 94 characters. This
results in a code space of up to 804,000 characters, or 19.6 bit
equivalence, while each character takes up only about 14 bits in the
data stream. (Contrast this to 16-bit schemes, which would have a
mere 65,000 character code space, with each character taking up 16
bits in the data stream.)

- CCEACODE will be a superset of ASCII. Under CCEACODE, ASCII text
will remain as 7-bit (single-byte) characters, with no need to widen
them into multiple byte sequences. The only exception being that an
ASCII "~" character will be represented by the two byte "~~" sequence.
(Contrast this to 16-bit uniform width schemes, which would widen each
ASCII character to 16 bits.)

- CCEACODE will be a superset or partial superset of all the East Asian
coding standards it seeks to accommodate.

- CCEACODE will be a superset of the original "HZ" Specification.

- CCEACODE encoded multilingual text will be indistinguishable from
ASCII text at the byte level, thus ensuring compatibility with existing
software and hardware.


  * SUPPORTED CODING STANDARDS

CCEACODE does not attempt to define any of the characters within its
code space. Instead, its code space will be allocated to the various
national or industrial coding standards in blocks, and individual
characters will be defined by these national or industrial coding
standards. CCEACODE will also standardize the tilde- escape
sequences and the exact positioning of national/industrial standard
character sets within the CCEACODE code space.

Only standards of wide-spread recognition and/or prominence will
be accommodated in CCEACODE.

Code blocks, each 93x94 in size, are allocated to accommodated
standards by assigning a tilde- special sequence to the standard,
indicating that text following the sequence will be interpreted
using the said standard.

Proposed CCEACODE tilde- special sequence assignments (undefined
tilde- sequences are reserved for future expansion):

   ~}    --  escape to ASCII
   ~{    --  escape to Chinese GB2312
   ~(    --  escape to Chinese Big-5 primary 
   ~+    --  escape to Chinese Big-5 secondary
   ~[    --  escape to Japanese (JIDOS?)
   ~]    --  escape to Korean (standard?)
   ~~    --  the ASCII character ~
   ~\n   --  line continuation (in ASCII context only)
   \n    --  new line, with implied escape to ASCII
	     (\n = new line sequence, may be platform-specific.)



  * NAME OF THE GAME

This proposed specification is tentatively named "Consolidated
Collection of East Asian Coding Standards", with acronym CCEACODE
(pronounced "see code").

I have intentionally avoided the term "Unified" in the name so as
to avoid discussions of "Han Unification". I am not against "Han
Unification" per se, but I believe it has its weekness and it is 
incompatible with the spirit of accommodating existing standards.


[End of Document]



From Ricky.Yeung@Eng.Sun.COM Thu Apr  8 14:15:52 1993
Return-Path: <Ricky.Yeung@Eng.Sun.COM>
Received: from Sun.COM by ifcss.org (4.1/IFCSS-Mailer)
	id AA16807; Thu, 8 Apr 93 14:01:05 CDT
Received: from Eng.Sun.COM (zigzag-bb.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1)
	id AA21203; Thu, 8 Apr 93 11:59:51 PDT
Received: from hk.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1)
	id AA19376; Thu, 8 Apr 93 11:59:50 PDT
Received: by hk.Eng.Sun.COM (4.1/SMI-4.1)
	id AA14491; Thu, 8 Apr 93 12:00:16 PDT
Date: Thu, 8 Apr 93 12:00:16 PDT
From: Ricky.Yeung@Eng.Sun.COM (Ricky Yeung)
Message-Id: <9304081900.AA14491@hk.Eng.Sun.COM>
To: soft-authors@ifcss.org
Cc: Ricky.Yeung@Eng.Sun.COM
In-Reply-To: Fung Fung Lee's message of Wed, 7 Apr 93 12:17:28 -0700 <9304071917.AA27124@fritter.Stanford.EDU>
Subject: Re: Extending HZ
Content-Length: 1992
Status: RO



  >   Actually I thought about this issue again last year after the establishment
  >   of alt.chinese.text, and had a private discussion with Ricky Yeung
  >   about two possible schemes.  As we didn't perceive enough interests back
  >   then, we stopped working on it.
  >   I would leave it to Ricky to discuss the schemes.

Here are some notes that I recall from our discussion last year:

- As in HZ, ~{ ~} is the only esc sequence to switch between ASCII and
  non-single byte codes.

- For codes other than GB, the HZ coding would be ~{~x ... ~} where x
  indicates what coding scheme the following codes are in.
  For examples,
  	BIG5   		~{~T.......~}
  	Unicode		~{~U.......~}
  	Japanese	~{~J.......~}
  	Korean		~{~K.......~}

Issues:

+ This scheme simplies the implementation of HZ filters that don't want
  to or can't handle other coding schemes.

+ For BIG5 codes, we can either "Qui Wei"lize (segment :-) it into
  three-byte codes (like Pai Chou's T3 code?) or have two portions of
  BIG5, and use ~t for the less frequently used codes.

+ One question rasied was that should we allow switching code schemes
  inside HZ?  My inclination was that its added complexity may not be
  justified (to save 8 bytes per switch), since mixing codes are not
  very common. 

  Examples:

  Mixing GB and BIG5, if not supporting switching inside:  

    ~{xxxxxx~}~{~Txxxxx~}~{xxxxx~}

  If supporting internal switching:

    ~{xxxxxx~Txxxxx~Gxxxxx~}	assuming ~G for GB

+ Internal switching can be added as a future expansion, though.

+ For Unicode, we can either "Qui Wei"lize it into three-byte ASCII
  codes, or just use the four-byte numeric code.

+ We discussed the use of other escape sequences for BIG5, like ~[ ~]
  and ~( ~).  I thought it's not general enough and suggested the above.
  Also Fung Lee pointed out the fact that the characters like (, ), [,
  ,] can occur as the 1st byte in GB, which could be visually confusing
  if used for mode switching.

-Ricky


From lee@fritter.Stanford.EDU Tue Apr 13 13:50:07 1993
Return-Path: <lee@fritter.Stanford.EDU>
Received: from fritter.Stanford.EDU by ifcss.org (4.1/IFCSS-Mailer)
	id AA27272; Tue, 13 Apr 93 13:48:24 CDT
Received: by fritter.Stanford.EDU (5.57/Ultrix3.0-C)
	id AA06385; Tue, 13 Apr 93 11:47:27 -0700
Date: Tue, 13 Apr 93 11:47:27 -0700
From: lee@fritter.stanford.edu (Fung Fung Lee)
Message-Id: <9304131847.AA06385@fritter.Stanford.EDU>
To: soft-authors@ifcss.org
Subject: Taiwan BIG5 service
Status: RO

For those who may not have read the following interesting announcement on
alt.chinese.text, I am forwarding the message.
I've just tried connecting to gopher.csie.nctu.edu.tw, and discovered many
other intereseting services in Chinese (BIG5).
I wonder if there are similar services in Hong Kong and (Mainland) China ?

-F.F. Lee

===============================================================================
>From nntp.Stanford.EDU!headwall.Stanford.EDU!agate!howland.reston.ans.net!newsserver.jvnc.net!news.edu.tw!news!news.csie.nctu.edu.tw!skhuang Mon Apr 12 22:53:43 PDT 1993
Article: 3614 of alt.chinese.text
Newsgroups: alt.chinese.text,csie.announce,tw.talk
Path: nntp.Stanford.EDU!headwall.Stanford.EDU!agate!howland.reston.ans.net!newsserver.jvnc.net!news.edu.tw!news!news.csie.nctu.edu.tw!skhuang
From: skhuang@csie.nctu.edu.tw (Shih-Kun Huang)
Subject: For BIG5 users in Taiwan
Status: RO
Message-ID: <C5EoCM.M5y@csie.nctu.edu.tw>
Apparently-To: <sycheng@csie.nctu.edu.tw>
Sender: usenet@csie.nctu.edu.tw
Reply-To: skhuang@csie.nctu.edu.tw
Organization: Computer Sci. & Information Eng., Chiao-Tung U, Taiwan, ROC
X-Newsreader: TIN [version 1.1 PL6]
Date: Tue, 13 Apr 1993 04:55:34 GMT
Approved: sycheng@csie.nctu.edu.tw
Lines: 33

Most of the Chinese environements in Taiwan  are using Big5 code and
articles in this group are in HZ. If users in Taiwan intend to 
read TW Big5 news and at the same time read HZ code, they cannot
conveniently switch between environments. Using pipe through
different conversion tools is not very convenient.  We provide
an "extra" service in our "gopher" server to let Twiwan users
view HZ articles directly. We convert HZ articles in alt.chinese.text
into BIG5 and repost them in our local groups. If you are using
BIG5 environment, you can try to read alt.chinese.text in BIG5 by
"gopher gopher.csie.nctu.edu.tw 70"
 or
"telnet gopher.csie.nctu.edu.tw 4270" 

And select "Documents, FAQ, RFC,..." topic. 
You must note your gopher or telnet client is 8-bits clean.
(gopher must be compiled by SYSV curses if you are using BSD systems)

Bugs: we cannot preserve author information as in the original form.
      and you can't followup or post. 
This service seems to be extraeous in some aspects. But if people don't
think so, we can allocate another service to let user post articles
in another group (in Taiwan local group) and this article will be
sent to a filter. It  will convert BIG5 article into HZ automaticllay.      
And repost into alt.chinese.text. 
Viewing news articles through gopher won't be slow if you are in Taiwan.
Our gopher server takes advantage of "tin index" and it is just a
little slower than "tin" reader.

Any comments and suggestions please sent to "help@csie.nctu.edu.tw"
--
Shih-Kun Huang			|  Huang2 Shih4-Kun1
skhuang@csie.nctu.edu.tw	| 


From @UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU Sat Apr 17 00:16: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 AA27982; Sat, 17 Apr 93 00:16:35 CDT
Message-Id: <9304170516.AA27982@ifcss.org>
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 6839; Sat, 17 Apr 93 01:12:08 EDT
Received: from UGA.CC.UGA.EDU (NJE origin LISTSERV@UGA) by UGA.CC.UGA.EDU (LMail V1.1d/1.7f) with BSMTP id 7754; Sat, 17 Apr 1993 01:12:06 -0400
Date:         Sat, 17 Apr 1993 13:15:40 CST
Reply-To: student <cs80147@CHPI.EDU.TW>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: student <cs80147@CHPI.EDU.TW>
Subject:      Encoding BIG-5 !!
Comments: To: CCNET-L@uga.bitnet
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
Status: RO

     Yon can find program by (ftp 140.111.2.22
 /pub/pc/compress/TOADUU@).ZIP [DDUU20.ZIP).
                  Thank you for your interested.   Tony Lin.

From @UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU Sun Apr 18 14:29:40 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 AA12457; Sun, 18 Apr 93 14:29:36 CDT
Message-Id: <9304181929.AA12457@ifcss.org>
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 8805; Sun, 18 Apr 93 15:24:42 EDT
Received: from UGA.CC.UGA.EDU (NJE origin LISTSERV@UGA) by UGA.CC.UGA.EDU (LMail V1.1d/1.7f) with BSMTP id 1514; Sun, 18 Apr 1993 15:24:40 -0400
Date:         Sat, 17 Apr 1993 23:39:52 -0400
Reply-To: Liedong Zheng <lz@FLYNN.CHEM.COLUMBIA.EDU>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: Liedong Zheng <lz@FLYNN.CHEM.COLUMBIA.EDU>
Subject:      mac version of gb2pinyin
Comments: To: ccnet-l@uga.bitnet
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
Status: RO

Hi:
        Tommi Kaikkonen's unix version of gb2pinyin is ported to mac. It is
compressed by compact pro, and self-extractable, archived on
ifcss.org:software/mac/convert/gb2pinyin.hqx. The readme file is included FYI.

Liedong

------------------gb2pinyin.readme-------------------------------------------
                             gb2pinyin.readme



This is a quick-n-dirty port of Tommi Kaikkonen's  unix version of
gb2pinyin. It does NOT have usual Macintosh interface. All credits
should go to Tommi Kaikkonen <tommi@phoenix.oulu.fi>

gb2pinyin  translates GB encoding to tone pinyin (chinese), and is amid to
help those whose native language is not Chinese.

How to use it:

Make sure the application gb2pinyin and the dictionary file TONEPY.tit are in
 the same folder. Lunch gb2pinyin by double-
clicking on its icon. On the console window, click on the file radio
button under Standard Input, and select a file that you want to
convert, click on the file radio button under Standard Output, and
give a destination file name, optionally put a "-m" for mutiple
search on the command line. Click OK, and you are all set.

Please report bugs to Liedong Zheng  at
<lz@flynn.chem.columbia.edu>

The following is the man page from  Tommi Kaikkonen's original
program.


Liedong Zheng

--------------included-------------------------
gb2pinyin reads the standard input and writes to standard output.

Option -m switches gb2pinyin to search for every possible way to
say the GB characters. Without option -m gb2pinyin treats every
characters according to its first translation in the TONEPY.tit file.

gb2pinyin lets usual ASCII characters to pass-by, but the
characters over 128 (decimal) will be translated according to their
tone pinyin pronounciation. Tone pinyin is a way to write spoken
chinese with roman characters.

This translator can be used as a filter.

File TONEPY.tit is used as translation dictionnary.

---------------------------------end-------------------------------------------

From @UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU Tue May 11 13:20:34 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 AA24956; Tue, 11 May 93 13:20:19 CDT
Message-Id: <9305111820.AA24956@ifcss.org>
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 5954; Tue, 11 May 93 14:18: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 4771; Tue, 11 May 1993 14:18:44 -0400
Date:         Tue, 11 May 1993 17:20:03 BST
Reply-To: "L.S.Ng" <L.S.Ng1@SOUTHAMPTON.AC.UK>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: "L.S.Ng" <L.S.Ng1@SOUTHAMPTON.AC.UK>
Subject:      improve GB (was Why I need Big5)
Comments: To: shann%wangwei.math.ncu.edu.tw@nsf.ac.uk
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
In-Reply-To:  <no.id>; from "Shann Wei-Chang" at May 11, 93 9:57 pm
Status: RO

A PROPOSAL to encode Non-standard Chinese Characters
****************************************************


I suggest a solution to Non-standard Charaters:

Aim: To code and display non-standard Characters WHEN NECESSARY.

Method: Include the BITMAP INFORMATION of a non-standard characters WITHIN an
ordinary document. The decoder should read this info and be able to display it.

Assign to a non-standard character a TEMPORARY Guobiao/HZ code which can be any
place in the blank region (region 8 to 15). So as the temporary non-standard
character appear in the text, the decoder will use the BITMAP info to display
it.

Format: To comply with SMTP, use a string of hexadecimal numbers to represent
the bitmap.  For 16x16 bitmap we need 32 bytes, so the hex number equivalent
would be 64 character long. The bitmap info is preceeded by the temporary GB/HZ
code. And all this info can fit into one single line only which should begin
with an identifier. e.g.

zKA8011234ABCDEFAB12345678098374859283BEFA394DCB3948CBDE948503948ABCD..
  ˆ   ˆall this are bitmap info in Hex number, length=64 for 16x16 bitmap
ˆ A801 the temporary GB/HZ code
identifier zK

Extension: For larger bitmap, more lines can be used.

Software:
1. It requires easy to use/flexible font editor. The font editor should be able
to code the bitmap info in Hex number.
2. It requires a text editor which can cut and paste the bitmap info into a
document.
3. The decoder should handle standard GB/HZ coding and when it encounters a
non-standard character, it reads the bitmap info to display it.

Please send your comment to l.s.ng1@mail.soton.ac.uk

--------------------
In reply to Shann:
> Sending Big-5 code is NOT such an achievement.  If you have "less", try to
> "setenv LESSCHARSET=latin1" then you can view Chinese, Big-5 or GB, in an
> cxterm.  (Hence you don't need "cless".)  Thus sending Big-5 or GB
> codes without encoding is an equivalent problem with sending latin1
> codes, which include most of the West European characters not defined
> in ASCII, like $\'e$, $\"u$, $\cc$ (these are TeX notations, you can
> guess what they are).

Thanks for these tips.

>
> The world is not going to update sendmail JUST for Big-5 code.  This update
> will be needed and appreciated by users of latin1 codes.  I tried some ftp
> programs and found they are already latin1 compatible.  I "set ascii"
> during an ftp session, then send Big-5 or GB codes.  Then I check, they
> are correct.  That means "ascii" already includes "latin1", hence GB and
> Big-5 are preserved.  Although I am not a computer scientist, but as
> a scientist in general, I can guess the technical difficulty to update
                                          ˆˆˆˆˆˆˆˆˆ
> sendmail to be compatible with latin1 cannot be too much more difficult
> then updating ftp.

ftp is different from SMTP. It has to be agreed by ALL institutions within the
Internet. The former can just be implemented separatly. It is a CULTURAL issue
rather than a TECHNICAL one.

>
> > ... Why use BIG5 at all? Do we need 12000
> > characters (in BIG5) if 7000 (in GB/HZ) is sufficient?


> Since you said you received 10 posting from me.  I guess you are on
> CHPOEM-L also.  Then you must know that, for instance, Dr. Deng and friends
> have input exerts from Hong Lou Meng.  They did it by GB code.  Some > > >
characters
  ˆˆˆˆˆˆˆˆˆˆ
> were missing and they have to describe a character by saying it is A on left,
  ˆˆˆˆˆˆˆˆˆˆˆˆ
> B on right but without C.  This is why I need Big-5, or even more, sometimes
> I need the standard Library code with 30K+ characters (but this code is
> definitely not necessary for usual use).  Big-5 has 5401 frequently used
> codes, it is sufficient for everyday use and can be somehow implemented
> similar to HZ (some good soul is doing that, I believe).  The rest of Big-5
> is sufficient for most ancient works that we may encounter from time to
> time, including Hong'Lou'Meng`, Shi_Jing, Gu^Shi_19, Tang'Shi_300, etc.
>

It seems that neither Big5 nor GB is sufficient for non-standard Chinese
Characters. Your 30K++ character library cannot be a universal solution. Say
a poor student wants to read your document using e-mail, how can that be done?
You have to send him the whole character library, don't you?

**Seriously and Important**

I suggest a solution to Non-standard Charaters:

Aim: To code and display non-standard Characters WHEN NECESSARY.

Method: Include the BITMAP INFORMATION of a non-standard characters WITHIN an
ordinary document.

The decoder should read this info and be able to display it. Assign to a non-
standard character a TEMPORARY Guobiao/HZ code which can be any place in the
blank region (region 8 to 15). So as the temporary non-standard character
appear in the text, the decoder will use the BITMAP info to display it.

Format: To comply with SMTP, use a string of hexadecimal numbers to represent
the bitmap.  For 16x16 bitmap we need 32 bytes, so the hex number equivalent
would be 64 character long. The bitmap info is preceeded by the temporary GB/HZ
code. And all this info can fit into one single line only which should begin
with an identifier. e.g.


zKA8011234ABCDEFAB12345678098374859283BEFA394DCB3948CBDE948503948ABCD..
  ˆ   ˆall this are bitmap info in Hex number, length=64 for 16x16 bitmap
ˆ A801 the temporary GB/HZ code
identifier zK

Extension: For larger bitmap, more lines can be used.

Software: Need easy to use font editor. The font editor should be able to code
the bitmap info in Hex number. The text editor can cut and paste the bitmap
info into a document.

> Now, do you have a feeling why I need Big-5?
>
> I can guess why you hate Big-5.  Because you were educated in simplified
> characters.  Why don't you change mode and thinking in my term.  On the
> contrary I was educated in traditional characters.  But I do want to
> communicate with my far-brothers like you.  I did my part, I installed
> programs to convert GB or HZ to Big-5, and sometimes I can just read
> simplified characters directly.  Why don't you also do it for me, if you
> care to communicate.  It won't be harder then to communicate in English,
> I guess.
> > I just hope that you Taiwanese will discard BIG5 and adopt GB/HZ for you
> > email posting.
>
> Let's do it democratically.  Time will resolve it.
>
> > We are all tired of uudecoding BIG5 documents unless someone will
> > create a SMTP-compliant-BIG5-variant coding scheme like HZ for GB.
>
> If you care to communicate, it is easy to write a C shell script to
> simplify the process of converting from Big-5 to HZ or GB.  I can
> write one for you if you are using UNIX.
>
> Cheers,
>
> -Shann
>

Thanks for your attention
liangsheng wu

From @UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU Tue May 11 15:44:14 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 AA27346; Tue, 11 May 93 15:44:04 CDT
Message-Id: <9305112044.AA27346@ifcss.org>
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 3183; Tue, 11 May 93 16:43:10 EDT
Received: from UGA.CC.UGA.EDU (NJE origin LISTSERV@UGA) by UGA.CC.UGA.EDU (LMail V1.1d/1.7f) with BSMTP id 9907; Tue, 11 May 1993 16:43:08 -0400
Date:         Tue, 11 May 1993 16:36:28 EDT
Reply-To: Jianlin Chang <chang@MJS.PHY.QUEENSU.CA>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: Jianlin Chang <chang@MJS.PHY.QUEENSU.CA>
Subject:      MIME for sending for non-US ASCII mail (Re: Why I need Big-5)
Comments: To: ccnet-l@uga.bitnet
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
Status: RO

Maybe many people didn't realize that, the growing standard for sending non-US
ASCII code mail is the MIME (Multipurpose Internet Mail Extensions) as specfied
in RFC 1341. This standard is for sending mail containing  audio, video,  Asian
language  text, or even text in most European languages. It add a Content-Type
header field which  can be used to specify the type and subtype of data in the
body of a message and  to  fully specify  the  native  representation
(encoding) of such data. Th body is encoded in some standard way. Upon
receiving the mail, the mail reader will perform appropriate actions according
to the Content-Type header field as specifed in the "mailcap" file. For
example, if the mail reader find audio header, it will just play it on the
audio device, if it find image header, it will start image view program to view
the program, it it find non-US ASCII charator set, it just start the
application to view the mail. Simply by adding an entry in "mailcap" file,
the mail reader can recognize new date types and perform new actions.

Why don't we look at this proposed standard before talking about new standards?

From yawei@cs.indiana.edu Thu May 13 09:40:33 1993
Return-Path: <yawei@cs.indiana.edu>
Received: from mako.cs.indiana.edu by ifcss.org (4.1/IFCSS-Mailer)
	id AA27664; Thu, 13 May 93 09:36:19 CDT
Message-Id: <9305131436.AA27664@ifcss.org>
Received: by mako.cs.indiana.edu
	(5.65c/9.4jsm) id AA02157; Thu, 13 May 1993 09:34:54 -0500
Date: Thu, 13 May 1993 09:34:54 -0500
From: "Ya-Gui Wei" <yawei@cs.indiana.edu>
To: L.S.Ng1@southampton.ac.uk, soft-authors@ifcss.org
Subject: Statistics on usage of Big5 Infrequent characters
Cc: yawei@cs.indiana.edu
Status: RO



Fung Fung and others,

  Below is just a little statistics on usage of Big5 characters I 
did last evening. Descriptions follow the table.

      SAMPLE      TOTAL     INF    ARL    TOT/INF   F/TOT%
   ---------------------------------------------------------
    A.C.T.BIG5   107129     348   1.086    307.8    99.68%
     CLASSICS    163427    2276   1.793     71.8    98.61%
   ---------------------------------------------------------

SAMPLES - A.C.T.BIG5 is the alt.chinese.text.big5 news spool for the
  week of May 5-12, 1993, apprx. 530 articles.  CLASSICS is the
  china-studies/literature/classics directory at ifcss.org, with
  classic proses and poetry from the pre-Qin to Tang periods.
TOTAL - the total count of Big5 characters in the sample.
INF - the total count of infrequent Big5 characters in the sample.
  (The Big5 table has 5401 frequent chars, and 7652 infrequent ones.)
ARL - average run length of INF, measures how many infrequent Big5
  characters occur in a row, on average. For example, if we have
  3 characters in a row and another 1 by itself, then the ARL
  is (3+3+3+1)/4 = 2.5 (not 2.0).
TOT/INF - number of all chars for each infrequent characters.
F/TOT% - percentage of Frequent characters in the sample text.

It seems that Infrequent characters are indeed quite infrequently
used, even in pre-Qin classics. When they are used, they don't
usually occur for more than once in a row.


  Ya-Gui Wei
  May 13, 1993


p.s. This little exercise was done to justify my proposal for
     a 2-byte scheme for encoding Big5 into ASCII.  There is
     little reason to waste an extra byte when 99.7% of the times
     we stay within the 5000+ frequent characters.  I'll have
     more to say about this later (and soon).

p.p.s. There may be arguements that the infrequent char usage
     may be deflated in the a.c.t.big5 sample because most articles
     there are converted from GB. However, I can also make the
     counter arguement that the usage may be _inflated_ due to
     the fact that classic proses and poetry are over-
     represented there. So why don't we take it as accurate 
     within a few tenths of percentage points, which is good
     enough for our purpose. :-)


From @UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU Sat May 15 12:19:59 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 AA11421; Sat, 15 May 93 12:19:55 CDT
Message-Id: <9305151719.AA11421@ifcss.org>
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 4379; Sat, 15 May 93 13:18:53 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; Sat, 15 May 1993 13:18:52 -0400
Date:         Sat, 15 May 1993 12:18:20 -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:      GB row-col -> GB 2byte code?
Comments: To: CCNET-L@uga.cc.uga.edu
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
Status: RO

Help!
I'm using the CJK tables from the Unicode Volume II manual also listed
at the Unicode FTP site and it containst the GB-2312 code in a row-column
format consisting of decimal numbers from 1000 to 9000 roughly.  Does
anyone have a table or other information to convert that 4 digit number
to the 2-byte code which is used by most of the tables and other code
available such as GBLIST, GB2PINYIN, PRONOUNC.TBL, TELECODE2GB, etc.

(Also, I'm looking for the equivalent with Korean KSC5601 code.)

Thanks in advance,

--Peter
henstock@ecn.purdue.edu

From @UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU Sun May 16 20:13:44 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 AA24942; Sun, 16 May 93 20:13:37 CDT
Message-Id: <9305170113.AA24942@ifcss.org>
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 8023; Sun, 16 May 93 21:12:43 EDT
Received: from UGA.CC.UGA.EDU (NJE origin LISTSERV@UGA) by UGA.CC.UGA.EDU (LMail V1.1d/1.7f) with BSMTP id 4156; Sun, 16 May 1993 21:12:42 -0400
Date:         Mon, 17 May 1993 10:10:39 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:      Re: GB row-col -> GB 2byte code?
Comments: To: CCNET-L@uga.cc.uga.edu
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
Status: RO

  Peter V Henstock <henstock%ECN.PURDUE.EDU> writes:
  > I'm using the CJK tables from the Unicode Volume II manual also listed
  > at the Unicode FTP site and it containst the GB-2312 code in a row-column
  > format consisting of decimal numbers from 1000 to 9000 roughly.  Does
  > anyone have a table or other information to convert that 4 digit number
  > to the 2-byte code which is used by most of the tables and other code
  > available such as GBLIST, GB2PINYIN, PRONOUNC.TBL, TELECODE2GB, etc.
  >
  > (Also, I'm looking for the equivalent with Korean KSC5601 code.)

  The conversion is done very easyly:
  Take the first two digits, add 160 and you have the ascii-value for
  the first byte, then do the same for the second two digits.
  Examples:
    Quwei      Ascii
    0101       161-161
    1601       176-161   etc.

  Hope this helps,
  ~a
   [A  [B~a
 [A [C [C [C [
 [A [C [C [~a
 [C [C [CChristian, Kyoto  g53150@sakura.kudpc.kyoto-u.ac.jp

From L.S.Ng1@southampton.ac.uk Tue May 18 05:42:09 1993
Return-Path: <L.S.Ng1@southampton.ac.uk>
Received: from sun2.nsfnet-relay.ac.uk by ifcss.org (4.1/IFCSS-Mailer)
	id AA12845; Tue, 18 May 93 05:35:15 CDT
Via: uk.ac.southampton; Tue, 18 May 1993 11:18:35 +0100
From: "L.S.Ng" <L.S.Ng1@southampton.ac.uk>
Message-Id: <22038.9305180955@mail.soton.ac.uk>
Date: Tue, 18 May 93 10:55:50 BST
To: soft-authors@ifcss.org (soft-authors@ifcss.org)
Subject: A solution for Non-Standard Chinese Characters in Email
X-Mailer: ELM [version 2.3 PL11]
Status: RO


Liang Sheng Wu 
 
A PROPOSAL to encode Non-standard Chinese Characters
****************************************************

Proposal Codename : FC (Fei1 Chang1 zi4 bianma fang'an)

It is the nature of Chinese Language that it does not have a definite set of 
characters. So we must have a semiformal graphical solution to
code for those rare but essential non-standard characters. It would be totally
unacceptable if a Classical Document has a few character missing. How can we
inherit Chinese Culture completely intact? Hence a solution for non-standard
character coding is necessary.

I suggest a solution to Non-standard Charaters:
 
Aim: To code and display non-standard Characters WHEN NECESSARY.
 
Method: Include the BITMAP INFORMATION of a non-standard characters WITHIN an
ordinary document. The decoder should read this info and be able to display it.
 
Assign to a non-standard character a TEMPORARY Guobiao/HZ code which can be any
place in the blank region (region 8 to 15 or 88 to 94). So as the temporary
non-standard character appear in the text, the decoder will use the BITMAP info
to display it.
 
Format: To comply with SMTP, use a string of hexadecimal numbers to represent
the bitmap.  For 16x16 bitmap we need 32 bytes, so the hex number equivalent
would be 64 character long. The bitmap info is preceeded by the temporary GB/HZ
code. And all this info can fit into one single line only which should begin
with an identifier. e.g.
 
zKA8011234ABCDEFAB12345678098374859283BEFA394DCB3948CBDE948503948ABCD..
  ^   ^all this are bitmap info in Hex number, length=64 for 16x16 bitmap
^ A801 the temporary GB/HZ code
identifier zK
 
Extension: For larger bitmap, more lines can be used.
 
Software:
1. It requires easy to use/flexible font editor. The font editor should be able
to code the bitmap info in Hex number. It should also log automatically all
the characters the user has defined/written so far.
2. It requires a text editor which can cut and paste the bitmap info into a
document.
3. The decoder should handle standard GB/HZ coding and when it encounters a
non-standard character, it reads the bitmap info to display it. 
It should allocate some buffer to hold the temporary bitmap. 
It should overwrite the existing temporary bitmap buffer with the most 
recent one in the event that GB/HZ code has been repeated. 
The bitmap info can be stored anywhere but it should appear before the 
non-standard character itself.
 
Please send your comment to l.s.ng1@mail.soton.ac.uk
 
Conclusion: 

It is necessary to code only a few non-standard Chinese Characters
in one single document. It can be seen that those non-standard character code
can be ported/copied/modified easily. And since it is temporay and is defined
locally (within a document), it would not cause interference with another
document, and if it does, it can be modified easyly. The blank regions in GB
table is much more than enough.

A question asked that what if the reader has already defined some character 
and the incoming message use the same GB/HZ code as the existing ones. I think
the decoder program should adhere to the principle that priority 
should be given to the 'guest'. i.e. ignore the reader's own definition. 
Since the reader is reading, he won't be writing, hence it doesn't matter if
he cannot write his own character.

Nevertheless, it is the nature of Chinese Language that it does not have a
definite set of characters. So we must have a semiformal graphical solution to
code for those rare but essential non-standard characters. It would be totally
unacceptable if a Classical Document has a few character missing. How can we
inherit Chinese Culture completely intact? Hence a solution for non-standard
character coding is necessary.

In fact, the function to create user-defined characters has been a standard 
feature in many Chinese Softwares/Systems. My solution is to make it possible
for electronic communications. What's the use if one character I create can't
be seen by the others? This is an essential improvement on Chinese Software
Design.

From @UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU Thu May 27 06:28:41 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 AA10825; Thu, 27 May 93 06:28:38 CDT
Message-Id: <9305271128.AA10825@ifcss.org>
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 0073; Thu, 27 May 93 07:27:56 EDT
Received: from UGA.CC.UGA.EDU (NJE origin LISTSERV@UGA) by UGA.CC.UGA.EDU (LMail V1.1d/1.7f) with BSMTP id 2456; Thu, 27 May 1993 07:27:54 -0400
Date:         Wed, 27 May 1992 19:28:01 +0800
Reply-To: Dr CK Farn <ckfarn@IM.MGT.NCU.EDU.TW>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: Dr CK Farn <ckfarn@IM.MGT.NCU.EDU.TW>
Subject:      Re: chinese fonts
Comments: To: ccnet-l@uga.cc.uga.edu
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
Status: RO

>Ang writes:
> > I understand that Big5 is commonly used in Taiwan.
> > But how about CNS? Is this the standard used in Taiwan or is Big5
> > the standard?
> > Is there any software etc using CNS as the internal code instead of Big5?
>
>I think Big5 and CNS are the same thing.

Big5 and CNS (CNS-11643) are different.  There are many Chinese internal
codes (including Wang, CDC, IBM, Big-5, ETen, TCA, etc.) used by different
users well before the two Chinese Standard (CNS-11643 and CCCII) were
established.  BIG-5 is the name of a Chinese integrated software (parallel
to Framework, including WP, spreadsheet, etc.) developed by III (Inst. of
Info. Industry), and they developed an internal coding scheme and a
character set for it.  Since it was one of the earliest PC-based coding
scheme, it became the de facto standard.  while the government spent lots
of time deciding on which standard to select, the users already settled on
their own.

Currently, most Chinese software makes use of BIG-5, among other things.
Today, most Chines DOS add-ons can process multiple internal codes.  For
example, Rainbow-5, an Eten PC-card can use at least BIG-5, IBM 5550, TCA,
CNS and Wang, Eten, and Wang codes.  Most printers can also process
multiple codes.  As for software, most are unaware of which internal codes
is used (as long as the Chinese extension can process it).

In addition, one can acquire translation programs among these coding
schemes with some efforts.  Some utilities can even do the translation on
the fly, while communicating between two systems using two different coding
schemes (just like between ASCII and EBCDIC).  To day, many Chinese DOS
extension vendors also market versions that can translate between BIG-5 and
GB.

_____________________________________________________________
Dr C.K.Farn       Information Mgmt Dept.,National Central U.,
(-S?~1j)          Chung-li, Taiwan 320, Republic of China
Tel: 886-3-426-7261,886-3-4227151x6527  Fax: 886-3-425-4604
Email: ckfarn@im.mgt.ncu.edu.tw

From @UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU Thu May 27 11:04:37 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 AA12863; Thu, 27 May 93 11:04:32 CDT
Message-Id: <9305271604.AA12863@ifcss.org>
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 2683; Thu, 27 May 93 12:03: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 9099; Thu, 27 May 1993 12:03:12 -0400
Date:         Thu, 28 May 1992 00:03:07 +0800
Reply-To: Dr CK Farn <ckfarn@IM.MGT.NCU.EDU.TW>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: Dr CK Farn <ckfarn@IM.MGT.NCU.EDU.TW>
Subject:      Re: chinese fonts
Comments: To: Stephen G Simpson <simpson@math.psu.edu>
Comments: cc: CCNET-L%UGA.bitnet@TWNMOE10.EDU.TW
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
Status: RO

> > >I think Big5 and CNS are the same thing.
> >
> > Big5 and CNS (CNS-11643) are different.  ...
>
>Thanks for the correction.  Are they completely different (like Big-5
>and IBM 5550), or are they different only in a relatively small number
>of codes?

Totally different!

These differences can be on the size of the character set (Big5,CNS: 13K+,
CCCII: 70K+), sort sequence, number of bytes (Big5,CNS: 2 bytes, CCCII,
Wang: 3 bytes).  It is a mess!  The government is trying to force the
CNS11643 scheme by requiring it in every gov. acquisition, we will have to
wait and see.
_____________________________________________________________
Dr C.K.Farn       Information Mgmt Dept.,National Central U.,
(-S?~1j)          Chung-li, Taiwan 320, Republic of China
Tel: 886-3-426-7261,886-3-4227151x6527  Fax: 886-3-425-4604
Email: ckfarn@im.mgt.ncu.edu.tw

From @UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU Fri May 28 09:00:09 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 AA26047; Fri, 28 May 93 09:00:03 CDT
Message-Id: <9305281400.AA26047@ifcss.org>
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 6661; Fri, 28 May 93 09:59:05 EDT
Received: from UGA.CC.UGA.EDU (NJE origin LISTSERV@UGA) by UGA.CC.UGA.EDU (LMail V1.1d/1.7f) with BSMTP id 6071; Fri, 28 May 1993 09:59:03 -0400
Date:         Fri, 28 May 1993 14:59: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: hanzi bitmap font (HBF) Standard
Comments: To: ccnet-l@uga.cc.uga.edu
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
Status: RO

On coding schemes,

> Accepted values for HBF_CODE_SCHEME in this Standard v1.0 are:
> [...]
>        Unicode vendor v1.1 -- not simply "Unicode"; use the specific
>                               version "v1.1" supplied by "vendor".
>                               Unicode is still evolving and thus
>                               different versions exist.

I think that Unicode is a good deal more well-defined than this -- the
UniHan area (4E00-9FA5) is essentially set in concrete now, as are the CJK
punctuation areas of concern to us, and most of the rest of the standard.
Unicode 1.0 is described by the published books, and a couple of tables
on unicode.org.  A few minor changes in areas separate from Chinese
computing are described in the Unicode 1.0.1 addendum also at that FTP
site.  A few extra presentation forms from ISO 10646 are added in Unicode
1.1, but again this has no impact on Chinese computing.  Now Unicode 1.1
is equivalent to ISO/IEC 10646-1 UCS2, Level 3 -- they cover exactly
the same collection of characters, with identical code assignments.
Future versions might add more hanzi, and may add a combining-form method
of extending the hanzi set, but they can be expected to leave existing
assignments alone (the credibility of both standards is at stake).

Different vendors might put different stuff in the Private Use Area
(E000-F8DD), but that's peripheral.  Besides, Unicode versions
are independent of vendors, though vendors might define their own
sub-versions.  Thus the coding schemes should be called

        Unicode 1.0
        Unicode 1.0.1
        Unicode 1.1

but these are all equivalent as far as the Chinese portion is concerned,
and the first two are now obsolete.  You could add an optional vendor
and vendor-version if you're using the Private Use Area, but that's
best avoided.


As for the C interface, I would have expected just

        typedef struct {
                /* fields corresponding to the definition */
                /* plus internal table of font files */
        } HBF_FILE;

        HBF_FILE *      HBF_OpenFont(const char *hbfFileName);
        int             HBF_CloseFont(HBF_FILE *hbfFile);
        int             HBF_GetBitmap(HBF_FILE *hbfFile,
                                        HBF_HzCode code,
                                        char *buffer);

(I can't see how you'd avoid re-opening font files all the time with the
existing definition.)
--
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 Fri May 28 15:46:00 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 AB02996; Fri, 28 May 93 15:45:58 CDT
Message-Id: <9305282045.AB02996@ifcss.org>
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 9243; Fri, 28 May 93 16:01:51 EDT
Received: from UGA.CC.UGA.EDU (NJE origin LISTSERV@UGA) by UGA.CC.UGA.EDU (LMail V1.1d/1.7f) with BSMTP id 2216; Fri, 28 May 1993 15:59:59 -0400
Date:         Fri, 28 May 1993 15:58:05 -0400
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:      Big5 and CNS-11643 are almost the same
Comments: To: ccnet-l@uga.cc.uga.edu
Comments: cc: cwnn <walt!omcp.omron!cwnn@UUNET.UU.NET>
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
Status: RO

As we all know, Big5 is a 2-byte Chinese character coding scheme that
is extremely popular in Taiwan.  As Dr. Farn has said, it the most
popular coding scheme for both PCs and Macs, and it is supported by
virtually all software.

Less well known but also important is CNS-11643, a 2-byte Chinese
character coding scheme which is endorsed as the national standard by
the ROC government.  Dr. Farn has said that support for CNS-11643 is
required in software procured for government use.

Recently CCNET has seen some discussion of the relationship between
Big5 and CNS-11643.  I asserted that these two coding schemes are the
same.  Others asserted that they are totally different.

Now I have done a little further research on this matter.  In an old
discussion of an early version of the Unicode cross reference table
cjkxref.fix, the following column header information appears:

> 3. BIG-5: 4 hexadecimal digits
> 4. CNS 11643-1986: L-XXXX (4 hexadecimal digits), where L is one of
>       1 = Frequent characters
>       2 = Less frequent characters
>       E = extensions
>    The first two levels are the two levels of BIG-5, minus the two
>    characters C94A and DDFC, rearranged (in the same order) to fit in
>    the range of graphic characters (A1-7E)

(The old discussion is archived at ifcss.org in
~ftp/china-studies/compute/ccnet-archive/chcoding.  The current
version of cjkxref.fix is available at unicode.org in
~ftp/pub/MappingTables.)

The above information appears to be confirmed by an examination of
columns 3 and 4 of cjkxref.fix.  Although the Big5 and CNS-11643
coding schemes are not identical, there appears to be a very simple
one-to-one correspondence between them.  With a very small number of
exceptions, they appear to contain exactly the same characters in
exactly the same order.

Unfortunately, I do not have access to any official standards document
in which the relationship between Big5 and CNS-11643 is spelled out.
Perhaps someone who is involved with ROC goverment software
acquisition and standards can supply this kind of official
information?

In any case, it does appear that, for practical purposes, Big5 and
CNS-11643 are the same.  Thus I think it is fair to say that Big5 is
not only extremely popular in Taiwan, it is also very close to being
an officially approved ROC government standard.  The practical
importance of this is that, if you are developing software for use in
Taiwan, Big5 is the one Chinese character coding scheme that you will
have to support.

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 AT PSUVM
FAX: +1 814 865-3735

From @UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU Sun Jun  6 01:25:59 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 AA26170; Sun, 6 Jun 93 01:25:58 CDT
Message-Id: <9306060625.AA26170@ifcss.org>
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 4888; Sun, 06 Jun 93 02:25:25 EDT
Received: from UGA.CC.UGA.EDU (NJE origin LISTSERV@UGA) by UGA.CC.UGA.EDU (LMail V1.1d/1.7f) with BSMTP id 3063; Sun, 6 Jun 1993 02:25:24 -0400
Date:         Sat, 6 Jun 1992 14:23:25 +0800
Reply-To: Dr CK Farn <ckfarn@IM.MGT.NCU.EDU.TW>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: Dr CK Farn <ckfarn@IM.MGT.NCU.EDU.TW>
Subject:      Re: Why it's called Big5?
Comments: To: Shide Zhang <szhang@BCM.TMC.EDU>
Comments: cc: CCNET-L%UGA.bitnet@TWNMOE10.EDU.TW
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
Status: RO

>The question sounds stuipid, but I really don't know. Why is the Chinese
>coding system used in Taiwan called Big5? Just curious.

The following is what I know.  If I am wrong, someone please correct me.

During the early 80's (probably around 79-80), the III (Institute of
Iformation Industry, a goverment funded agency) of ROC launched a project
to develop a Chinese software product for use with PC's.  The software is
for general purpose use, and is meant to be an integrated package (like
Framework) including five major functions (WP, Spreadsheet, comms, file
handling, etc.).

There are five major functions in it, and the product is thus named BIG-5.
At that time, there were no suitable Chinese internal coding scheme for PC
(there were many mainframe based internal coding scheme, like CDC, IBM,
WANG, etc., but I thing at that time, selecting any one vendor based scheme
will make III liable to be accused of protecting one vendor), so they
develop their own internal Chinese coding scheme for the BIG-5 package.
BIG-5 as a sotware package was a market disaster, but the coding scheme
becomes the most popular in the micro-computer market.

Note that BIG-5 is not THE official chinese coding scheme.
_____________________________________________________________
Dr C.K.Farn       Information Mgmt Dept.,National Central U.,
(-S?~1j)          Chung-li, Taiwan 320, Republic of China
Tel: 886-3-426-7261,886-3-4227151x6527  Fax: 886-3-425-4604
Email: ckfarn@im.mgt.ncu.edu.tw

From @UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU Wed Jun  9 15:23:15 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 AA25002; Wed, 9 Jun 93 15:22:59 CDT
Message-Id: <9306092022.AA25002@ifcss.org>
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 8542; Wed, 09 Jun 93 16:21:53 EDT
Received: from UGA.CC.UGA.EDU (NJE origin LISTSERV@UGA) by UGA.CC.UGA.EDU (LMail V1.1d/1.7f) with BSMTP id 0520; Wed, 9 Jun 1993 16:21:51 -0400
Date:         Wed, 9 Jun 1993 13:20:24 -0700
Reply-To: Robert Felsing <FELSING@OREGON.UOREGON.EDU>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: Robert Felsing <FELSING@OREGON.UOREGON.EDU>
Subject:      CCCII used by Taiwan (and several US) libraries
Comments: To: ccnet-l@uga.bitnet
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
Status: RO

        A number of Internet
-accessible libraries use CCII instead of
Big-5 coding.  Does anyone know of a "reader" that is available for CCCII?
It's a shame that the Big-5 option is not made available at all libraries.
These libraries are, of course, using online systems created by Innovative
Interfaces, which makes the situation even more frustrating.

        A second question:  Is there any inexpensive Japanese operating
system that will allow for the reading of text transmitted by Japanese
Gophers?  I assume Japanese DOS/V works.  Does anyone know of ANY Japanese
libraries that are accessible over the Internet?

        Many thanks for any assistance or suggestions!

                        Bob Felsing
                        East Asian Bibliographer
                        University of Oregon
                        Eugene, OREGON USA

                        (FELSING@OREGON.UOREGON.EDU

From @UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU Wed Jun  9 20:28:53 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 AA07547; Wed, 9 Jun 93 20:28:41 CDT
Message-Id: <9306100128.AA07547@ifcss.org>
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 5901; Wed, 09 Jun 93 21:28:04 EDT
Received: from UGA.CC.UGA.EDU (NJE origin LISTSERV@UGA) by UGA.CC.UGA.EDU (LMail V1.1d/1.7f) with BSMTP id 1405; Wed, 9 Jun 1993 21:28:03 -0400
Date:         Thu, 10 Jun 1993 09:25:18 -0800
Reply-To: Dr CK Farn <ckfarn@IM.MGT.NCU.EDU.TW>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: Dr CK Farn <ckfarn@IM.MGT.NCU.EDU.TW>
Subject:      Re: CCCII used by Taiwan (and several US) libraries
Comments: To: CCNET-L%UGA.bitnet@TWNMOE10.EDU.TW
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
Status: RO

>        A number of Internet
>-accessible libraries use CCII instead of
>Big-5 coding.  Does anyone know of a "reader" that is available for CCCII?
>It's a shame that the Big-5 option is not made available at all libraries.

CCCII are choosen for most libraries for a simple and strong reason.  Big-5
and most other Chinese (fan2ti2) coding schemes only allow for arond 13K
characters, which is for most practical purposes, more than enough.
However, for library use, the character set is simply too small.  CCCII
theoretically holds 76K+ characters (most implementation, I understand,
have 30K+ characters).

In Taiwan, much of the library systems uses CCCII as internal codes, and
allow for special CCCII terminals (very expensive due to low volume) so
that librarians can do necessary updates and inserts.  However, for network
connections that uses only the inquiry function, most library system caters
for an "on the fly" translation between CCCII and Big5, so that a normal
Chinese (Big5) Telnet frontend can access the information.

This solution seems odd, but it is based on requirements, unless we treat
the characters beyond 13K as " " in the system.  For the translation, it is
for extending user services.

For the US users whose oriental library do not have the translation
facilities at the host side, one can also make an "on the fly" translation
at the terminal side between CCCII/Big5 or CCCII/GB, it should not be a
major technical problem.
_____________________________________________________________
Dr C.K.Farn       Information Mgmt Dept.,National Central U.,
(-S?~1j)          Chung-li, Taiwan 320, Republic of China
Tel: 886-3-426-7261,886-3-4227151x6527  Fax: 886-3-425-4604
Email: ckfarn@im.mgt.ncu.edu.tw

From @UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU Fri Jun 11 20:04: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 AA23771; Fri, 11 Jun 93 20:03:38 CDT
Message-Id: <9306120103.AA23771@ifcss.org>
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 9586; Fri, 11 Jun 93 21:02:40 EDT
Received: from UGA.CC.UGA.EDU (NJE origin LISTSERV@UGA) by UGA.CC.UGA.EDU (LMail V1.1d/1.7f) with BSMTP id 9716; Fri, 11 Jun 1993 21:02:39 -0400
Date:         Sat, 12 Jun 1993 10:01:44 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:      Unicode Han-Character properties
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
Status: RO

This mail is sent to a number of lists and individuals, I apologize
if you have already seen it and if ist's just noise to you.

Christian

                C A L L   F O R   C O N T R I B U T I O N S

                                  for a

                DATABASE OF UNICODE HAN-CHARACTER PROPERTIES


There are a number of places where lists of character properties for
chinese characters are compiled, and there might be many more that I
am not aware of. Now, with Unicode lingering on the horizon and tables,
which provide reliable conversion between the different coding systems
used in East Asia, I think it is time to try to compile all these
different lists into one big database, which with some additional
work will hopefully provide basic information for all characters
defined in the Unicode Han Character Set.

A database like this would be a great enhancement for the computer
as a research tool or language study assistant, it would save long
hours of browsing through dictionaries and free energies for more
productive work.

Character properties I have in mind include, but are not limited to
the following:

    1.) Informations about the character shape and input codes:
        Radical and strokecount
        Total strokecount
        Four corner number
        Cangjie input code
        Wubi input code

    2.) Pronounciation in Chinese (Pinyin), Japanese and Korean

    3.) Character numbers or page references in dictionaries.

    4.) Informations about the character usage frequencies


Any other contributions are welcome. The format for the contributions
should be as follows:

    1.) The data should be in a <tab> separated list. Empty cells should
        be marked by an * (This is the same format as in the file
        'cjkxref.fix' available at unicode.org).

    2.) Please include a header, which should contain information
        about the content of the file, the character code and the
        length fo the individual cells, as well as name and con-
        tact adress of the contributor.

    3.) The character codes can be either in binary or ASCII format.
        Information in any of the codes covered by the table in
        'cjkxref.fix' are welcome.


    4.) All contributions should contain only material which is pub-
        lic domain. The names of the contributers will be given in
        a doc-file distributed with the databases.

Here is an example header:

# Han-Code: Big-5
#
# Field-contents:          Length:
# Character (Big5 -Code)    4
# Four Corner Code          6
#
# provided by: Christian Wittern
# email: g53150@sakura.kudpc.kyoto-u.ac.jp


I intend to make the database file available for ftp at ifcss.org,
which will be the home for the database. As I can't possibly check
all contributions for accuracy, I'll be willing to correct errors
and update the masterfile regularly, whenever errors are brought
to my kowledge or new contributions arrive.

I hope this will bring together hitherto isolated efforts and
prevent waste of time and energy for doubled input of information.

Thanks in advance for your help.

Best wishes on a hot summerday in Kyoto,

  Christian

  g53150@sakura.kudpc.kyoto-u.ac.jp

From @UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU Wed Jul 21 08:12: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 AA00536; Wed, 21 Jul 93 08:11:50 CDT
Message-Id: <9307211311.AA00536@ifcss.org>
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 7018; Wed, 21 Jul 93 09:10:54 EDT
Received: from UGA.CC.UGA.EDU (NJE origin LISTSERV@UGA) by UGA.CC.UGA.EDU (LMail V1.1d/1.7f) with BSMTP id 4460; Wed, 21 Jul 1993 09:10:51 -0400
Date:         Wed, 21 Jul 1993 14:07:44 BST
Reply-To: Ross Paterson <rap@DOC.IMPERIAL.AC.UK>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: Ross Paterson <rap@DOC.IMPERIAL.AC.UK>
Subject:      Re: UNICODE Series
Comments: To: ccnet-l@uga.cc.uga.edu
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
Status: RO

Another development that may of interest is the UCS Transmission
Formats (UTFs) that have been proposed for Unicode/ISO-10646 (UCS =
Universal Character Set, another name for ISO-10646).  These aim to
encode these wide characters as byte sequences with some degree of
backward compatability.  Now some people are using them as external
representations, e.g. in files as well as for communication.

UTF-1 (formerly called UTF) is described in an informative (non-normative)
annex to ISO-10646.  ISO-10646 characters are encoded as follows:

        ISO-10646       UTF
        ---------------------
        0000 - 009F     00-9F
        00A0 - 00FF     A0 A0-FF
        0100 - 4015     A1-F5 XX
        4016 - 038E2D   F6-FB XX XX
        038E2E and up   FC-FF XX XX XX XX

where XX means G0 (21-7E) plus G1 (A0-FF) (190 positions).  (Currently
codes are assigned only for the 16-bit subset, which is identical to
Unicode 1.1).  Some properties:
- ASCII files are still correct.
- UTF files using only Latin-1 characters are legible when interpreted
  as Latin-1 files.
- C0 (00-20: control codes and SPACE) and C1 (7F-9F) characters appear
  only as themselves, and so can be used to re-synchronize.
Disadvantages include the amount of arithmetic involved in conversion,
and the difficulty in synchronization.  For an implementation, see
metis.com:pub/utf.c.

UTF-2 (a.k.a. FSS-UTF -- File System Safe UTF) was proposed by X/Open.
It provides synchronization, simpler conversion, and 2-way ASCII
compatability, at the cost of using bytes in the range 80-9F, some
longer encodings, and the loss of the partial Latin-1 compatability.
The following description is excerpted from the comments in
metis.com:pub/utf-fss.c, written by Ken Thompson:

 * The proposed UCS transformation format encodes UCS values in the range
 * [0,0x7fffffff] using multibyte characters of lengths 1, 2, 3, 4, 5,
 * and 6 bytes.  For all encodings of more than one byte, the initial
 * byte determines the number of bytes used and the high-order bit in
 * each byte is set.  Every byte that does not start 10xxxxxx is the
 * start of a UCS character sequence.
 *
 * An easy way to remember this transformation format is to note that the
 * number of high-order 1's in the first byte signifies the number of
 * bytes in the multibyte character:
 *
 * Bits  Hex Min  Hex Max  Byte Sequence in Binary
 *   7  00000000 0000007f 0vvvvvvv
 *  11  00000080 000007FF 110vvvvv 10vvvvvv
 *  16  00000800 0000FFFF 1110vvvv 10vvvvvv 10vvvvvv
 *  21  00010000 001FFFFF 11110vvv 10vvvvvv 10vvvvvv 10vvvvvv
 *  26  00200000 03FFFFFF 111110vv 10vvvvvv 10vvvvvv 10vvvvvv 10vvvvvv
 *  31  04000000 7FFFFFFF 1111110v 10vvvvvv 10vvvvvv 10vvvvvv 10vvvvvv 10vvvvvv
 *
 * The UCS value is just the concatenation of the v bits in the multibyte
 * encoding.  When there are multiple ways to encode a value, for example
 * UCS 0, only the shortest encoding is legal.

Synchronization is much easier, ASCII files are still correct, and only
ASCII characters use ASCII bytes.

These properties mean that many 8-bit clean programs and subroutines that
don't place any special meaning on non-ASCII bytes (e.g. a string search
routine) will also work on UTF text without change.  And, of course, any
existing ASCII file is also a UTF file.  For these reasons, it is used
as the external encoding in Plan 9 (a research Unix system).  For more
details, see research.att.com:dist/plan9man/09utf.ps.Z.  They didn't
address the rendering of non-spacing characters (diacritics), but those
are not used in Chinese computing.

As for code length, if you compare the above descriptions with
the layout of the code space (see the Unicode books, or tables in
unicode.org:pub/MappingTables and metis.com:pub/csmaps), you get the
following character lengths in bytes:

                        now     Unicode UTF1    UTF2
----------------------------------------------------
ASCII                   1       2       1       1
Latin-based alphabets   1       2       1+      1+
Europe & Middle East    1       2       2       2
Asian alphabets         1       2       2       3
CJK Auxilliary          2       2       2       3
Hangul syllable blocks  2       2       2/3     3
Hanzi/Kanji/Hanja       2       2       3       3

The big losers here are a belt of alphabets from India to Cambodia, plus
Mongolian and alphabetic Hangul, not that these need worry CCNET readers.

So if you can stand a 50% blow-up of your hanzi text, the gain is a fairly
smooth transition to a universal character set, with more hanzi, and both
simplified and traditional characters.  I've recently hacked the X windows
client 'xedit' to handle UTF text in a Plan 9-like way.  It's certainly
a lot simpler than the current scheme for internationalization of X.
--
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 Mon Aug  2 10:50: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 AA09113; Mon, 2 Aug 93 10:50:47 CDT
Message-Id: <9308021550.AA09113@ifcss.org>
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 1245; Mon, 02 Aug 93 11:49:28 EDT
Received: from UGA.CC.UGA.EDU (NJE origin LISTSERV@UGA) by UGA.CC.UGA.EDU (LMail V1.1d/1.7f) with BSMTP id 7939; Mon, 2 Aug 1993 11:49:26 -0400
Date:         Mon, 2 Aug 1993 11:37:13 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:      Chinese in the UNICODE
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
Status: RO

Dear Netters:

      I think this is a very important topic.
      A few weeks ago, I learned from the electronical magasine that we would
have to even translate Chinese to Chinese due to the non-correlated
code setting of the original Chinese characters used in Taiwan, HongKong &
overseas and the simplified Chinese characters used in mainland China in
the future UNICODE code.
      I think this would be a misfortune not only for Chinese people but also
for everyone in the world.
      Can we, all Chinese computing lovers in the world, do anything good
for the great culture's future in a correct direction?
      My strong point is: we should at least let Chinese to not be translated
in the future code setting, UNICODE for example.
      I think the new Chinese code should be based on the original Chinese
characters. We have at least two big reasons for this:
      1) Original Chinese characters have never been eliminated even in
mainland China although many of them have been simplified. Original
characters are still 'legal' in mainland China. People still use it in
mainland China, don't mention Taiwan, HongKong & overseas.
      2) Original Chinese characters contain every thing we may need such as
'the art of war' and anything else.
      Let's have a look on the 'new Chinese code' setting. This is a large
sheet that contains all original Chinese characters we might need.
On the first subsheet we have only a few hundreds of simplified characters
each of them sits in the same 'hole' correspond to the original one. The
rest 'holes' are empty. The second subsheet would be the 'Kanji' set. It
also contains only 'simplified' characters. The third subsheet would be
the Korean Chinese character set. It contains also only 'simplified'
characters.
      For all simplified Chinese, KanJi and Korean Chinese, they use the
same code as the original Chinese code setting for those characters not
been 'simplified' or 'modified' original Chinese characters.
      I think mainland China simplified only a few hundreds characters and
we use as many characters as in the original character set. The Japanese
expert can tell us how many Chinese characters Japanese use and how many have
been simplified. Also for Korean Chinese. I bilieve that every simplified set
would be only a few hundreds.
      In this way, we could:
      1) save a lot of space for other languages and function codes. We may
even put a sort of 'PostScript' code and drawing code in the UNICODE. Using
different code for thousands of repeated characters for the same language
and let them to be translated due to only a few hundreds of simplified
characters is stupid and it's a crime!!!!!
      2) need not any translation between the original Chinese text and
simplified Chinese text or even between Janpanese (or Korea) and Chinese
for the 'Chinese' part.
      Let's talk to the polititians and make the code work for the human
being, not only for polititians who will not really use it.
      What's your opinion?

Jian-xiong Wang

----------------------------Original message----------------------------
GB codes are limited to mostly frequently used words.  Using GB codes seems
to be sufficient for most writtings.  Unfortunately, classic Chinese works
contain a lot of obscure words.  For example, when I read the computer version
of Art of War, I found seven words that are not in the GB codes.

I would like to know if there is an widely accepted way to represent obscure
words in computing.  Assume Chinese characters are composed of a limited
number of parts, then, it's possible to provide a coding system for these
parts, and another coding system designating how these parts are configured.
Being an outsider to the inner working of computers, I have no idea if it is
feasible to pursue this direction.  But am interested in finding ways to
overcome this problem.

Would appreciate very much information regarding this topic.

Thanks in advance.

From @UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU Thu Aug  5 06:28:15 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 AA16173; Thu, 5 Aug 93 06:28:02 CDT
Message-Id: <9308051128.AA16173@ifcss.org>
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 3326; Thu, 05 Aug 93 07:26:45 EDT
Received: from UGA.CC.UGA.EDU (NJE origin LISTSERV@UGA) by UGA.CC.UGA.EDU (LMail V1.1d/1.7f) with BSMTP id 0222; Thu, 5 Aug 1993 07:26:44 -0400
Date:         Thu, 5 Aug 1993 12:26: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: hanzi coding and fonts
Comments: To: ccnet-l@uga.cc.uga.edu
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
Status: RO

guojin@iss.nus.sg wrote:
> I think a STRUCTURED coding scheme is a necessity, ultimately,
> full stop.

> For example, a freind of mine has a Chinese name with the hanzi
> "ge" (song in English, ~{8h~} in hz code) in it.  However, maybe
> he is a brother, he didn't like the hanzi which literaly reads
> "brother (~{8g~}, the left part) in debt (~{G7~}, the right part)".
> He changed that hanzi to a new one he created which literaly reads
> "brother (~{8g~}, the right part) in speaking (~{QT~}, the left part)".
> Both he and I don't know if it is in the KangXi ZiDian, but it is
> definitly NOT in GB-2312 nor in Big5 and thus NOT in UNICODE.

It is in Unicode: it's U+8B0C (the character is in JIS X0208-1990,
KSC 5657-1991, and is also a user character in CNS 11643-1986).  This
particular character was an ancient variant of ~{8h~} ge1 "song", so
your friend has merely repeated history, but I wonder to what extent it
is desirable to have people creating new characters at will.  After all,
the function of a writing system is to communicate.

Unicode/ISO-10646 has 5140 characters that are not in GB 2312-80 or
Big-5; as well as Japanese and Korean standards, it covers thousands of
characters from the various extended GB ranges.  People may find that
it gives a much better coverage of old texts.

Nevertheless, the CJK Joint Research Group are considering proposals
to make the encoding extensible: one is to define combining characters
corresponding to the 214 traditional radicals.  A rare character might
be coded by the Unicode of its base followed by a Unicode representing
a radical to be added to the base, just like an accent added to a Latin
letter (though many of those are precoded).  In the proposal I heard of,
there was no plan to specify which form of the radical was used (say for
the "heart" radical) or where it would be placed relative to the base.
The encoding would not say how to draw the character; it would just
provide a means for specifying it.  Also, if a character could be directly
encoded, it would be illegal to use the composed form.  It seemed to me
that a method that knew more about variant forms and positions would be
more flexible, but they're reluctant to put too much specific linguistic
information in the multi-lingual encoding; in any case some hanzi-based
scripts like Vietnamese Chu Nom built characters using different rules.
--
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 Mon Aug  9 05:06:35 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 AA05477; Mon, 9 Aug 93 05:06:27 CDT
Message-Id: <9308091006.AA05477@ifcss.org>
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 3023; Mon, 09 Aug 93 06:05:09 EDT
Received: from UGA.CC.UGA.EDU (NJE origin LISTSERV@UGA) by UGA.CC.UGA.EDU (LMail V1.1d/1.7f) with BSMTP id 7862; Mon, 9 Aug 1993 06:05:07 -0400
Date:         Mon, 9 Aug 1993 12:40:00 MYT
Reply-To: Ng Liang Shing <liang@HSNG.PL.MY>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: Ng Liang Shing <liang@HSNG.PL.MY>
Subject:      SINOCODE
Comments: To: Chinese Computing Network <ccnet-l@uga.cc.uga.edu>
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
Status: RO

There is a program called SINOCODE that converts BIG5, Guobiao and JIS codes.
I found it in the following sites using archie:

Does anybody have any comments on the features, shortcomings and bugs on
SINOCODE? I would very much like to hear from you. Thank you.

Sincerely
Liangsheng Wu
ps. Please do not include this message when replying.
--archie result: prog sinocode--
Sorting by hostname


Search request for 'sinocode'


Host etlport.etl.go.jp   (192.31.197.99)
Last updated 04:30  5 Jul 1993

    Location: /pub/mule/contrib
      FILE      rw-rw-r--    113229  May 31 00:14   sinocode-0.11.tar.gz

Host haywire.nmsu.edu   (128.123.1.25)
Last updated 05:51 14 Apr 1993

    Location: /pub/chinese
      FILE      rw-rw-r--    170914  Nov 17 09:52   sinocode.zip
      FILE      rw-rw-r--      4114  Nov 17 09:50   sinocode.txt

Host me.uta.edu   (129.107.2.20)
Last updated 09:14  5 Aug 1993

    Location: /pub/nihongo
      FILE      rwxr--r--    170914  Jun 22 16:47   sinocode.zip

Host nic.funet.fi   (128.214.6.100)
Last updated 06:41 17 Jun 1993

    Location: /pub/culture/japan/mirrors/mule/mule-0.9.8/contrib
      FILE      rw-rw-r--    113229  Jun 15 01:42   sinocode-0.11.tar.gz

Host oskgate0.mei.co.jp   (132.182.49.2)
Last updated 10:41 18 Jun 1993

    Location: /free/gnu/emacs/Mule/contrib
      FILE      rw-r--r--    113229  Jun 16 15:01   sinocode-0.11.tar.gz

Host sh.wide.ad.jp   (133.4.11.11)
Last updated 06:24 20 Jun 1993

    Location: /JAPAN/mule/mule-0.9.8/contrib
      FILE      rw-r--r--    113229  Jun 14 22:42   sinocode-0.11.tar.gz

Host thalamus.sans.kth.se   (130.237.219.100)
Last updated 20:18 23 Jun 1993

    Location: /pub
      FILE      rw-r--r--    125395  Dec  1  1992   sinocode-0.11.tar.Z

--
Ng Liang Shing            |   This is an Internet node host inside
Sungai Petani, Malaysia   |   an old 286.  A few years back, this place
liang@hsng.pl.my          |   was not more than a small town.

From @UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU Fri Aug 13 04:48:47 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 AA03620; Fri, 13 Aug 93 04:48:44 CDT
Message-Id: <9308130948.AA03620@ifcss.org>
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 4480; Fri, 13 Aug 93 05:47:56 EDT
Received: from UGA.CC.UGA.EDU (NJE origin LISTSERV@UGA) by UGA.CC.UGA.EDU (LMail V1.1d/1.7f) with BSMTP id 3792; Fri, 13 Aug 1993 05:47:56 -0400
Date:         Fri, 13 Aug 1993 05:47:52 -0400
Reply-To: "HU Bo, IFT Munich, +49 89 54759129" <hubo@IFT.FHG.D400.DE>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: "HU Bo, IFT Munich, +49 89 54759129" <hubo@IFT.FHG.D400.DE>
Organization: FHG
Subject:      Re: GB-1
Comments: To: Ed Lai <lai@APPLE.COM>
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
In-Reply-To:  <DFNGATE:N8ZLsHAg*@MHS>
Status: RO

there are far more than that! I found 240 or
more 1->n mappings in GB-I (1) [3004 characters]
into Big 5. GB-1 above zone 88 is reserved for
user defined characters.

Bo

From @UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU Fri Aug 13 06:22:09 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 AA04355; Fri, 13 Aug 93 06:22:06 CDT
Message-Id: <9308131122.AA04355@ifcss.org>
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 4924; Fri, 13 Aug 93 07:21:12 EDT
Received: from UGA.CC.UGA.EDU (NJE origin LISTSERV@UGA) by UGA.CC.UGA.EDU (LMail V1.1d/1.7f) with BSMTP id 7006; Fri, 13 Aug 1993 07:21:11 -0400
Date:         Fri, 13 Aug 1993 04:20:18 -0700
Reply-To: Ed Lai <lai@APPLE.COM>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: Ed Lai <lai@APPLE.COM>
Subject:      Re: GB-1 really means GB 12345-90
Comments: To: CCNET-L@uga.cc.uga.edu
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
Status: RO

>there are far more than that! I found 240 or
>more 1->n mappings in GB-I (1) [3004 characters]
>into Big 5. GB-1 above zone 88 is reserved for
>user defined characters.

I probably used the wrong term, from Ross Paterson's
report of unicode

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

So what I am asking for is GB 12345-90

/* Disclaimer: All statments and opinions expressed are my own */
/* Edmund K. Lai                                               */
/* Apple Computer, MS37-AS                                     */
/* 20525 Mariani Ave,                                          */
/* Cupertino, CA 95014                                         */
/* (408)974-6272                                               */
zW@h9cOi

From @UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU Wed Aug 25 16:33:36 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 AA04014; Wed, 25 Aug 93 16:33:21 CDT
Message-Id: <9308252133.AA04014@ifcss.org>
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 1236; Wed, 25 Aug 93 17:31:53 EDT
Received: from UGA.CC.UGA.EDU (NJE origin LISTSERV@UGA) by UGA.CC.UGA.EDU (LMail V1.1d/1.7f) with BSMTP id 6937; Wed, 25 Aug 1993 17:18:27 -0400
Date:         Thu, 26 Aug 1993 05:17:50 +0800
Reply-To: Huang Chih-Hsien <hch@NCTUCCCA.EDU.TW>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: Huang Chih-Hsien <hch@NCTUCCCA.EDU.TW>
Subject:      Chinese Character Database (CCDB) (Was Re: 26000 characters)
Comments: To: ccnet-l@uga.uga.edu, twuniv-l@twnmoe10.edu.tw
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
Status: RO

Dear netters:

This is a brief introduction to the Chinese Character Database (CCDB).
It is available via anonymous ftp (I will set up a mail-ftp server
soon) at NCTUCCCA.edu.tw [140.111.3.21] in /Chinese/CCDB.  The total
size of materials after uncompressed including sources are about 42MB.

Enjoy!

------------------------------------------------------------------------
[Campus Computer Communication Assn., National Chiao Tung University
 NCTUCCCA.edu.tw: /Chinese/CCDB: ./README]

    The Chinese Character Database (CCDB) is developed by the Chinese
Character Analysis Group for Information Application, the Council for
Cultural Planning and Development, Executive Yuan.  Please read
./readme/readme.doc and ./readme/manual.doc before everything.  A
usage policy and some notes will be given.  You have to read them
carefully.

    Most of the Chinese pattern files are huge.  Although they were
compressed, however, we still got 3 files nearly or even over 4MB.
For consideration of users having slow access to our anonymous ftp
archive, we decided to keep two copies of the database: ZIP'd and
ARJ'd.

    All ZIP'd files are in the current directory.  If you don't know
how to unzip it, try to get "pkz204g.exe" in /PC-MsDos/Garbo-PC/arcers.

    ARJ'd files are in ./arj directory.  They are compressed and
splitted into pieces (no more than 360KB per file).  If you don't
know how to deal with ARJ'd files, try to get "arj241.exe" in
/PC-MsDos/Garbo-pc/arcers.

*** [ATTENTION] *******************************************************
All ZIP'd, ARJ'd and *.EXE files should be ftp'd in the *binary* mode.
***********************************************************************

--
Huang, Chih-Hsien     Campus Computer Communication Assn. Vice President
Administrator of  NCTUCCCA.edu.tw  [140.111.3.21]  Anonymous FTP Archive
Rm 101, Computer Center, National Chiao Tung University, Hsinchu, Taiwan
Internet:    hch@NCTUCCCA.edu.tw         or         hch@CCCA.NCTU.edu.tw

From @UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU Thu Aug 26 02:34: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 AA09455; Thu, 26 Aug 93 02:34:09 CDT
Message-Id: <9308260734.AA09455@ifcss.org>
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 2833; Thu, 26 Aug 93 03:32:29 EDT
Received: from UGA.CC.UGA.EDU (NJE origin LISTSERV@UGA) by UGA.CC.UGA.EDU (LMail V1.1d/1.7f) with BSMTP id 4659; Thu, 26 Aug 1993 03:32:25 -0400
Date:         Thu, 26 Aug 1993 16:31:26 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:      FAQ: What the hell is CCCII? (Was Re: 26000 Characters)
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
Status: RO

Dear CC-Netters,

There has been some talk recently about CCCII and I would like
to expand a little on that, to stimulate interest in CCCII.

First of all, thanks to Huang Chih-hsien and the NCTUCCCA for making
available this treasurehouse of Chinese Characters. I'm sure, this
will help getting CCCII implementations and will generally encourage
usage of CCCII more than any commercial application could, hopefully
to the benefit of all scholars dealing with Chinese.

What *IS*  CCCII?


CCCII (Chinese Character Code for Information Interchange) was
developped since the 70's sponsored by the Taiwanese gov. Propably
also due to some political reasons, it has not attracted much
attention among users of Chinese on computers, although it has
been widely adopted  for use in library catalogues in the US.

CCCII is a 3-byte code, developped in accordance with the ISO-2022
standard for multibyte-code extensions. CCCII is based on 7 significant
bits per byte, which makes it also net.compatible.

CCCII tries to cover virtually ALL Chinese Characters and it tries
not just to encode them, but also to encode the relationship among
the characters (Regular characters and variants etc.).


What are the benefits of CCCII?


CCCII is an existing standard which covers virtually all Chinese
Characters. No need to hussle around with privately defined
Characters.

The code is structured in a way, that makes conversion between
simplified and traditional Characters possible in both directions
without loss of Information. This can be done algorithmically, on
the fly, depending on the users need.

As an aside - non of this could be attained by UNICODE.



How is this achieved?

CCCII defines a very huge codespace of 94*94*94 = 830584 codepoints.
This space is devided into layers of roughly 52000 points.
One layer could be thought of as a chessboard, multiple layers would
then by several chessboards piled on top of each other.
The first layer defines the regular characters, more than 42000 are
assigned so far. The next layer defines the simplified Characters,
if they exist. That means, that the basic coordinate of the chess-
board reamains the same, you simple change the chessboard from
regular to simplified when changing to simplified characters.
This means of course that, if you have a simplified Character, to
which the shapes of three traditional Characters are assigned,
you would have the shape (or glyph) of this simplified Character
on three different places in the simplified chessboard layer.
To distinguish between them at the input-level, on would of
course have to use the traditional forms for input.

On top of the layer for simplified characters are ten more layers
for variant forms of the characters, above them are Characters from
other Asian Codes, like JIS and KSC.

This code-layout makes it possible for example, to have a text of
the Chinese Classics inputted and proofread exactly as it has been
printed, with all variant and even obsolete character shapes it
uses and still be able to have a simplified text for schoolbooks, or
a reading edition using the regular forms from the *same* text,
*without* additional proofreading.


How can I use CCCII?

To my knowledge, there has been only hardware dependent
implementations of CCCII (an add-on board for the IBM-PC,
which sells for more than 2000 US$). This is partly due
to the fact, that the handling of fonts for 70000 Character
shapes is surely demanding in terms of system resources.

On the other hand, given the constantly higher performance
even of standard PC, I'm sure these these technical problems
could quite easily overcome by implementors for MS-Windows or
th MAC OS. Given the availablity of all 70000 glyphs (in 64*64 bitmaps),
together with a databases for the 42000 regular Characters.

I believe that CCCII is the only solution for scholarly use
of computers, so I sincerely hope this will encourage some
developers to work with CCCII and to come up with some
solutions, which will soon proof to be far better for Chinese
than anything based on Unicode.

Things will look quite differently, of course, for true multilingual
data processing, as it is required for example in libraries. Here
the use of MULE (which could be adopted, I believe, to handle CCCII),
or in the future, of SGML-based systems will finally give way to
true mulitlinguality.

Summer Greetings from Kyoto,

Christian Wittern

From @UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU Fri Aug 27 05:07: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 AA24209; Fri, 27 Aug 93 05:07:48 CDT
Message-Id: <9308271007.AA24209@ifcss.org>
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 0184; Fri, 27 Aug 93 06:07:00 EDT
Received: from UGA.CC.UGA.EDU (NJE origin LISTSERV@UGA) by UGA.CC.UGA.EDU (LMail V1.1d/1.7f) with BSMTP id 8776; Fri, 27 Aug 1993 06:06:58 -0400
Date:         Fri, 27 Aug 1993 18:05:58 +0800
Reply-To: Chris Delucia <a1101006@CCMS.NTU.EDU.TW>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: Chris Delucia <a1101006@CCMS.NTU.EDU.TW>
Subject:      FAQ: What the hell is CCCII? (Was Re: 26000
Comments: To: ccnet-l@uga.cc.uga.edu
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
Status: RO

Thanks to Christian Wittern for the informative FAQ on CCCII.

I have used CCCII many times in the Taiwan University Library to check
catalogs at the Fu Sinian Lib (Acad. Sinica) & elsewhere here in Taiwan
(though I never successfully got into the Nat. Central Library catalog -
an additional password seems to be necessary there). Thinking ahead to
a time when I can't walk to the Taida library (like next week!), I've
wondered how one can access these Chinese libraries from abroad. Apparently,
with Big-5, one can get the menus, but can't look up books.

In an ftpsite directory, I can't remember which one, I came across some
files called "cccii.tbl" and "chgcode.exe" which apparently allow for
character conversion between CCCII and Big-5. I didn't check it out, but
I got the "readme" file on it. I called up the company that sold this
program a couple of months ago. The conversion program would be of no
use in trying to log into Chinese libraries remotely, but they also
sold a commercial version of CCCII (that apparently could). I don't have
the name or phone # of this company handy (I'm packing & leaving for the
US in 2 days), but I recall that the CCCII program was called something
like "Da4 Han4." It cost something along the lines of $50,000 NT (nearly
$2000 US) for their basic system of 20,000 characters, and @ $100,000 for
the full system of 50,000 (and at least 1 intermediate version, 30,000?).

Does anyone have any details on this program, or know someone who's used
it? Though obviously not priced for Sinologists, it does indicate some
commercial interest in the CCCII direction. It is supposedly available
in computer stores, but in my few brief trips this summer to computer
stores I didn't see it.

My main concern, as I'm sure is the case with many CCNETers as well,
is simply being able to produce all the characters I need to use.
I am not a programmer, so it doesn't really matter to me if the character
is represented by 1, 2 or 3 bytes (though it may matter to my HD). I
guess there are two ways of being able to meet my needs - an affordable
CCCII-like program that comes with virtually every character that appears
in extant texts, or a program that's more streamlined but has a good
character creation utility. I currently use ETEN Flying Saucer (Feidie)
#5, which has a 24 X 24 pixel (for printing out) character editor. It's
not pretty, but it works. A few months ago, in the process of inputting
some Han dynasty literature, I created about 50 characters. Naturally,
I didn't bother to create variant character forms unless there was something
otherwise significant to discuss about it. Let's say there were @ 40
that were unique characters. Of these 40 or so, I was able to locate most
(@ 30) in vol 2 of _The Unicode Standard_. So, much better than Big-5, but
I still would have had to create several characters.

I am looking forward to any and all developments in increasing the number
of available characters (CCCII, Unicode & Guangyun each have their merits),
but I think character editors should be developed too. Even with Unicode
or Guangyun character pools, I would still have to create the occasional
character (maybe that wouldn't be the case for CCCII, who knows). As for
current users of Big-5, I would guess that the vast majority rarely needs
to use characters outside of that set. If someone only encounters the
need to create a character a few times a year, it's probably not worth
hundreds or thousands of dollars to have 30,000 characters sit there on your
hard drive. I'm not familiar with all the types of character editing/
creating utilities, but I do know that Chinese Windows has TrueType fonts,
but a TrueType font editor still does not exist.

Well, I've spent more time on this than I should. Hope this discussion is
still going strong in a couple of days when I check in from the Far West.
If anyone wants to write me directly, my Taiwan U. account will remain
active for a while, so I can try to respond from the US.

                        Chris DeLucia
                        a1101006@ccms.ntu.edu.tw


Re:

> First of all, thanks to Huang Chih-hsien and the NCTUCCCA for making
> available this treasurehouse of Chinese Characters. I'm sure, this
> will help getting CCCII implementations and will generally encourage
> usage of CCCII more than any commercial application could, hopefully
> to the benefit of all scholars dealing with Chinese.

.....

> How can I use CCCII?
>
> To my knowledge, there has been only hardware dependent
> implementations of CCCII (an add-on board for the IBM-PC,
> which sells for more than 2000 US$). This is partly due
> to the fact, that the handling of fonts for 70000 Character
> shapes is surely demanding in terms of system resources.
>
> I believe that CCCII is the only solution for scholarly use
> of computers, so I sincerely hope this will encourage some
> developers to work with CCCII and to come up with some
> solutions, which will soon proof to be far better for Chinese
> than anything based on Unicode.

From @UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU Mon Aug 30 07:56:36 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 AA26221; Mon, 30 Aug 93 07:56:26 CDT
Message-Id: <9308301256.AA26221@ifcss.org>
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 1673; Mon, 30 Aug 93 08:54:56 EDT
Received: from UGA.CC.UGA.EDU (NJE origin LISTSERV@UGA) by UGA.CC.UGA.EDU (LMail V1.1d/1.7f) with BSMTP id 3157; Mon, 30 Aug 1993 05:25:48 -0400
Date:         Mon, 30 Aug 1993 18:24:56 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:      Re: FAQ: What the hell is CCCII? (Was Re: 26000 Characters)
Comments: To: ccnet-l@uga.cc.uga.edu
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
Status: RO

  This question was asked in private mail, but as this might be
  of general interest, I hope the sender will not object, that I
  answer in public.

  > In message <9308261613.AA22498@bochap.iss.nus.sg> you write:
  > >
  > > What *IS*  CCCII?
  > >
  > > to the fact, that the handling of fonts for 70000 Character>
  >
  > > Christian Wittern
  >
  > Hi,  these days I really got confused on the number of characters defined in
  > CCCII.  Once I read it as "more than 74000", you said above "70000", but most
  > one quoted it as "more than 50,000".  Could you give me a clear picture?
  > Thanks.
  > GUO Jin

  This is a tricky one. It depends on what you count as a character. CCCII
  defines not just a code, which is a place for each character to live in,
  but also defines some relationship of characters in terms of variant
  forms (and of course trad./simpl. forms). In addition to that, depending
  on the context, a given character could be considered a variant (same
  reading and meaning as the regular form), or as a regular form by itself.
  CCCII doesn't hesitate to give the same glyph various places in the
  vast codespace it defines. So, although this is very difficult to
  establish this, the number of distinguishible glyphs in CCCII might be
  close to 50000, who knows. But the number of assigned codeplaces and
  corresponding bitmaps is more than 70000 or, to be more exact, close to
  75000 thousand.
  The number of regular Characters is around 42000, whereas the variants,
  including simplified forms, amount to ca. 33000.

  I hope this helps.

  Christian

From @UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU Mon Aug 30 08:21:36 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 AA26347; Mon, 30 Aug 93 08:21:23 CDT
Message-Id: <9308301321.AA26347@ifcss.org>
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 2171; Mon, 30 Aug 93 09:19:59 EDT
Received: from UGA.CC.UGA.EDU (NJE origin LISTSERV@UGA) by UGA.CC.UGA.EDU (LMail V1.1d/1.7f) with BSMTP id 0965; Mon, 30 Aug 1993 09:19:57 -0400
Date:         Mon, 30 Aug 1993 08:43:03 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:      CCCII sets
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
Status: RO

I also got a question about the total number of CCCII characters. From
a small publication, Guozi zhengli xiaozu shinian, published by CCCII in Dec.
1989 (officially, but in fact much later), I culled the following figures.

Note that the group has a very Sino-centered and normative approach to
what it calls "orthodox" and variant characters; it is rather virulently
(in this booklet) opposed to any Han-unification as Unicode (which it sees
as a Japanese-Communist plot), and to simplified characters as characters in th
eir own right. Since CCCII was heavily involved in the first code using
Han unification, i.e. the American ANSI/EACC code, I don't know what made
them change their position. They're also very against the Chinese National
Code (Taiwan) as well; we are not talking about a disinterested objective
computer body here! This does not preclude the usefulness of their work
of course.

The total number of characters collected by the group is 75,684; this
breaks down into 44,167 official characters, and 31,517 variants. Only the
6,763 simplified characters of GB 2312 are included, as "variants"; apparently
also if there is no difference whatsoever between a GB and an "official" glyph.

This number does NOT include the 6,349 Japanese characters (apparently, again,
no matter what the glyph is), 171 kana signs, and 2028 hanmun combinations,
all limited apparently to the smallest official codings of Japan, Korea and
the PRC.

(Since -almost- any character can and has been used in Japanese and Korea,
since there are Korean "kokuji", and since there are many more simplified
characters (through simplified radicals!) possible than the mere 6,763 of
the GB2312 - and why not the other GB codes?, this way of counting seems
ridiculous; one would have to end up with some 50,000x4 "different" charac-
ters at least!)

Not all these characters have been published, and have gone through CCCII's
mysterious validation process. Published are: Common characters (4,808),
Useful characters (17,302), Rare characters (20,583) and Variants (11,517),
for a total of 53,940; the other 20,000+ characters are said to be in the stage
of beta-checking.

As I said before, more interesting is the fact, that the group found IN ADDITIO
N to the 75,684 some 9,000 characters "with no way of recognizing them". They
come from the automated files of the Ministry of household registration and
other agencies; they were expected to be investigated through the early
nineties; I don't know whether the files have them or not.

In addition to these compilations and codings, the CCCII group also tries,
as have Japan, Korea, and the PRC done before, to actually standardize
(with the object of normative enforcement) script FONTS: FangSongti, XiMingti,
Mingti, Kaishuti, and Songti. Let's hope they are not succesful; it is a
blatant effort of all these countries to put extra difficulties in the way
of foreign computer makers and/or font developers, especially now that the
opposition against Unicode has failed (Japan AND Taiwan were heavily against
it!) The fact that some of the orthodox characters (which e.g. prescribe diffe-
rentiations not commonly adhered to, as between the moon- and meat-radicals)
can look rather strange, is yet quite another matter; the reason is, again,
politics -against the Japanese domination of the printing industry-, so
I won't comment upon that on this listserv.

Martin Heijdra/Gest/Princeton

From simpson@math.psu.edu Tue Sep  7 11:06:56 1993
Return-Path: <simpson@math.psu.edu>
Received: from leibniz.math.psu.edu by ifcss.org (4.1/IFCSS-Mailer)
	id AA09184; Tue, 7 Sep 93 11:00:28 CDT
Received: from boole.math.psu.edu by leibniz.math.psu.edu with SMTP 
	(5.65+/psu-relay-1.1) id AA14012; Tue, 7 Sep 93 11:58:57 -0400
From: Stephen G Simpson <simpson@math.psu.edu>
Received: by boole.math.psu.edu (5.65+/psu-lanleaf-1.3)
	id AA04560; Tue, 7 Sep 93 11:58:56 -0400
Date: Tue, 7 Sep 93 11:58:56 -0400
Message-Id: <9309071558.AA04560@boole.math.psu.edu>
To: soft-authors@ifcss.org
Status: RO

Ross Paterson <rap@doc.ic.ac.uk> writes:

> My understanding is that EUC is a scheme for mixing text from up to
> 4 character sets, using the following byte sequences:
> 
> 	set 0	00-7f		ASCII (narrow)
> 	set 1	GR GR		wide characters
> 	set 2	8e GR		extra narrow set
> 	set 3	8f GR GR	extra wide set
> 
> Here GR (Graphic Right) means the range a1-fe.  The wide sets are two-byte
> codes using the ranges 21-7e, like GB, JIS or KSC.  The narrow set is a
> one-byte code.  For example, the X locale zh_CN.ugb has GB as set 1 and
> the pinyin row of GB as set 2.  The zh_TW.big5 locale has the two CNS
> sets as sets 1 and 3.  Japanese locales have JIS-208 in set 1, JIS-201
> (katakana) in set 2, and JIS-212 in set 3.
> 
> So I think EUC is best treated as accessing a set of fonts, each using
> HBF files which probably already exist.  It's up to the application
> program to process the EUC text.

Ross, thanks for the concise explanation.  You know, I read some
articles about EUC but it didn't explain it this well.  I'm sure
you're right -- there is no need to extend HBF to take account of EUC.

-- Steve

From simpson@math.psu.edu Tue Sep  7 12:09:54 1993
Return-Path: <simpson@math.psu.edu>
Received: from leibniz.math.psu.edu by ifcss.org (4.1/IFCSS-Mailer)
	id AA09853; Tue, 7 Sep 93 12:07:44 CDT
Received: from boole.math.psu.edu by leibniz.math.psu.edu with SMTP 
	(5.65+/psu-relay-1.1) id AA14579; Tue, 7 Sep 93 13:06:04 -0400
From: Stephen G Simpson <simpson@math.psu.edu>
Received: by boole.math.psu.edu (5.65+/psu-lanleaf-1.3)
	id AA04607; Tue, 7 Sep 93 13:06:03 -0400
Date: Tue, 7 Sep 93 13:06:03 -0400
Message-Id: <9309071706.AA04607@boole.math.psu.edu>
To: soft-authors@ifcss.org
Cc: handa@etl.go.jp
Subject: some ideas about extending HZ to Big5
Status: RO

To: Chinese software authors discussion list

Concerning possible extensions of the HZ standard to cover Big5, I
guess you remember that we had a little discussion about this some
time ago.

In the meantime I have been looking at Mule, a multilingual extension
of GNU Emacs developed by Ken'ichi Handa <handa@etl.go.jp> and some
other people in Japan.  The Mule-junet file format is interesting
because it allows you to mix multiple character sets such as ASCII,
GB, Big5, JIS, KSC, ISO-Latin1, etc. etc. using escape sequences to
switch from one character set to another.  Furthermore, Mule-junet
files are 7-bit files and can be sent everywhere by e-mail.  In
addition to standard printable ASCII, the only other character that
appears in Mule is the Escape character, 0xB1.  Some of the escape
sequences used in Mule-junet are:

Escape $ ( A           switch to GB2312
Escape $ ( 0           switch to Big5 level 1
Escape $ ( 1           switch to Big5 level 2
Escape , A             switch to ISO-Latin1
Escape ( B             switch to ASCII

Big5 levels 1 and 2 are packed into the 0x21-0x7E 0x21-0x7E range, in
order, using the B2G macro in mule/src/codeconv.h.

So far as I can tell, the Mule-junet file format is peculiar to Mule,
i.e. it is not supported by other software.  However, it is an
extension of the format used in Japanese e-mail, and it is closely
related to international standards such as ISO 2022 and EUC.  (But I
don't understand these standards very well.)

It is interesting to note that HZ is already in a sense compatible
with Mule-junet, the only big difference being the use of ~{ and ~}
instead of ESC $ ( A and ESC ( B.  So, perhaps we should consider
extending HZ in a way that retains this kind of compatibility with
Mule-junet and related international standards.

Any thoughts on how to do this?

I mentioned this matter to Ken'ichi Handa and he came up with the
following:

 > I also once considered the way to extend HZ for
 > multilingual.  My idea was to put <F> (final character such
 > as 'A' for GB, 'B' for JIS) just after ~ to make it
 > compatible with the current HZ.  So,
 > 	GB -- ~A{ or ~{
 > 	JIS -- ~B{
 > 	KSC -- ~C{
 > 	BIG5-1 -- ~0{
 > 	BIG5-2 -- ~1{
 > 	ASCII -- ~}  (no change)
 > But this method is limited to such character sets that
 > never use the sequence ~}.  Laint-1 can't be used with this
 > way of extension.

Any thoughts on how to solve this problem?

-- Steve Simpson

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 AT PSUVM
FAX: +1 814 865-3735

From mcpong@cs.ust.hk Mon Oct  4 21:36:03 1993
Return-Path: <mcpong@cs.ust.hk>
Received: from cssu2.cs.ust.hk by ifcss.org (4.1/IFCSS-Mailer)
	id AA13655; Mon, 4 Oct 93 21:21:11 CDT
Received: by cssu2.cs.ust.hk (4.1/SMI-4.1)
	id AA00846; Tue, 5 Oct 93 10:19:43 HKT
Date: Tue, 5 Oct 93 10:19:43 HKT
From: mcpong@cs.ust.hk (Dr. Man-Chi PONG)
Message-Id: <9310050219.AA00846@cs.ust.hk>
X-Mailer: Mail User's Shell (7.2.5 10/14/92)
To: soft-authors@ifcss.org
Subject: GuoBiao & GB6345
Status: RO

I think it's important to clarify the difference between a "coding standard"
and a "standard on the shapes of glyphs", so that the readers are not
confused.

Guobiao = ~{¹ú¼Ò±ê×¼~} guojia biao, meaning "National Standard"
PRC government has many "guobiao", e.g. about size of bolts and nuts, etc.

GB2312-80 is a ***HANZI CODING STANDARD***
-- the title is ~{ÐÅÏ¢½»»»ÓÃºº×Ö±àÂë×Ö·û¼¯»ù±¾¼¯~}
-- (my direct translation to English) is
   "character set, basic set, of Chinese character encoding 
   for information interchange"

There are other PRC government ***HANZI CODING STANDARDs***, say,
for traditional Chinese characters.

===========
GB6345.1-86 is a ***standard on the shapes of glyphs***
-- the title is ~{ÐÅÏ¢½»»»ÓÃ32x32µãÕó×ÖÄ£¼¯~}
-- (my direct translation to English) is
   "32x32 bitmap glyph set for information interchange"

GB6345.2-86 is a standard on the DATA of the glyphs of GB6345.1-86
-- the title is ~{ÐÅÏ¢½»»»ÓÃ32x32µãÕó×ÖÄ£¼¯ Êý¾Ý¼¯~}.
					    ^^^^^^
			    the bitmap DATA SET for GB6345.1-86

They include some glyphs not defined in GB2312-80, and use
some "code points" (as some writers use such term) from the
"unused encoding space" of GB2312-80 to encode those glyphs.

There are other PRC governemnt published glyph sets of
various bitmap sizes; e.g.,

GB5007.1-85 is ~{ÐÅÏ¢½»»»ÓÃ24x24µãÕó×ÖÄ£¼¯~}.
GB5007.2-85 is ~{ÐÅÏ¢½»»»ÓÃ24x24µãÕó×ÖÄ£¼¯ Êý¾Ý¼¯~}. data set
GB5199.1-85 is ~{ÐÅÏ¢½»»»ÓÃ15x16µãÕó×ÖÄ£¼¯~}.
GB5199.2-85 is ~{ÐÅÏ¢½»»»ÓÃ15x16µãÕó×ÖÄ£¼¯ Êý¾Ý¼¯~}. data set
===========

> From khsc@synoptics.com Tue Oct  5 01:59:15 1993
> Subject: Re:  GB6345
>
> ...
> If I can
> squeece out more time, I will create a gb6345.16 file and the associate
					 ^^^^^^^^^
> HBF file for the 16 bit fonts.

So, if one really makes a size-16 glyph set conforming to the PRC government
standard, one should conform to GB5199.1-85 & GB5199.2-85. 

===========

Probably the question orginates from:

> From khsc@synoptics.com Tue Oct  5 01:59:15 1993
> Subject: Re:  GB6345
>
> ...
> My original reason for creating gb6345.24 (bitmap file for gb6345) was
> to to allow me to write a HP laser printer printing program which allows
> mix GB and ascii code. I am sure that anyone who has attempt the effort
> has encounter the same problem.  GB is two byte long and ASCII is one byte
> long, it is only natural that a Chinese ideogram occupy twice the width of
> an ASCII character.  now the problem is that GB bitmap is defined in an
> externl file such as cclib.*24, and ASCII font is not.  I need an ASCII
> bitmap file that is half the width of the GB bitmap file.
> ...

	Whether we really should allow an HBF file to
	specify variable width glyphs in the same HBF file?
I'd oppose the idea.

To do mixed width char output (say, for ASCII char & hanzi),
one can use 2 HBF files, one for the ASCII bitmaps and one
for the hanzi bitmaps.  (The bitmaps may be in the same or
different bitmap files.)

The kuochiao 16x16 hanzi bitmaps & 16x14 symbol bitmaps are
similar in nature, and F.F.Lee has posted a way to tackle this
problem.  Please see Lee's earlier posting.

mcpong

From @UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU Tue Oct 12 10:03:10 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 AA18420; Tue, 12 Oct 93 10:02:14 CDT
Message-Id: <9310121502.AA18420@ifcss.org>
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 1848; Tue, 12 Oct 93 11:00:36 EDT
Received: from UGA.CC.UGA.EDU (NJE origin LISTSERV@UGA) by UGA.CC.UGA.EDU (LMail V1.1d/1.7f) with BSMTP id 7800; Tue, 12 Oct 1993 11:00:34 -0400
Date:         Tue, 12 Oct 1993 15:47:13 BST
Reply-To: "L.S.Ng" <L.S.Ng1@SOUTHAMPTON.AC.UK>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: "L.S.Ng" <L.S.Ng1@SOUTHAMPTON.AC.UK>
Subject:      Feichangguizi Example
Comments: To: Chinese Computing Network <ccnet-l@uga.cc.uga.edu>
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
Status: RO

Following is an example of Feichangguizi Protocol:

BEGIN:

GBAFAFZB16BCDB12B323B45B5B6B7B6B67B6B7B78B9B8B9B8BB74BB3B4B3B4B54B45B31B

~{LlL(4sJ&SVC{VG//4sJ&~}

END.

The first line GBAFAF defines that GB blank region code AFAF uses a
bitmap 16x16 (ZB16) and following that is a string of Hexadecimal
numbers that defines the bitmap itself.

The next line is a Hz code Chinese sentence reads:

Tiantai Dashi you ming Zhi Yi DaShi

(Master Tiantai is also known as Master Zhi-yi)

The Character 'yi' is not in the standard GB table.  So I use AFAF to
represent it, (it appears in HZ as //).  The definition of the character
is given by the string of hex number.  Each hex number (2 characters)
can represent 8-bit.  So each row of the character bitmap is represented
by 4 characters, there are 16 rows to make up the 16x16 bitmap.

The decoder (e.g.  a Terminal Emulator like Eten or CXterm, or a
Wordprocessor) will read the bitmap definition (first line) into a
buffer.  Then it will start decoding and displaying the next line.  Upon
reading '//' i.e.  (GB AFAF) it then uses the bitmap definition given in
previous line.

(Producing this bitmap hex code can be done by the Wordprocessor.)

From @UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU Sat Oct 16 03:20:04 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 AA12446; Sat, 16 Oct 93 03:19:59 CDT
Message-Id: <9310160819.AA12446@ifcss.org>
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 9450; Sat, 16 Oct 93 04:18: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 7426; Sat, 16 Oct 1993 04:18:50 -0400
Date:         Sat, 16 Oct 1993 16:19:41 +0800
Reply-To: guojin@ISS.NUS.SG
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: Guo Jin <guojin@ISS.NUS.SG>
Subject:      KC and CHS<->CHT
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
Status: RO

Hi, there,

I found a big5->gb conversion table, kcgb.ovl, in the KC package.  Has
anyone tried this table and/or KC's conversion function?

Also in this package, there is another file, kcgb5.ovl.  Does anyone know
what it is and how it is arranged?

Thanks.

guojin@iss.nus.sg

From asiandoc-request@magnus.acs.ohio-state.edu Sat Oct 23 21:39:46 1993
Return-Path: <asiandoc-request@magnus.acs.ohio-state.edu>
Received: from quark.magnus.acs.ohio-state.edu by ifcss.org (4.1/IFCSS-Mailer)
	id AA09634; Sat, 23 Oct 93 21:39:44 CDT
Errors-To: asiandoc-request@magnus.acs.ohio-state.edu
Received: by quark.magnus.acs.ohio-state.edu (5.65/3.910213)
	id AA17164; Sat, 23 Oct 93 22:36:23 -0400
Reply-To: asiandoc@magnus.acs.ohio-state.edu
Errors-To: asiandoc-request@magnus.acs.ohio-state.edu
Sender: asiandoc-request@magnus.acs.ohio-state.edu
Received: from bitnet-gateway.uiowa.edu by quark.magnus.acs.ohio-state.edu (5.65/3.910213)
	id AA17159; Sat, 23 Oct 93 22:36:22 -0400
Received: by bitnet-gateway.uiowa.edu (5.64.jnf/930611)
	  on Sat, 23 Oct 93 21:36:20 -0500 id AA20216 
Message-Id: <9310240236.AA20216@bitnet-gateway.uiowa.edu>
Received: From uiamvs.bitnet By uiansmx.bitnet ; 24 Oct 93 02:36:18 GMT
Date:    Sat, 23 Oct 93 21:34 CDT
To: asiandoc@magnus.acs.ohio-state.edu
From: Hideyuki Morimoto 319-335-5886       <MORIMOTS@UIAMVS.BITNET>
Subject: Re: CCCII, EACC, and 9term questions
Status: RO

In reference to the posting related to CCCII/EACC, while I have
no information regarding the second question, some data may be
provided pertaining to the first point.

> 1.  Are CCCII and EACC (two multibyte codesets, the former used by
> libraries in Taiwan and Hong Kong and the latter by the Library of
> Congress, RLIN, and OCLC) identical?  If not, what are the major and
> minor differences?  Is translation between the two non-trivial?

CCCII (Chinese Characater Code for Information Interchange) was
developed in Taiwan prior to REACC.  The RLG then developed REACC, the
administration of which was then transferred to the Library of Congress
to become, with the appellation EACC, the American National Standard
for East Asian Character Codes for Bibliographic Use
(ANSI Z39.64-1989).  EACC is an amalgam of CNS, CCCII, Guojia Biaojun,
JIS, Korean Standard Code, and other codes; however, as was suspected,
it is apparent that the REACC development heavily relied on the already-
existing CCCII system.  EACC, thus, presents a trace of similarity
to CCCII.  For example, all characters for I-hs"uan Lin-chi lu have
the identical numeric codes in both EACC and CCCII.

     character for                 EACC #             CCCII #
      I                             215244             215244
      hs"uan                        214B30             214B30
      Lin                           215425             215425
      chi                           3F4926             3F4926
      lu                            215D74             215D74

Nevertheless, some characters represented in EACC are missing in
CCCII.  In other words, EACC and CCCII are not completely identical.
For instance, some characters forged in Japan after Chinese character
elements (usually referred to as "kokuji's," which are *NOT* kana's)
are not included in CCCII.

     character for                 EACC #        JIS #      CCCII #
      kogarashi (cold blast)        69515E        515E       missing
      maro (an obsolete pronoun for
             first person singular) 694B7B        4B7B       missing

Translation between EACC and CCCII for those codes appearing in both
systems should not be complicated.  The CJK Thesaurus, for example, is
available on RLIN.  In each record representing a unique character, the
numeric code of EACC as well as CCCII, if there is one, is entered,
which would enable use of this Thesaurus as a rendition table between
the two systems.

Hideyuki Morimoto
University Libraries, University of Iowa
hideyuki-morimoto@uiowa.edu

From @UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU Tue Nov  9 03:10:35 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 AA11507; Tue, 9 Nov 93 03:10:25 CST
Message-Id: <9311090910.AA11507@ifcss.org>
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 9595; Tue, 09 Nov 93 04:07:55 EST
Received: from UGA.CC.UGA.EDU (NJE origin LISTSERV@UGA) by UGA.CC.UGA.EDU (LMail V1.1d/1.7f) with BSMTP id 6614; Tue, 9 Nov 1993 04:07:54 -0500
Date:         Tue, 9 Nov 1993 04:07:52 EST
Reply-To: Duh? <bo@SAAVIK.STANFORD.EDU>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: Duh? <bo@SAAVIK.STANFORD.EDU>
Subject:      Extended HZ coding scheme...
Comments: To: ccnet-l@uga.cc.uga.edu
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
Status: RO

Hi all,
Through private communication with J.Zhang (zhang@utkvx.utk.edu), my mind
became clearer in the possibility for an extended coding scheme based on HZ.
The idea is embarrasingly simple -- chances are that it's been out there or
discussed years ago. If that were the case, my apologies. I'll give an outline
first so that you wouldn't have to waste too much time if it turns out to be
worthless. In any case, I intend this post as an oppotunity to learn more
about Chinese programming.

The scheme:
1. Use two-byte coding with full 256 spaces for each byte. A 7-bit ASCII
subset can be used as a compromise for e-mail.
2. Divide the 64k coding space into 8 ranges, each corresponding to a commonly
used Chinese font (Song4, Fang3Song4, Kai3, simplified, traditional, etc) with
8192 characters/symbols.
3. Expand the escape sequence for switching between ASCII and Chinese to 4 byte
long.

Advantages:
1. Optimal usage of coding space.
2. Enhance performance in font lib access, and even less memory usage.
3. Allow effortless support for mixing fonts/styles in one document.
4. Help developing a standard set of font libs.
5. Virtually eliminate mis-intepretation of ASCII <-> Chinese.

Now some detailed explanations:

1. I understand that the 94-member group of HZ coding was intended to
accomodate some brain-dead mailers that can only handle typable (printable?)
ASCIIs. A smallest-common-denominator scenario that we've all come too familiar
with. But I suspect that the portion of those brain-dead mailers in use today
is small and decreasing. Mailers capable of full 7-bit (or even 8-bit) ASCII
are becoming more and more popular.
   With full 256/byte coding, we have 64k slots to play with. For 7-bit ASCII
communication, we can easily take out that 16k subset and still get almost
twice the space as in HZ.
   Of course, you could go further. And there're some Grand Coding that intend
to include all human languages on earth. For the time being let's focus on
good'ol ASCII and Chinese.

2. You could use the full 64k coding space to include lots of weird Chinese
chars that no one but a few archeologists could recognize. Well, we shouldn't
let those archeologists drag us all down. I think 8k chars should be sufficient
for most "normal" usage.
   So let's break the coding space into 8 chunks, each 8k big. The first chunk
corresponds to Fang3Song4 font. Kai3 font goes from 2000h to 3fffh. And so on.
We have 8 different fonts included in one coding scheme. Alternatively, we
could have four fonts each for simplified and traditional styles.

3. Say the font defaults to Fang3Song4. To change to Kai3 font, the programm
simply adds 2000h to each char's default code.
   Mapping the code to the proper font lib, in this scheme, can and should be
done by a highly optimized and standard printf routine. The printf takes one
explicit argument -- the code. But it should implicitly (via header file or
env variables) take the names of font lib files. Conceivably, the printf does
font-lib mapping according to the higher 3 bits of the code, in assembly
language. Then it simply stripps the 3 bits and goes into the particular lib.
   Once such a printf routine is done, support for mixing fonts/styles becomes
a non-issue. As I understand, currently such support is far from trivial, and
everyone re-invents the wheel as to how to support font mixing. Furthermore,
there is no need for additional font tags. It's just the higher 3 bits of the
code, and interpreted by printf. The programmer using the printf can totally
forget about it.
   If the 7-bit ASCII subset is to be used, then the sub-coding-space would
be non-contageous: 0000h-007fh, 0100h-017fh, ...7f00h-7f7fh. We have two 8k
chunks. But switching among the two is essentially the same mechanism, just
with an offset value of 4000h.

   As to choosing between 8 fonts with single style or 4 fonts each for
simplified and traditional styles, I'd say the need for mixing styles doesn't
come up so often.

4. Currently HZ uses a 2-byte combo to signify transition from ASCII to
Chinese and then another combo for the reverse. In practice, I find that this
sometimes results in mis-interpretation.
   As a heuristic estimate, let's assume equal probability distribution for
the 8-bit combinations. The probability for a random hit of the two-byte
escape sequence is 1/64k -- one screw-up for every 64k of a file. Not small
enough in my judgment. Why not use 4 bytes? The chance for random hit would
be 1 in 4 billion. Or more, for that matter. The transition doesn't occur
often for typical files. Therefore, the increase in file size is trivial.
Only those bytes causing confusion would need extra processing in the new
scheme. So the performance degradation shoudl also be trivial.

All flames/comments/dsicussions welcome.

Bo Peng

From @UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU Sun Nov 21 18:44:25 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 AA27696; Sun, 21 Nov 93 18:44:15 CST
Message-Id: <9311220044.AA27696@ifcss.org>
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 2693; Sun, 21 Nov 93 19:41:57 EST
Received: from UGA.CC.UGA.EDU (NJE origin LISTSERV@UGA) by UGA.CC.UGA.EDU (LMail V1.1d/1.7f) with BSMTP id 9080; Sun, 21 Nov 1993 19:41:55 -0500
Date:         Sun, 21 Nov 1993 19:41:20 -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:      Re: Big5
Comments: To: susan lasovick <lasovick@world.std.com>
Comments: cc: ccnet-l@uga.cc.uga.edu
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
In-Reply-To:  <199311212057.AA14661@world.std.com>
Status: RO

To: Susan Lasovick <lasovick@world.std.com>

 > I would be very interested to know the proportion of GB in use in Hong
 > Kong

I don't have any solid information here.  Why not post this question
on CCNET?

One relevant fact is that GB-2312-1980 is unsuitable for traditional
Chinese characters.  Since almost all printed Chinese documents in
Hong Kong use traditional characters, I would guess that GB is not
widely used, for practical reasons.  Of course this may change after
the PRC takeover.

The PRC government is rumored to have GB extensions which handle
traditional Chinese characters.  However, I have never seen any fonts
for these extensions, nor have I seen any software that uses these
extensions.  My guess is that the PRC government wants to discourage
the use of traditional characters and therefore restricts their use to
special printing houses that print documents for foreign consumption,
e.g. the overseas edition of People's Daily.  The fonts are therefore
not available to the general public.

 > When you say 'stick to the ETEN coding,' do you mean the ETEN
 > coding itself or the base standard Big5?

The Eten coding scheme consists of the base standard Big5 plus some
useful extensions which cover Japanese Kana, Cyrillic, etc.  Certainly
you should implement Big5, but if I were you I would also implement
Eten's extensions as much as possible, because Eten is so very
popular.

I imagine that this would be almost a business necessity.  For
example, there is a rival Big5 product similar to Eten, called KC, and
KC has its own set of extensions, different from Eten's.  However KC
bows to Eten by implementing an Eten compatibility mode, in which
Eten's extensions override KC's extensions.

Incidentally, there are freely available Unicode tables which give the
mappings from GB, Big5, etc. into Unicode.

-- Steve Simpson

From @UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU Mon Nov 22 21:44:44 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 AA17197; Mon, 22 Nov 93 21:44:15 CST
Message-Id: <9311230344.AA17197@ifcss.org>
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 1385; Mon, 22 Nov 93 22:41:27 EST
Received: from UGA.CC.UGA.EDU (NJE origin LISTSERV@UGA) by UGA.CC.UGA.EDU (LMail V1.1d/1.7f) with BSMTP id 9748; Mon, 22 Nov 1993 22:41:24 -0500
Date:         Mon, 22 Nov 1993 18:15:36 GMT
Reply-To: "L.S.Ng" <L.S.Ng1@SOUTHAMPTON.AC.UK>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: "L.S.Ng" <L.S.Ng1@SOUTHAMPTON.AC.UK>
Subject:      Big5 and OTHER Guobiao
Comments: To: Chinese Computing Network <ccnet-l@uga.cc.uga.edu>
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
Status: RO

>From lsn Mon Nov 22 18:12:15 1993
Date: Mon, 22 Nov 93 18:12:15 GMT
To: simpson@EDU.PSU.MATH
Subject: Re: Big5 & Guobiao(s)
In-Reply-To: <no.id>; from "Stephen G Simpson" at Nov 21, 93 7:41 pm
X-Mailer: ELM [version 2.3 PL11]


>From the posting by John Delacour the other day, we learned that there
are in fact many Guobiao Coding subsets already defined.

The Chinese Name for GB2312-80 is 'Ji1-Ben3-Ji2' which means 'Basic
Set', from which I gather that it is the smallest subsets of all Guobiao
coding sets. Futher, I infer that the PRC Government has in foresight
lay down the coding scheme for many possible applications, well
including the Traditional Character sets for research purposes.

But the question I would like to ask is where can we find the Bitmap
fontfile (or better, scaleable) for other 'BIGGER' Guobiao?

(The fullname for GB2312 is Zhonghua Renming Gongheguo - Guajia Biaozun
                              China  People  Republic  National Standard

- Xinxi   Jiaohuan   Yong - Hanzi Bianma     Zi4      Fu3    Ji2
  "Info" "Exchange""Purpose"             "Character""Symbol""Set"

..cont..  *** Ji1 Ben3 Ji2 ***)


> The PRC government is rumored to have GB extensions which handle
> traditional Chinese characters.  However, I have never seen any fonts
> for these extensions, nor have I seen any software that uses these
> extensions.  My guess is that the PRC government wants to discourage
> the use of traditional characters and therefore restricts their use to
> special printing houses that print documents for foreign consumption,
> e.g. the overseas edition of People's Daily.  The fonts are therefore
> not available to the general public.

Your 'guess' seems to base on some prejudice over the PRC Government
:-) This hypothesis sounded superb. But I prefer a gentler alternative.



IMO, the popularity of Guobiao 2312 i.e.  the BASIC SET is due to its
size :-) It the olden days of PC XT, each disk is 360K.  Most PC has
only one or two 360 floppy disk drive.  So each GB2312 fontfile (aboout
250K) would fit in nicely into a disk.  It have been TEN good years ever
since the publication of GB2312 (in 1980) until better PC fitted with
hard-disk get popular.  In the meantime, GB2312 has become the de facto
standard for 'the rest of China'.

On the contrary, in Big5 coding scheme, some vendors (e.g.  Eten) chose
to use a 16x15 character bitmap instead of a 16x16.  This save 2 bytes
per character.  So each 16x15 character occupy 30 bytes.  Say there are
about 14000 characters in Big5 (sorry to Bruce Liu, my memory is quite
bad, I couldn't remember the exact number most of the time).

So this would made up to about 420K.  The saving in using 16x15 instead
of 16x16 is about 28K.  And in the early versions of Eten, (even up to
ver 3.0), the bitmap fontfile were split into multiple files for dubious
reasons.  And now I guess it is because the character set is too big!!

It is good for the PRC government to have thought of using a smaller
set. And I believe that they have already BIGGER set of Guobiao. (in
use?? perhaps someone from China can clarify this?)

On the other hand, the Taiwanese has Big5 as the SMALLEST set and this
decision has given them a lot of trouble. (Of course, the merit is that
now Big5 is the de facto for traditional characters; It could well be
other Bigger Guobiao(s))

For example, Big5 has to use a 15 bit coding scheme (Highbyte 7-bit,
lowbyte 8-bit) which makes it incompatible with the good old SMTP
(Simple Mail Transfer Protocol).  While baby Guobiao2123 use a 14 bit
coding (Highbyte 7-bit, Lowbyte 7-bit), it happily adapts to the world
of email.  This applies both to HZ coding and GB coding.  For example,
even if I forget to save a mail in HZ coding, and I save it in GB coding
instead: when the mail get transferred, only the High Bit get strip, and
alas, it doesn't matter, now it becomes HZ code.  So I can happily
decode it.

The other trouble is 'Wan4 Ma3 Beng1 Teng2' (Ten Thousand of Coding
schemes [pronounce same as Horse] ...) due to no National Regulation
(Enforcement of law) on Coding Scheme. But I believe that this problem
could well be negligible now as Big5 seems to be accepted publicly.




Sincerely
Liangsheng WU

From @UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU Mon Nov 22 21:52:48 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 AA17435; Mon, 22 Nov 93 21:52:34 CST
Message-Id: <9311230352.AA17435@ifcss.org>
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 2863; Mon, 22 Nov 93 22:50:39 EST
Received: from UGA.CC.UGA.EDU (NJE origin LISTSERV@UGA) by UGA.CC.UGA.EDU (LMail V1.1d/1.7f) with BSMTP id 0157; Mon, 22 Nov 1993 22:50:38 -0500
Date:         Tue, 23 Nov 1993 11:47:37 EST
Reply-To: David Steelman <SCUT024%TWNMOE10.BITNET@uga.cc.uga.edu>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: David Steelman <SCUT024%TWNMOE10.BITNET@uga.cc.uga.edu>
Subject:      Big5 codes
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
Status: RO

Here is a Qbasic routine for printing out all of the codes. When you
read the resultant file under a Chinese system, it will show all of the
characters used. Presumably you could use the same text for any
codes.
-----------------------------------------------------
 OPEN "e:\big5.txt" FOR OUTPUT AS #1
start = TIMER
LET a = 164                        'start at 161 for symbols and punctuation
LET b = 65

CLS
PRINT "PROCESSING"
FOR cnt% = 1 TO 92   'change to 95 if a starts at 161
b = 65
        FOR count% = 1 TO 59 'change to 61 and rem out next 3 lines for special
                IF a < 198 OR a > 200 THEN GOTO 10  'skip
                IF a = 198 AND b = 160 THEN a = 201
                IF a = 199 OR a = 200 THEN a = 201
10              b = b + 1
                PRINT #1, CHR$(a);
                PRINT #1, CHR$(b);
                'PRINT CHR$(a);
                'PRINT CHR$(b)
        NEXT count%
        b = b + 34

        FOR count% = 1 TO 94
                b = b + 1
                PRINT #1, CHR$(a);
                PRINT #1, CHR$(b);
                'PRINT CHR$(a);
                'PRINT CHR$(b)
        NEXT count%

        a = a + 1
NEXT cnt%
finish = TIMER
PRINT "Processing time: "; (finish - start); " sec."
CLOSE
END

From @UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU Tue Nov 23 17:10: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 AA02092; Tue, 23 Nov 93 17:09:52 CST
Message-Id: <9311232309.AA02092@ifcss.org>
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 7149; Tue, 23 Nov 93 18:07:52 EST
Received: from UGA.CC.UGA.EDU (NJE origin LISTSERV@UGA) by UGA.CC.UGA.EDU (LMail V1.1d/1.7f) with BSMTP id 5070; Tue, 23 Nov 1993 18:07:50 -0500
Date:         Tue, 23 Nov 1993 22:45:01 GMT
Reply-To: "L.S.Ng" <L.S.Ng1@SOUTHAMPTON.AC.UK>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: "L.S.Ng" <L.S.Ng1@SOUTHAMPTON.AC.UK>
Subject:      Re: Big-5 Encoding
Comments: To: lius@RA.MSSTATE.EDU
Comments: cc: Chinese Computing Network <ccnet-l@uga.cc.uga.edu>
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
In-Reply-To:  <no.id>; from "Bill H. Liu" at Nov 22, 93 7:39 pm
Status: RO

There is a little addenum to my previous posting on the Big 5 encoding.

13973 are the number of Chinese Character plus Symbols defined in Big5
scheme. i.e. From subgroup A1 to F9.

Where as for the Chinese character the subgroups are A4-C6 and C9-F9.
By simple math, the total Chinese Characters are 13488.

But this is not the case, as some subgroups are not fully filled.  To
determine the exact number of Chinese characters, I looked at the 24x24
fontfile STDFONT of Eten 3.0.  The size is 942768.  Each 24x24 character
is 72 byte, so there are only 13094.

> >
> > Bruce also asked:
> >
> > > BTW, how do you retrieve the bitmap from the font file?
> >
> Hey, the original post asked how to do it in CWin. Read it carefully. You
> did not answer my question. Why do you want to deal with the bitmap in CWin?

I don't understand your question. Could you please rephrase it?


> > Whereas to access a TTF, you need to know about the structure of it.
> > (Thanks for your tips, they are in ftp.microsoft.com:/drg)
> > After that, you call a rasterizer to convert it into bitmap and then
> > send it to a device.
> >
> Again. Why do you want to do that? Isn't there an easier way of doing it?

Here is the compromise: If you rely on CWIN, you are limited by CWIN. If
you do it hard, you gain the power. It is up to you.



> > > > (HEX)
> > > > 8E40 - A0FE    USER 1
> > > > A140 - A3FE    SPECIAL 1
> > > > A440 - C67E    COMMON
> > > > C4A1 - C8FE    SPECIAL 2   (JAPANESE & RUSSIAN ETC)
> > > > C940 - F9FE    RARE
> > > > FA40 - FEFE    USER 2
> > > >
> > > > HI BYTE = SUBGROUP NUMBER, RANGE FROM 0x8E TO 0xFA
>                                             ~~~~~~~~~~~~
> > > > LO BYTE = CHAR NO. IN EACH SUBGROUP, RANGE  (40-7E) AND (A1-FE)
> But I didn't get a good answer. According to your post, FA - 8E = 6C and
> 0x6C + 1 = 0x6D which is 109 decimal. Could you explain this elementary
> math to me? (I have to admit that I did learn hexdecimal arithmatic while I
> was in elementary school.)

You missed something, the last subgroup is FE not FA. So 113 = number of
first to last subgroup = last subgroup - first subgroup + 1.


> > ps. By the way, would you like to clip some pages from your MS FE SDK on
> > the Chinese TTF to the net?
>
> How? Type it in?

Yes, please. I guess in could not be more than a good few pages.


Thanks in advance.

Sincerely
Liangsheng WU

From @UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU Wed Nov 24 16:54:30 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 AA25904; Wed, 24 Nov 93 16:54:22 CST
Message-Id: <9311242254.AA25904@ifcss.org>
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 1750; Wed, 24 Nov 93 17:51:09 EST
Received: from UGA.CC.UGA.EDU (NJE origin LISTSERV@UGA) by UGA.CC.UGA.EDU (LMail V1.1d/1.7f) with BSMTP id 7093; Wed, 24 Nov 1993 17:49:08 -0500
Date:         Wed, 24 Nov 1993 16:45:19 -0500
Reply-To: John McRae <jrm@CRUX2.CIT.CORNELL.EDU>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: John McRae <jrm@CRUX2.CIT.CORNELL.EDU>
Subject:      Re: ANSI Z39.64
Comments: To: ccnet-l <ccnet-l@uga.cc.uga.edu>,
          susan lasovick <lasovick@world.std.com>
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
In-Reply-To:  Your message of "Wed, 24 Nov 93 13:37:53 EST."
Status: RO

>Can anyone tell me which Asian language codesets ANSI Z39.64 defines?
>
>Thanks,
>Susan Lasovick
>lasovick@world.std.com
============================

ANSI Z39.64 is commonly known as EACC, formerly REACC, for [RLG or RLIN]
East Asia Character Code.  It was created by Research Libraries Group
(RLG) for use in CJK bibliographic information systems, and it is used by
RLIN, OCLC, and the Library of Congress (LC).  LC is now the
administrator in some sense, although I would be very interested to know
from others how active LC's role is.  EACC was based largely on CCCII; I
would also be pleased to have others explain the technical differences.

-- John McRae, Asian Studies
Cornell University
jrm5@cornell.edu

From @UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU Tue Dec 14 05:38:59 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 AA22384; Tue, 14 Dec 93 05:38:51 CST
Message-Id: <9312141138.AA22384@ifcss.org>
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 9603; Tue, 14 Dec 93 06:37:01 EST
Received: from UGA.CC.UGA.EDU (NJE origin LISTSERV@UGA) by UGA.CC.UGA.EDU (LMail V1.1d/1.7f) with BSMTP id 4339; Tue, 14 Dec 1993 06:37:00 -0500
Date:         Tue, 14 Dec 1993 11:36:00 GMT
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 Info
Comments: To: ccnet-l@uga.cc.uga.edu
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
Status: RO

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 Thu Dec 23 15:41: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 AA22619; Thu, 23 Dec 93 15:41:14 CST
Message-Id: <9312232141.AA22619@ifcss.org>
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 4578; Thu, 23 Dec 93 16:39:34 EST
Received: from UGA.CC.UGA.EDU (NJE origin LISTSERV@UGA) by UGA.CC.UGA.EDU (LMail V1.1d/1.7f) with BSMTP id 3215; Thu, 23 Dec 1993 16:39:33 -0500
Date:         Thu, 23 Dec 1993 13:39:06 PST
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:      Info on EACC/ANSI Z39.64
Comments: To: ccnet-l@uga.bitnet
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
Status: RO

REPLY TO 11/24/93 13:35 FROM LASOVICK@WORLD.STD.COM "susan lasovick"

To Susan Lasovick --

Belated answer to your query posted on CCNET-L on 11/24/93 (I'm a CCCNET-L
lurker, but have been so backlogged in e-mail, I just got to it.)

> Can anyone tell me which Asian language codesets ANSI Z39.64 defines?

ANSI Z39.64 (East Asian Character Code Set for Bibliographic Information
Interchange, aka "EACC") includes a unified "Han" set of Chinese characters
drawn from CCCII (all of vol.  1 (most of plane 21), more common characters in
vol.  2 (rest of plane 21 to plane 23) and the variant volumes (variants
linked to the layer one characters on planes 21-23), PLUS all the Chinese
characters in CB2312-80 JIS X0208, and KIPS (the precursor of KSC 5608) that
were not in CCCII.  Thus simplified and traditional Chinese characters, joyo
kanji forms and kokuji, plus some Korean variants are all included; kana from
JIS X0208 and hangul from KIPS.

EACC itself is an integration of all these sets; it follows the CCCII code
structure, and most of the character codes are the same as those in CCCII.
However, CCCII often encodes the same character more than once (depending on
semantic use); in these cases EACC usually encodes it only once, giving
preference to encoding a common variant as a variant rather than as an obscure
character.  (Favorite example is the three-stroke simplified character for
10,000; CCCII also encodes it as a layer-one character because it is also part
of a late-Han surname.  We use the layer-2 encoding.)  The published versions
of CCCII does not include Joyo kanji forms that are not also Chinese variant
forms, kokuji, kana, or hangul (although with the layer structure you could
simply specify a plane as an entire code-set.  However, that would mean even
more redundant encoding of Han characters.  EACC tried hard to follow the
principle, "one character, one code" for all Chinese characters, which was
revolutionary in its time.  Most of the EACC development focused on encoding
the Chinese characters in the non-CCCII sets so that they were linked to the
correct traditional (fanti) characters and making the correct mapping tables
between code sets.

RLG created an online "RLIN CJK Thesaurus" that shows the cross-mappings
between EACC and CCCII, GB, JIS, KIPS (and also one of the Chinese Telegraph
Codes).  Since the entire EACC repertoire has been included in Unicode/IS
10646 (plus all the Han characters added to published standards since EACC was
first developed in 1983), we will be relying on Unicode-EACC cross mapping
tables in the future, especially to export CJK bibliographic records with EACC
encoded characters to Unicode/10646 supported products.

Enjoy your postings by the way.  Now I'll go back to lurking. Happy holidays.

Karen Smith-Yoshimura
(N.B.  I'm RLG rep to the Unicode Consortium, X3L2, and frequently part of the
US delegation to ISO-IEC JTC1/SC2/WG2 [the folks who brought you IS 10646].
I co-authored the text for ANSI Z39.64 and wrote one of the position papers to
WG2 on Han unification.  After a decade worth of effort, it's gratifying to
see it pay off!)
------------------------------------------------------------------------------
Karen Smith-Yoshimura                     BL.KSS@RLG.BITNET [bitnet]
The Research Libraries Group              BL.KSS@RLG.STANFORD.EDU [internet]
1200 Villa Street                         Phone: 415-691-2270
Mountain View, CA  94041-1100             Fax: 415-964-0943

To:  LASOVICK@WORLD.STD.COM
cc:  CCNET-L@UGA.BITNET

From easug-error@guvax.acc.georgetown.edu Thu Jan 27 15:13:42 1994
Return-Path: <easug-error@guvax.acc.georgetown.edu>
Received: from axp1.acc.georgetown.edu by ifcss.org (4.1/IFCSS-Mailer)
	id AA06524; Thu, 27 Jan 94 15:13:39 CST
Resent-Date: Thu, 27 Jan 1994 15:56:33 -0500
Resent-From: easug-error@guvax.acc.georgetown.edu
Errors-To: easug-error@guvax.acc.georgetown.edu
Received: from guvax.acc.georgetown.edu by guvax.acc.georgetown.edu (PMDF
 V4.2-10 #5850) id <01H86LEI6NJ4A4L6YS@guvax.acc.georgetown.edu>; Thu,
 27 Jan 1994 15:57:45 EST
Received: from LSP5.CS.NYU.EDU by guvax.acc.georgetown.edu (PMDF V4.2-11 #3726)
 id <01H86LDKYD1S9ZQ1RK@guvax.acc.georgetown.edu>; Thu, 27 Jan 1994 15:56:58 EST
Received: by LSP5.CS.NYU.EDU (5.61/1.34) id AA18491; Thu,
 27 Jan 94 15:56:33 -0500
Date: Thu, 27 Jan 1994 15:56:33 -0500
From: nhan@LSP5.CS.NYU.EDU (Ngo Thanh Nhan)
Subject: TCVN 5773:1993 (NSCII) -- Vietnamese No>m national standard
To: easug@guvax.acc.georgetown.edu
Errors-To: easug-error@guvax.acc.georgetown.edu
Resent-Message-Id: <01H86LEI90AQA4L6YS@guvax.acc.georgetown.edu>
Message-Id: <9401272056.AA18491@LSP5.CS.NYU.EDU>
X-Vms-To: IN%"easug@guvax.acc.georgetown.edu"
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT
Status: RO

NYU Linguistic String Project -- Thu Jan 27 15:56:17 EST 1994

For your information.

-- Ngo Thanh Nhan
------------------------- begin included message ----------------------

###### #### ##  ## ##  ##  TECHNICAL COMMITTEE ON INFORMATION TECHNOLOGY
  ##  ##    ## ##  ### ##                   (TCVN/TC1)
  ##  ##    ###    ## ###    Viet Nam General Dept for Standardization,
  ##   #### ##     ##  ##          Metrology and Quality Control
=========================  ---------------------------------------------
T  E  C  H  N  I  C  A  L      70, Tran Hung Dao -- Ha Noi, Viet Nam
C  O  M  M  I  T  T  E  E      Tel: +84 4 266220 - Fax: +84 4 267418

                           PRESS RELEASE

Subject: TCVN 5773:1993 (NSCII) -- Vietnamese No>m national standard

Vietnam has adopted the first 16-bit character encoding standard for
computing, called "No>m Standard Code for Information Interchange"
(NSCII).  This move took place seven months after the adoption of the
8-bit VSCII character encoding ("Vietnamese Standard Code for
Information Interchange" -- Vietnam's first national standard for
computing), and only four months after the announcement of Vietnam's
ambitious information technology strategy for the 1990's.

No>m has been the writing system, based on ideographic (Chinese)
characters, in use since the tenth century for the spoken
Vietnamese language.  VSCII, formally set out in the document
TCVN 5712:1993, is the character encoding standard for quo>'c
ngu*~ -- the dominant, alternative Latin-based writing system
since the 1920's.

Mr Le Quy An, Vice Minister of Science, Technology and Environment,
signed the document adopting the national standard "TCVN 5773:1993
(NSCII)" in Hanoi on December 31, 1993.

By adopting and extending the current repertoire of ideographic
characters found in the emerging ISO 10646/Unicode international
standard for multilingual computing, TCVN 5773:1993 (NSCII) defines the
first standard code table which contains the most essential No>m proper
characters -- those ideographic characters that can only be found in
use in Vietnam. Vietnam intends to include No>m characters in
future revisions of the ISO 10646/Unicode standard, and is
currently working with China, Japan, Korea, Taiwan, Hong Kong
and the United States in this endeavor under ISO auspices.

Originally proposed for discussion in May 1992, NSCII was formally
approved through a national ballot and technical review conference held
in Hanoi in November 1993.  A version of the NSCII code table in the
form of a Macintosh HyperCard Stack is currently available by
"Anonymous FTP" from the archives of the Unicode Consortium (in
unicode.org:/pub/Mapping_Tables/EastAsia_maps).

TCVN is the Vietnamese acronym for Vietnam's national standards
organization -- Viet Nam General Department for Standardization,
Metrology and Quality Control -- a member of the International
Organisation for Standardization (ISO). TCVN/TC1 is its Technical
Committee on Information Technology, which is directly responsible for
the compilation of NSCII. TCVN/TC1 has expressed its gratitude for
comments and suggestions which it received from inside and outside of
Vietnam.  The NSCII code table was refined following these
suggestions and comments.

The TCVN/TC1 committee may be contacted at 70, Tran Hung Dao, Ha Noi,
Viet Nam. Tel: +84 4 266220, Fax: +84 4 267418.

/
------------------------- e n d included message ----------------------


From @UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU Tue Feb  1 19:35:46 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 AA09502; Tue, 1 Feb 94 19:35:41 CST
Message-Id: <9402020135.AA09502@ifcss.org>
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 0524; Tue, 01 Feb 94 20:32:36 EST
Received: from UGA.CC.UGA.EDU (NJE origin LISTSERV@UGA) by UGA.CC.UGA.EDU (LMail V1.1d/1.7f) with BSMTP id 6936; Tue, 1 Feb 1994 20:32:30 -0500
Date:         Tue, 1 Feb 1994 20:34:45 EST
Reply-To: mpei <mpei@AOL.COM>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: Ming Pei <mpei@AOL.COM>
Subject:      BIG5 standard
Comments: To: ccnet-l@uga.cc.uga.edu
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
Status: RO

Doug.Schiffer  wrote
>
> Looking over the NJSTAR v2.1 GB font
> I see it has the following sections.
> Does anybody know what the full GB standard set has in the "missing"
> sections 10 through 14?
>
> Section       Hex      Description
> -------    ---------   -------------------------
> 01      A1A1-A1FE   Punctuation
> 02      A2A1-A2FE   Numerals (circled
> etc)
> 03      A3A1-A3FE   ASCII (wide characters)
>
> 04      A4A1-A4FE   Hieragana
> 05      A5A1-A5FE   Katakana
> 06      A6A1-A6FE   Greek
>
> 07      A7A1-A7FE   Russian
> 08      A8A1-A8FE   Roman vowels w tone marks/ Zuyin Fuhao
> 09      A9A1-A9FE   Line graphics
>
> 10      AAA1-AAFE   ?????????????????????? [missing]
> 11      ABA1-ABFE   ??????????????????????
> 12      ACA1-ACFE   ??????????????????????
> 13      ADA1-ADFE   ??????????????????????
> 14      AEA1-AEFE   ??????????????????????
>
> 15      AFA1-AFFE   NJSTAR uses this area for hanzi that have
> more than one traditional form corresponding
> to the simplified forms in GB 2312. I happen
> to know that GB12345 uses sections 88-94
> for this purpose.
>
> 16-87   B0A1-F7FE   Hanzi
>
I don't know about NJSTAR. I looked at the CWIN3.1 codes and found
the following:

 Section       Hex      Description
 -------    ---------   -------------------------
 01      A141-A1FE   Punctuation
 02      A241-A2FE   graphics, ASCII (wide)
 03      A341-A3FE   Greek and  Zuyin Fuhao

 04-89   A440-F9FE   Hanzi
 except Sections 39,40 (C4,C5) which are not used

 90      FA40-FAFE   user-defined words

 Thus, CWIN3.1 seems to have more Chinese chareacters than NJSTAR. I don't
 know why Sections 39 and 40 are skipped.

 Ming Pei

From @UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU Fri Feb  4 06:35:12 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 AA03160; Fri, 4 Feb 94 06:35:04 CST
Message-Id: <9402041235.AA03160@ifcss.org>
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 5792; Fri, 04 Feb 94 07:33:04 EST
Received: from UGA.CC.UGA.EDU (NJE origin LISTSERV@UGA) by UGA.CC.UGA.EDU (LMail V1.1d/1.7f) with BSMTP id 4890; Fri, 4 Feb 1994 07:33:03 -0500
Date:         Thu, 3 Feb 1994 17:09:00 -0500
Reply-To: Doug Schiffer <Doug.Schiffer@F513.N260.Z1.FIDONET.ORG>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: Doug Schiffer <Doug.Schiffer@F513.N260.Z1.FIDONET.ORG>
Subject:      GB12345
Comments: To: CCNET-L@uga.cc.uga.edu
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
Status: RO

On Monday, 1-31-94, "L.S.Ng" wrote:

 >From: "L.S.Ng" <ur-valhalla!soton.ac.uk!L.S.Ng1>
 >Hi,
 >
 >Where did you see the GB12345 specification? Is it with Chinese Star?
 >Where can I get a font file for that?

Alas, I don't have the actual standards document. (Does anyone out
there?) I've picked up some information about it from various
places. I got quite a bit of cross-reference information from the
Unicode cross reference tables.  It tells me that GB12345 character
[67,94] = Big5 AEF9, for example.

>From examining the table, I noticed that GB12345 has entries on rows
88 to 93.  GB2312 stops at row 87.  From examining a few of these
"extra" characters, I noticed that they are all cases where more
than one traditional form  maps to a GB2312 simplified form.

As for a font file, I wish I had one.  In principle, the Unicode
xref table could be used to construct one.  There's a problem, however.
The table has only one entry under the GB column, and sometimes I think
that some other GB standard (such as GB 7589-87) has the same character,
and it takes priority.  I reasoned this out because there are a lot
of gaps in the listing for the 12345 set.  If I sort it in order of
GB number, I find the following list (row 88 and above):

        GB12345 list
                      Page   1

GB     Unicode Big5 JIS    KSC
====== ======= ==== ====== ======
1-8801   896C  C4FC
1-8802   95C6  C1F3 1-7020
1-8803   9336  BFF6 1-6870
1-8804   5F46  B9FB        1-6580
1-8805   8514  BDB3 0-7289 0-6059
1-8806   7E94  C5D7 0-6988 1-7554
1-8810   9F63  C4D5 0-8381
1-8811   5679  BEB4
1-8814   9F15  C35D 0-8374
1-8816   5641  E4FA 1-2231 1-7207
 .... (205 more entries) ....

I'm missing 1-8807, 8808, 8809, 8812, 8813...

BTW:  In the Unicode list, 0-XXXX stands for GB2312, 1-XXXX is GB12345.
A similar arrangement applies to the JIS & KSC standards.

Below row 88, if the simplified character is the same as the traditional,
the Unicode xref table only lists the GB2312 form.  But above row 88, the
GB12345 set should be fully represented, yet isn't <sigh>.



 >FYI, the standard GB left region 8 to 15 undefined. Those in NJSTAR is
 >defined by the author himself.

I was wondering if that's what was going on.  Thanks.

From @UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU Tue Apr 26 13:41:58 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 AA03602; Tue, 26 Apr 94 13:41:51 CDT
Message-Id: <9404261841.AA03602@ifcss.org>
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 0511; Tue, 26 Apr 94 14:38:05 EDT
Received: from UGA.CC.UGA.EDU (NJE origin LISTSERV@UGA) by UGA.CC.UGA.EDU (LMail V1.1d/1.7f) with BSMTP id 3797; Tue, 26 Apr 1994 09:29:34 -0400
Date:         Tue, 26 Apr 1994 09:26:54 -0400
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, ISO-2022, and 7-bit merged GB/Big5
Comments: To: ccnet-l@uga.cc.uga.edu
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
In-Reply-To:  <199404261153.HAA23589@leibniz.math.psu.edu>
Status: RO

I wrote:
 > > 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.

Ross Paterson wrote:
 > And the next question is, which of these should we prefer?

Both Unicode and ISO-2022 provide good answers to the problem of
mixed-language capability in internationalized software.  In the past
Ross has been a strong advocate of Unicode, but now he seems to be
reconsidering and thinking that ISO-2022 may not be such a bad idea.

ISO-2022 is a "conservative" approach.  Unicode is a "radical"
approach.  Someone once said that a conservative is a radical who has
been mugged.

Here are some relevant considerations.

1. The ISO-2022 idea is to incorporate existing character sets
(Big5 Chinese, GB Chinese, JIS Japanese, ISO-8859-* European, ...) by
using escape sequences to switch between the character sets.  The
advantage is that the existing character sets are preserved.  The
disadvantage is that there are at least three different ways to
represent the Chinese character Da4 ("large"), namely the GB way, the
Big5 way, and the JIS way.

2.  The Unicode idea is to merge existing character sets into one
character set.  The advantage is that there will be only one
representation of Da4, which makes it easier to do searches etc.  The
disadvantage is that the mappings of existing character sets (Big5,
GB, JIS etc) into the unified character set are not linear, rather
they are given by tables.

3.  Theoretically, Unicode is a 16-bit standard, i.e. every character
is represented by 2 bytes.  In practice, software may end up
representing characters internally by anywhere from 1 to 3 bytes.
ISO-2022 does not try to claim that all characters will be represented
by the same number of bytes.

4.  In theory, Unicode is supposed to consist of one unified character
set.  In practice, Unicode implementations may patch together fonts
from various individual character sets.  ISO-2022 is more open about
this patching process.

5.  Both ISO-2022 and Unicode are just now coming into widespread use.
Plan 9 and Microsoft Windows NT use Unicode.  Multilingual Emacs
(Mule) and Multilingual Mosaic (Mosaic-L10N) use variants of ISO-2022.

My own view is that Unicode is a much better idea, but ISO-2022 may be
expedient in the short run.

As for 7-bit merged GB/Big5, my HZ+S proposal and Ya-Gui's unreleased
HZ-2 proposal are ISO-2022 style solutions.  Shann seems to be
proposing a Unicode-style solution.  Nothing is set in stone, so let's
keep our minds open.

-- Steve

From @UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU Tue Apr 26 13:41:58 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 AA03602; Tue, 26 Apr 94 13:41:51 CDT
Message-Id: <9404261841.AA03602@ifcss.org>
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 0511; Tue, 26 Apr 94 14:38:05 EDT
Received: from UGA.CC.UGA.EDU (NJE origin LISTSERV@UGA) by UGA.CC.UGA.EDU (LMail V1.1d/1.7f) with BSMTP id 3797; Tue, 26 Apr 1994 09:29:34 -0400
Date:         Tue, 26 Apr 1994 09:26:54 -0400
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, ISO-2022, and 7-bit merged GB/Big5
Comments: To: ccnet-l@uga.cc.uga.edu
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
In-Reply-To:  <199404261153.HAA23589@leibniz.math.psu.edu>
Status: RO

I wrote:
 > > 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.

Ross Paterson wrote:
 > And the next question is, which of these should we prefer?

Both Unicode and ISO-2022 provide good answers to the problem of
mixed-language capability in internationalized software.  In the past
Ross has been a strong advocate of Unicode, but now he seems to be
reconsidering and thinking that ISO-2022 may not be such a bad idea.

ISO-2022 is a "conservative" approach.  Unicode is a "radical"
approach.  Someone once said that a conservative is a radical who has
been mugged.

Here are some relevant considerations.

1. The ISO-2022 idea is to incorporate existing character sets
(Big5 Chinese, GB Chinese, JIS Japanese, ISO-8859-* European, ...) by
using escape sequences to switch between the character sets.  The
advantage is that the existing character sets are preserved.  The
disadvantage is that there are at least three different ways to
represent the Chinese character Da4 ("large"), namely the GB way, the
Big5 way, and the JIS way.

2.  The Unicode idea is to merge existing character sets into one
character set.  The advantage is that there will be only one
representation of Da4, which makes it easier to do searches etc.  The
disadvantage is that the mappings of existing character sets (Big5,
GB, JIS etc) into the unified character set are not linear, rather
they are given by tables.

3.  Theoretically, Unicode is a 16-bit standard, i.e. every character
is represented by 2 bytes.  In practice, software may end up
representing characters internally by anywhere from 1 to 3 bytes.
ISO-2022 does not try to claim that all characters will be represented
by the same number of bytes.

4.  In theory, Unicode is supposed to consist of one unified character
set.  In practice, Unicode implementations may patch together fonts
from various individual character sets.  ISO-2022 is more open about
this patching process.

5.  Both ISO-2022 and Unicode are just now coming into widespread use.
Plan 9 and Microsoft Windows NT use Unicode.  Multilingual Emacs
(Mule) and Multilingual Mosaic (Mosaic-L10N) use variants of ISO-2022.

My own view is that Unicode is a much better idea, but ISO-2022 may be
expedient in the short run.

As for 7-bit merged GB/Big5, my HZ+S proposal and Ya-Gui's unreleased
HZ-2 proposal are ISO-2022 style solutions.  Shann seems to be
proposing a Unicode-style solution.  Nothing is set in stone, so let's
keep our minds open.

-- Steve

From @UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU Thu Apr 28 19:00:23 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 AA16174; Thu, 28 Apr 94 19:00:20 CDT
Message-Id: <9404290000.AA16174@ifcss.org>
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 0527; Thu, 28 Apr 94 19:57: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 8609; Thu, 28 Apr 1994 17:58:21 -0400
Date:         Fri, 29 Apr 1994 19:54:27 +0800
Reply-To: Jing-Shin Chang <shin@HERMES.EE.NTHU.EDU.TW>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: Jing-Shin Chang <shin@HERMES.EE.NTHU.EDU.TW>
Subject:      CNS converter. Re: 7-bit clean big5
Comments: To: ccnet-l@uga.uga.edu
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
Status: RO

Dear CCNET netters,

You don't need to invent another wheel when it is available!!

         Z@D>]BDbFnGB]_D!T6oGDMD'

(especially when there are so many wheels -^^-)
(What are those  c*D$D,t`N{  words in the above line.)

There are many suggestions in the latest ccnet-l discussions
concering the "7-bit clean Big5" (or CNS) and proposals for
an extended HZ standard for the new chinese.* news hierachy.

 From technical points of view, I think this might be a
retrospect from the 8-bit (and 2-4 bytes) encoding trends
back to the ancient times since 8-bit clean environment is
increasingly polular. People just don't know their Sparcs,
RS/6000, and HPUXs are mostly 8-bit clean. (Hardware as well
as applications.)

OK. I will not talk about those 8-bit stuffs. Let's started
with the 7-bit envionments.

I am strongly in favor of using the CNS code as the exchange
code for the chinese.* newsgroups and use plug-in conversion
programs, as mentioned by one of Ning's posting, between
the CNS and the reader's favorite coding system, so as to
hide the readers from the exchange code. In addition, the
ISO 2022 standard should be followed.  The configuration
would then look like this:

        (HZ Users) HZ <-> | Big5 <-> CNS posting | <-> Big5 (Big5 Users)
                          +--- news readers -----+

(HZ <-> Big5 and CNS <-> Big5 are available.)

The major reasons are:

        1) the news readers can use whatever Chinese terminals
                they used, either 7-bit HZ or 8-bit Big5 terminals

        2) a larger code space which prevent one from using
                variant characters frequently

        3) there is no n-to-1 mapping problem for Big5 postings
                although HZ postings still have such a problem
                for Big5 readers.

                (In the present act.big5 newsgroup, even a Big5
                posting may become messed due to the conversion
                to HZ and the reconversion back to Big5.)

        4) conversion programs are readily available and the
                ISO 2022 standard is followed.

The decision, of course, depends on many other factors.

The 3rd line of this email is an encoded CNS message, which
is the chinese translation of the 2nd line. This encoding
scheme is widely used in the mail and news systems in the
SEEDNET of the ROC. And it is probably what you are seeking
for as a 7-bit clean code.

(The SeedNet is the *.com.tw, *.org.tw and *.net.tw parts of the
Internet. However, only mail access is available due to some
legal problems in the ROC telecommunication laws.)

Thanks Simpson. Thank you for your consideration for the Big5
users. You may want to get a code conversion package from the ftp site:
iiidns.iii.org.tw(140.92.1.45):/pub/seed/chcode, which provide code
conversion functions among major Taiwanese Chinese coding schemes,
including BIG5, IBM5550, NSC (should be the CNS-11643 internal code)
NSC-P (the "7-bit clean" version of NSC, this is probably what
everybody is expecting for), EUC (extended UNIX code, which involve
the ASCII and CNS-11643 in the front part of its code space,
2 or 4 bytes, widely used in Workstations in Taiwan, and probably in
Japan and Korea too), TCA (Taipei Computer Association recommended
code, which avoids code confliction better than the Big5 code does),
IBM Host code and Telgram code (old stuffs!!).

See the "README" and "chcode.doc" in the same directory for a brief
introduction on the encoding schemes. Also, you may like to trace
the GetNSCPcode() and PutNSCPcode() functions in code.c for details.

(Note: The above distributed version has a few bugs, and the interface
is not good as a filter. I had fixed some bugs and personally made a
few changes to make it a filter. I could contribute the revised
version if necessary.)

There are also free CNS fonts made available by the ROC government
on Jan. (They are 24x24 and 40x40 fonts though. See the attached
uuencoded file (Big5). Sorry for those persons who cannot view the
Big5 file!)

You could also get a PC version of SUCCESS, which integrate, PPP
communication program, news reader, TCP/IP supports (ftp, telnet,
email), from III, which supports BIG5, CNS, EUC code conversion.
(Since I am a workstation user, this information is not testified
by myself.)

Because III (which is exactly the organization who invents the Big5
code) is a govenment-supported organization, you can get these stuffs
for free and they will continue on improving the software without extra
charge. I think it is therefore more suitable in comparison with other
sharewares.

Using a standard that conforms to ISO 2022 is probably a better solution
for combining our applications with other multi-lingual applications as
mentioned in a few previous postings. So, instead of using private
standard as the exchange code, I prefer not to invent another wheel.
This is also adopted by those workstation giants like Sun, Dec, IBM.
In fact, the technical trends for these giants are to move toward 8-bit
clean environment (More exactly, toward MLNS, Mutli-Language National
Supports.) When they have to retrospect to the old environment, they
resorted to available standards. One example is the Sun ALE (Asia
language Environment, including HLE for Traditional Chinese, CLE for
Simplified Chinese, JLE for Japanese and KLE for Korean). It was made
8-bit clean as early as 1990 (probably earlier?) for the terminal
or workstation side. However, they use an ISO-2022 conformant approach
for sending Chinese email among HLE workstations (See the attached
appendix from Sun's Training courses.) Therefore, I suggest to use
the CNS coding scheme and make it ISO conformat when designing the
exchange code for the news groups.

        Jing-Shin -^^-

=== Appendix I. Sun's Approaches for Sending Chinese/Japanese/Korean email ===
/usr/ucb/mail was modified for:

Sending
        EUC convert to ISO 2022 with self-announcement,
        resulting stream is 7-bit, send to mail spool
Receving
        8-bit EUC (e.g., mail folder) unaffected
        7-bit ISO from mail spool converted to EUC
        self-announcement indicates need for EUC
Saving message
        mail going into mail folder is EUC
        7-bit -> 8-bit conversion done if necessary
Printing
        Mailtool allows filter definition for printing EUC text
        In .mailrc
                set print2="pr|htops|lpr"

        mailtool - EUC -> ucbmail - ISO -> sendmail - IP net or UUCP ->
        sendmail -> binmail -> mail spool - ISO -> ucbmail - EUC -> mailtool

Locale (language) of mail embedded in message text
Example, for codeset 1:
ESC $ ) F
        F: '0' (HLE/Taiwan), 'A' (CLE/China), 'B' (JLE/Japan), 'C' (KLE/Korean)

        Note: Taiwan(ROC) does not have entry in ISO Standard Registry.
        HLE mail is currently using entry in ISO private registry space.
        Possibly may conflict with other private entry mail originating
        outside Taiwan.

==== Appendix II ==== Big5 News: Free CNS fonts available ====
begin 640 cns11643.font
MI*2\T*>]I+VG1[S0M\>DI*3EI>:TJ[U8"J5$K7"S0K2CJ-&PZJ2ZIE6LR:=+
MMD^K_JBI"@H)"0D)I'6PTZ[)L_@@,3DY-"\P,2\R,B"P3ZK,P].E\J7!NT^E
M7[/XOLD*"J71N&? V;.AI*2EH;S0M\>GO:2]IT>JNB!#3E,@,3$V-#,@(+#J
MKF&\T+?'I*2DY:7FM*N]6*%!P6"\QJ5\N%6D2Z1DIFBMTZ2DI.4*N7&XHZ9R
MJZRA0:1WI=&XTZ>]J4VDNJQ&LZ&DX:Q&I7&[<Z= I[FFJ*%!J,.P9:7FIN:L
M1K!\I42M<+-"H4.G6:3IL%^E_JY-JKJDI JDY:9RI\ZQ3K2CJ-&PZJ2ZIE6L
MR:=+MD^K_JBIH4,*"J5$K7"S0KEQI&RS0K)ZN.JNQJ2DI-^J[:7<H4&NVK[:
MI*2\T*>]I$ND4:1 IGZDO:='JKH@0TY3(#$Q-C0S(""PZJYAO-"WQZ%!I=@*
MJV6GVK#JJKJA>:2DI.6\T+?'I>:TJ[U8H7JD=\)8I5*LL*1#K=.F<JVQH4*E
M?+A5I$ND9+ESI$>D4:1#K=.F<J%#J.2DI*71I*2\T JGO;MSIT"JNK+$I7RH
M[++$I$.F<JVQH4&D=Z>YIJ@@,C1X,C0@(+M0(#0P>#0P(""D1[K8N7&XHZ9R
MJZRA0:;3I.&L1J5QI%V[<Z= "J1&LL2D0*CLLL2D5*9RK;$@-#!X-# @(*JZ
MN7&XHZ9RJZRA0[-OJ,>F<JNLLGND=Z7FI=&E1*UPLT*Y<:1LLT*R>KCJKL:D
MI*3?H4$*LL[$=[' O'.A0PH*N-.DI*3?J_RE6*%!N]VM;KS0M\>Y<;BCIG*K
MK*JZI$BD:*%!I6FFV[/&NL^D^:G.NL^Q8:%!JV6IN;M/I5^EJ[QSIGNU\Z1'
MN+FE1 JM<+-"N7&D;+-"LGJXZJ[&I*2DWZ=+MD^K_JBIH4.FTZEWN_FW<[M/
MN?2D2Z;*I+BJNJ%YI*2DY;S0M\>EYK2KO5BA>J>YON.F<KU8"J6[H4&K:+:W
:JKVQM:96I*2\T*>]LL2D5++5P<JV4J%#"@JA

end

From @UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU Thu Apr 28 19:21:06 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 AA16706; Thu, 28 Apr 94 19:21:03 CDT
Message-Id: <9404290021.AA16706@ifcss.org>
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 0666; Thu, 28 Apr 94 20:19: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 7377; Thu, 28 Apr 1994 18:45:32 -0400
Date:         Thu, 28 Apr 1994 23:17:01 +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:      Re: Big5 != CNS
Comments: To: CCNET-L@uga.cc.uga.edu
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
Status: RO

Roland Wang writes:

>CNS is a character set. It's implementation independent. Big5 has two
>meanings,
>character set (implementation independent) and encoding scheme
>(implementation
>dependent). When we talk about character sets, CNS is a super set of Big5
>(CNS has much more characters than Big5).

>From everything I've seen in the way of tables and things I've read, CNS
11643-1986 contains 13,051 characters and Big5 13,053 characters, including
all the non-Hanzi characters, so perhaps != should be replaced by !quite=

      John

One character that fascinates me is this one:-

0xC94A  0xFA0C  # CJK COMPATIBILITY IDEOGRAPH-FA0C

Does anyone know what this signifies?


I append the introduction to the Unicode Big5 table (from FTP://unicode.org:-

______________________

Name:             BIG5 to Unicode table (complete)
Unicode version:  1.1
Table version:    0.0d3
Table format:     Format A
Date:             11 February 1994
Authors:          Glenn Adams <glenn@metis.com>
John H. Jenkins <John_Jenkins@taligent.com>

General notes:

This table contains the data Metis and Taligent currently have on how
BIG5 characters map into Unicode.

WARNING!  It is currently impossible to provide round-trip compatibility
between BIG5 and Unicode.

A number of characters are not currently mapped because
of conflicts with other mappings.  They are as follows:

BIG5        Description                    Comments

0xA15A      SPACING UNDERSCORE             duplicates A1C4
0xA1C3      SPACING HEAVY OVERSCORE        not in Unicode
0xA1C5      SPACING HEAVY UNDERSCORE       not in Unicode
0xA1FE      LT DIAG UP RIGHT TO LOW LEFT   duplicates A2AC
0xA240      LT DIAG UP LEFT TO LOW RIGHT   duplicates A2AD
0xA2CC      HANGZHOU NUMERAL TEN           conflicts with A451 mapping
0xA2CE      HANGZHOU NUMERAL THIRTY        conflicts with A4CA mapping

We currently map all of these characters to U+FFFD REPLACEMENT CHARACTER.
It is also possible to map these characters to their duplicates, or to
the user zone.

Notes:

1. In addition to the above, there is some uncertainty about the
mappings in the range C6A1 - C8FE, and F9DD - F9FE.  The ETEN
version of BIG5 organizes the former range differently, and adds
additional characters in the latter range.  The correct mappings
these ranges need to be determined.

2.  There is an uncertainty in the mapping of the Big Five character
0xA3BC.  This character occurs within the Big Five block of tone marks
for bopomofo and is intended to be the tone mark for the first tone in
Mandarin Chinese.  We have selected the mapping U+02C9 MODIFIER LETTER
MACRON (Mandarin Chinese first tone) to reflect this semantic.
However, because bopomofo uses the absense of a tone mark to indicate
the first Mandarin tone, most implementations of Big Five represent
this character with a blank space, and so a mapping such as U+2003 EM SPACE
might be preferred.


Format:  Three tab-separated columns
Column #1 is the BIG5 code (in hex as 0xXXXX)
Column #2 is the Unicode (in hex as 0xXXXX)
Column #3  is the Unicode name (follows a comment sign, '#')
The official names for Unicode characters U+4E00
to U+9FA5, inclusive, is "CJK UNIFIED IDEOGRAPH-XXXX",
where XXXX is the code point.  Including all these
names in this file increases its size substantially
and needlessly.  The token "<CJK>" is used for the
name of these characters.  If necessary, it can be
expanded algorithmically by a parser or editor.

The entries are in BIG5 order

Any comments or problems, contact <John_Jenkins@taligent.com>

From @UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU Fri Apr 29 05:16:22 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 AA04852; Fri, 29 Apr 94 05:16:20 CDT
Message-Id: <9404291016.AA04852@ifcss.org>
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 1744; Fri, 29 Apr 94 06:14:32 EDT
Received: from UGA.CC.UGA.EDU (NJE origin LISTSERV@UGA) by UGA.CC.UGA.EDU (LMail V1.1d/1.7f) with BSMTP id 2428; Fri, 29 Apr 1994 06:14:31 -0400
Date:         Fri, 29 Apr 1994 11:12: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: Big5 != CNS
Comments: To: ccnet-l@uga.cc.uga.edu
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
Status: RO

John Delacour <JD@EREMITA.DEMON.CO.UK> writes:
> From everything I've seen in the way of tables and things I've read, CNS
> 11643-1986 contains 13,051 characters and Big5 13,053 characters, including
> all the non-Hanzi characters, so perhaps != should be replaced by !quite=
>
>       John
>
> One character that fascinates me is this one:-
>
> 0xC94A  0xFA0C  # CJK COMPATIBILITY IDEOGRAPH-FA0C

There is also

0xDDFC  0xFA0D  # CJK COMPATIBILITY IDEOGRAPH-FA0D

These two characters are duplicates of A461 and DCD1 respectively, and
hence were discarded when CNS levels 1 and 2 were created.

From @UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU Sat Apr 30 01:51:06 1994
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:      miscellaneous: Big5 news, gopher, web, HZ+S
Comments: To: Ya-Gui Wei <yawei@cnd-b.cnd.org>
Comments: cc: ccnet-l@uga.cc.uga.edu
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
Status: RO
Content-Length: 2391
X-Lines: 71

Ya-Gui writes:
 > The Taiwan site that provide a.c.t and a.c.t.big5 cross-mirroring
 > is also providing an HZ hook-up to Taiwan's big5 newsgroups. If
 > the user was refering to those services, then he was not reading
 > Big5 directly.

Ah!  That could be the explanation.  I was surprised when this guy
told me that ZWDOS supports Big5.  Sorry for not checking my facts.

 > I myself am not able to read Big5 gopher sites because my local
 > gopher client is not 8-bit clean and I don't want to bother to
 > recompile it myself.

I use the Emacs Gopher and World Wide Web clients, gopher.el and
w3.el.  They work under cxterm in Big5 mode (or on a PC running ETen
or KC) to access Big5 Gopher and Web servers in Taiwan.  The links
are in my WWW home page, last line of my signature below.

Text-based Gopher and Web clients on a Chinese terminal are better
than Mosaic-L10N in some ways.  It's hard to use the on-line
Chinese->English dictionary via Mosaic-L10N, because Mosaic-L10N
doesn't give you a good way to type in the Chinese word that you want
to look up.

 > BTW, could you post your Big5<->HZS conversion algorithm?

The programs are at ftp.math.psu.edu, /pub/simpson/chinese/hzps.  They
are lightly hacked versions of Fung's GB <-> HZ converters.  At this
point in time they are essentially untested.  The Big5 -> HZ+S routine
is

     big2hzp(b1, b2, a1, a2)
         int b1, b2, *a1, *a2;
     {
         unsigned long n;

         n = 157 * ((b1 < 0xC9) ? (b1 - 0xA1) : (b1 - 0xC9))
                + ((b2 < 0xA1) ? (b2 - 0x40) : (b2 - 0xA1 + 63));

         *a1 = 0x21 + (int) (n / 94);

         *a2 = 0x21 + (int) (n % 94);
     }

and the HZ+S -> Big5 routine is

     hzp2big(p, a1, a2, b1, b2)
         int p, a1, a2, *b1, *b2;
     {
         unsigned long n;
         int r;

         n = 94 * (a1 - 0x21) + (a2 - 0x21);

         *b1 = ((p == 1) ? 0xA1 : 0xC9) + (int) (n / 157);

         r = (int) n % 157;

         *b2 = ((r < 63) ? (0x40 + r) : (0xA1 + r - 63));
     }

I hope I've got these algorithms right -- I haven't had time to test them.

-- Steve

Stephen G. Simpson
Department of Mathematics, Pennsylvania State University
333 McAllister Building, University Park, State College, PA 16802
Office phone +1 814 863-0775     Home phone +1 814 238-2274
E-mail simpson@math.psu.edu      FAX +1 814 865-3735
World Wide Web http://www.math.psu.edu/simpson/

From @UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU Sun May  1 09:34:43 1994
Reply-To: Jing-Shin Chang <shin@HERMES.EE.NTHU.EDU.TW>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: Jing-Shin Chang <shin@HERMES.EE.NTHU.EDU.TW>
Subject:      CNS (7-bit) <-> Big5 converter uploaded to ifcss.org
Comments: To: ccnet-l@uga.uga.edu
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
Status: RO
Content-Length: 5116
X-Lines: 146

Dear CCNET netters,

The 7-bit CNS code <-> Big5 code conversion program, as promised in
one of my previous posting is now uploaded to ifcss.org:/incoming
as "(00)ChnCodeFilter-1.4.tar.Z". If you are interested in this package,
please download it from the /incoming directory or from the directory
announced by the ifcss.org administrator.

Note: currently, two tar files are uploaded in /incoming:

        ChnCodeFilter-1.4.tar.Z and 00ChnCodeFilter-1.4.tar.Z.

The latter is a more recent upload. Please get this file and
rename it as ChnCodeFilter-1.4.tar.Z in your local host. Sorry
for such inconvenience since I cannot delete the earlier upload.
The README.1st file is attached at the end of this email. If you
had an official distribution of the "chcode" package from iiidns.
iii.org.tw, you may want to get a copy of this modified version
as a substitute.

I will later post some information on how the CNS messages are passed
through the net as used in Taiwan and similar encoding schemes.
Sorry for not posting such information earlier since I was busy with
two of my final papers, which are due 05/01.

Best.

        Shin -^^-
====
#
# @(#)$Id: README.1st,v 1.1 1994/04/30 22:48:11 shin Exp $
#
#       Jing-Shin Chang
#       Department of Electrical Engineering
#       National Tsing-Hua University
#       Hsinchu, Taiwan 30043, ROC.
#
#       email: shin@hermes.ee.nthu.edu.tw
#
This is a code conversion package for converting among several
commonly used Chinese coding system in Taiwan, ROC. The original
source is distributed by the Institute for Information Industry
(III), Taiwan, ROC.

** See the copyright statements in the "ccvt.c" file first. **

The interface of the original distribution had been modified so
that it could be used as a filter for character streams from
standard input and to standard output.

A few bugs are also fixed to avoid alignment problems when compiled
in different platforms.

[How to make the execution file]

(1) to use the filter version, just type

        make ccf

(2) to use the original interface, type

        make chcode

[How to get a help message]

Type 'ccf' or 'chcode' without arguments to get a brief introduction to
the usage.

Typical examples:

        ccf -be big5file eucfile        # big5 -> EUC
        ccf -eb eucfile | more          # view an EUC file with a Big5 terminal
        zcat eucfile.Z | ccf -eb | more # view a compressed EUC file
                                        # convert a compressed EUC file
        zcat eucfile.Z | ccf -eb - big5file

[File List]

        README.1st      - the current document you are reading
        ccf.1           - nroff man page

        Makefile        - make file for the package
        ccf.c           - main program
        ccvt.c          - code conversion functions (**)
        util.c          - small utility functions

        README          - original README in the official distribution
        chcode.doc      - original official document

        test.b5         - a small test file in Big5
        test.5550       - an IBM5550 file
        test.euc        - an EUC file
        test.cns        - a CNS file
        test.p          - a 7-bit CNS file used for newsgroup posting
        DIFF.ccvt       - major diffs between ccvt.c and code.c in official
                                distribution
                        (* See "Differences ..." in the following section.)

[Differences with the official distribution]

0. Currently, the official distribution is archived in the ftp site:

        iiidns.iii.org.tw(140.92.1.45):/pub/seed/chcode

and several other SeedNet servers.

1. The order of some typedefs and #defines are not the same, because
        the current modified version is acquired from a different
        revision.

2. Put4Byte(), Get4Byte(), GetNSCPcode(), GetIBMHcode() are fixed for
        alignment errors.

3. main() is modified as a filter.

        ** WARNING **

4. The definitions for SS2, SS3, LS2, LS3 codes and their management in
        GetNSCPcode() are different. My version agree with the document
        "README" and "chcode.doc". Furthermore, by testing some SeedNet
        news, I found that the official distribution cannot convert some
        graphic symbols (such as those box drawing symbols) correctly
        while my version can. Therefore, this version might be a better
        choice. (I had used it for quite a long time without serious
        problems.)

        Don't blame me because both versions are III's distributions.

5. The Alter() function is allowed to be compiled for passing input
        string length explicitly. Normally, you don't need to care
        about this.

6. One statement, which determines the code plane, is not the same
        in both version.

7. Most variables and functions in the current version use static variables.
        The official version does not.

8. See other differences in DIFF.ccvt (including bug fixing parts.)
        Uninterested diffs are removed.

[Platforms Tested]

        Sun-3/SunOS 4.0.3
        Sun Sparc Stations/SunOS 4.1.1
        IBM RS6000/AIX 3.2

From @UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU Sun May  1 16:55:24 1994
Reply-To: Jing-Shin Chang <shin@HERMES.EE.NTHU.EDU.TW>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: Jing-Shin Chang <shin@HERMES.EE.NTHU.EDU.TW>
Subject:      B5encode/B5decode and HZ+S Block 1/2 definitions
Comments: To: ccnet-l@uga.uga.edu
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
Status: RO
Content-Length: 18690
X-Lines: 463

The recent postings from Prof. Simpson for HZ+S Version 0.4 can be modified
in a way that is conformant to ISO 2022 and uses only LOGICAL operations
(ANDs or ORs) instead of using multiplications and divisions in making
the mapping from Big5 codes to printable (or 7-bit ASCII) characters.

Look at the following BIG5 map:

/*
 * @(#) Jing-Shin Chang, NTHU, Hsinchu, Taiwan, ROC.
 *
ASCII:  0x00 - 0x1f     - control characters
        0x20 - 0x2f     - space and symbols
        0x30 - 0x39     - digits (0 - 9)
        0x3a - 0x40     - symbols
        (0x20- 0x40     - symbols and digits)
        0x41 - 0x5a     - upper case
        0x5b - 0x60     - symbols
        0x61 - 0x7a     - lower case
        0x7b - 0x7e     - symbols
        0x7f (127)      - DEL
Big5:   High Bytes:     0x81-0x8d,0x8e-0xa0,0xa1-0xfe
                        (0x01-0x0d,0x0e-0x20,0x21-0x7e,
                        when high bit stripped)
        Low  Bytes:     0x40-0x7e,0xa1-0xfe
        a0: ' ' | 0x80, a1: '!' | 0x80, fe: '~' | 0x80

    High Bytes
    00            7e 80 81  8d 8e     a0 a1 a3 a4  c6 c9  f9 fa fe ff
00 +----------------------------------------------------------------+
   |                                                                |
   |                                                                |
3f +----------------------------------------------------------------+
40 +--------------------*----*-.-------.-*---*-#----#-!----!-x---x--+
 : | 40-7e: 63 chars    * U  * . U     . * S * # S  # ! A  ! x U x  |
 : |                    * 3  * . 2     . * P * # T  # ! L  ! x 1 x  |
 : |                    *    * .       . * C * # D  # ! T  ! x   x  |
7e +--------------------*----*-.-------.-*---*-#----#-!----!-x---x--+
80 (NULL|0x80)
81 +----------------------------------------------------------------+

a1 +--------------------*----*-.-------.-*---*-#---#--!----!-x---x--+
 : | a1-fe: 94 chars    * U  * . U     . * bf* # S #  ! A  ! x U x  |
 : |                    * 3  * . 2     . * c0$ # T #  ! L  ! x 1 x  |
 : |                    *    * .       . * e0$ # D #  ! Td5! x   x  |
fe +--------------------*----*-.-------.-*-----#---#--!------x---x--+
ff (DEL)

*/

In Prof. Simpson's proposal, the Big5 codes are divided into two Blocks
with:
                                         +++++++++++ ************
                                         +         + *          *
                                         + Block 1 + *  Block 2 *
                                         + a140 -  + *  c940 -  *
                                         +  c87f   + *    fefe  *
                                         +++++++++++ ************

and the codes are moved to the printable area by adding shift offsets
to the codes. Such operations required multiplications and divisions
for each code.

We can actually aviod using multiplications and divisions if we think
Block 1 and Block 2 are divided as follows:

                                         a1                     fe
                                     40  ************************
                                         *                      *
                                         * Block 2              *
                                         *                      *
                                     7e  ************************
                                     a1  ++++++++++++++++++++++++
                                         +                      +
                                         + Block 1              +
                                         +                      +
                                     fe  ++++++++++++++++++++++++

The codes in Block 1 have the 8-th bit set in both their high bytes and
low bytes. On the other hand, in Block 2, the 8-th bit of the high bytes
are set but the 8-th bit of the low bytes are cleared. Therefore, we can
map the big5 codes into the printable area simply as follows:

        1. clear all the 8-th bits of the high bytes when we encounter
                a big5 code.

        2. clear the 8-th bits of the low bytes for codes in Block 1
                but keep them untouched if the codes belong to Block2

        3. a string of Big5 codes is quoted with a SO (shift out) code
                (e.g., 0x0e or "~1") and a SI (shift in) code (e.g., 0x0f
                or "~}") to distinguish it from ASCII codes.

        4. within a quoted Big5 code string, the codes are assumes to be
                in Block 1 by defaults; however, if a code in Block 2 is
                encountered during the mapping process, it is preceeded
                by an SS2 escape sequence (e.g., ESC 'N' or ~2), which
                represent a temporary shift to the 2nd code plane (i.e.,
                Block 2). (* one SS2 for each Block 2 code *)

(For simplicity of illustration, I only consider a mixed ASCII and BIG5 text
in the above steps. Extension to incorporate ASCII/GB/BIG5 is trivial.)
To implement the encoding and decoding of the above steps, we only need two
simple finite state machines (4 states for encoding and 2 states for decoding).
The main operations will be logical ANDs and ORs without using multiplications
and divisions. The computation load can thus be ignored.

Two programs, called "b5encode" and "b5decode" are attached in this posting
to show the simple implementation. The SO (0x0e), SI (0x0f), SS2 (ESC 'N')
control sequences are the same as the ones used in the SEEDNET news postings
as mentioned in my previous postings. It is conformat to ISO 2022 since all
control codes started with characters outside the 0x21 - 0x7e range.

In fact, the news postings in the SeedNet of Taiwan, which is based on CNS
codes also use the same 7-bit mapping process. The SunMicro implementation of
the Chinese/Japanese/Korean email transmission in its Asia Language
Environment also used the same mapping process to change the 8-bit codes
(Big5 or EUC) to 7-bit ISO 2022 compatible streams before the email is
deliveried. (EUC has a very trivial mapping with CNS-11643/86).The languages
(corresponding to the ~{, ~1, ~2, and ~} escapes in our current discussion)
are specified by "ESC $ ) '0'|'A'|'B'|'C'" for Chinese (Taiwan), Chinese
(Mainland), Japanese or Korean. Therefore, we can use the same b5encode and
b5decode procedures for many current implementations in news and email
postings.

The original HZ and HZ+S proposal have an obvious problem for using '~' (0x7e)
'{' (0x7b), '}' (0x7d) '1' and '2' as escape codes. All these codes belong
to the printable ASCII area; therefore, they are not compatible with ISO 2022.

Hope the above idea and information are useful for the current Big5 -> 7-bit
Big5 (or -> CNS) discussions. BTW. The CNS <-> Big5 converter had been
uploaded to ifcss.org. Personally, I prefer to use the 7-bit CNS for news
exchange. The cost for using a BIG5 <-> HZ+S algorithm is essentially the
same as using a BIGs <-> CNS because the two programs are already there.

        Shin -^^-
===
The following two programs are tested on a 15K big5 files. It seems OK.
However, since it was written within only about 2 hours, your testing
reports and comments are highly appreciated.
=== B5encode.c ===
/*
 * @(#)$Id: b5encode.c,v 1.1 1994/05/01 19:01:15 shin Exp shin $
 * @(#) encode a BIG5 text into 7-bit stream, ISO 2022 compatible
 */

#include        <stdio.h>

#define         ESC     033             /* 0x2b */
#define         SO      016             /* 0x0e */
#define         SI      017             /* 0x0f */
#define         ALE_LANG        HLE     /* default character set for
                                           Chinese (T) */
#define         HLE     '0'             /* Chinese/Taiwan */
#define         CLE     'A'             /* Chinese/Mainland */
#define         JLE     'B'             /* Japanese */
#define         KLE     'C'             /* Korean */

#define         CNS_SS2 0x4e            /* ESC 'N' -- to 2nd plane */
#define         CNS_SS3 0x4f            /* ESC 'O' */

#define         EUC_SS2 0x8e            /* EUC_SS2 0xa2-b0 for plane 2-16  */
#define         EUC_SS3 0x8f

#define         STAT_ASC        0
#define         STAT_B5_C1L     1
#define         STAT_B5_C1H     2
#define         STAT_B5_C0      3

#define is_high(x)      (x>=0xa1&&x<=0xfe)
#define is_low(x)       (!is_high(x))

main()
{
        int state = STAT_ASC;
        int so = 0;
        int     c, c0;


        while ( (c = getchar() ) != EOF ) {
                switch (state) {
                case STAT_ASC:
                        if ( is_high(c) ) {
                                if ( !so ) {
                                        putchar(SO);
                                        so = 1;
                                }
                                c0 = (c&0x7f);  /* clear high-bit */
                                state = STAT_B5_C0;
                        }
                        else {
                                if ( so ) {
                                        putchar(SI);
                                        so = 0;
                                }
                                putchar(c);
                        }
                        break;
                case STAT_B5_C0:
                        if ( is_high(c) ) {
                                putchar(c0);
                                putchar(c&0x7f);
                                state = STAT_B5_C1H;
                        }
                        else {
                                putchar(ESC);
                                putchar(CNS_SS2);
                                putchar(c0);
                                putchar(c);
                                state = STAT_B5_C1L;
                        }
                        break;
                case STAT_B5_C1H:
                case STAT_B5_C1L:
                        if ( is_high(c) ) {
                                c0 = (c&0x7f);  /* clear high-bit */
                                state = STAT_B5_C0;
                        }
                        else {
                                putchar(SI);
                                putchar(c);
                                so = 0;
                                state = STAT_ASC;
                        }
                        break;
                default:
                        break;
                } /* switch */
        } /* while */
}

/*
 * History:
 *
 * $Log: b5encode.c,v $
 * Revision 1.1  1994/05/01  19:01:15  shin
 * Initial revision
 *
 */

=== B5decode.c ===
/*
 * @(#)$Id: b5decode.c,v 1.1 1994/05/01 19:02:46 shin Exp shin $
 * @(#) decode a BIG5 file from a 7-bit stream encoded by b5encode
 */

#include        <stdio.h>

#define         ESC     033             /* 0x2b */
#define         SO      016             /* 0x0e */
#define         SI      017             /* 0x0f */
#define         ALE_LANG        HLE     /* default character set for
                                           Chinese (T) */
#define         HLE     '0'             /* Chinese/Taiwan */
#define         CLE     'A'             /* Chinese/Mainland */
#define         JLE     'B'             /* Japanese */
#define         KLE     'C'             /* Korean */

#define         CNS_SS2 0x4e            /* ESC 'N' -- to 2nd plane */
#define         CNS_SS3 0x4f            /* ESC 'O' */

#define         EUC_SS2 0x8e            /* EUC_SS2 0xa2-b0 for plane 2-16  */
#define         EUC_SS3 0x8f

#define         STAT_ASC        0
#define         STAT_B5_C1L     1
#define         STAT_B5_C1H     2
#define         STAT_B5_C0      3

#define         STAT_SO         4
#define         STAT_SO_ESC     5
#define         STAT_SO_ESC_SS2 6

#define is_high(x)      (x>=0xa1&&x<=0xfe)
#define is_low(x)       (!is_high(x))

main()
{
        int state = STAT_ASC;
        int so = 0;
        int     c, c0;


        while ( (c = getchar() ) != EOF ) {
                switch (state) {
                case STAT_ASC:
                        if ( c == SO ) {
                                so = 1;
                                state = STAT_SO;
                        }
                        else {
                                putchar(c);
                        }
                        break;
                case STAT_SO:
                        if ( c == SI ) {
                                so = 0;
                                state = STAT_ASC;
                        }
                        else if (c == ESC) {
                                if ( getchar() != CNS_SS2 )
                                        fprintf("warning: unexpected char\n");
                                putchar(0x80|getchar());
                                putchar(getchar());
                        }
                        else {
                                putchar(0x80|c);
                                putchar(0x80|getchar());
                        }
                        break;
                default:
                        break;
                } /* switch */
        } /* while */
}

/*
 * History:
 *
 * $Log: b5decode.c,v $
 * Revision 1.1  1994/05/01  19:02:46  shin
 * Initial revision
 *
 */

================== Related Discussion ======
> [simpson@math.psu.edu] said:
>
> Nelson said:
>    In GB it's as simple as putting a ~{ in front of the GB code to
>    make it HZ compliant but can the same be said with BIG5, can i just
>    put ~1 or ~2 in front of BIG5 code to get it HZ+S compliant, or is
>    there a conversion required.
>
> A very simple conversion is required, namely the 8-bit Big5 blocks
> must be packed into the 7-bit code space.  See HZ+S 0.4 below.
>
>    If a conversion is required, i would say just go straight to using
>    CNS since a conversion is required anyways.
>
> The trouble is that CNS is not at all the same thing as Big5.  (I
> among others were guilty of spreading misinformation on this point.)
> Many people have Big5 software, but not many people have CNS software.
> However, I see your point.  Let's see if Jing-Shin Chang or somebody
> else can supply CNS<->Big5 conversion routines that are simple and
> that really work.
>
>   HZ+S Version 0.4
>
>       ... stuffs deleted ...
>
>   In order to give Big5 a standard 7-bit representation, we partition
>   the Big5 code range into two blocks.  Blocks 1 and 2 consist of the
>                                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>   ranges A140 to C87F and C940 to FEFE respectively, where the second
>   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>   byte is restricted to the ranges 40 to 7F and A1 to FE.  Block 1
>                                                          ^^^^^^^
>   contains 5401 more frequently used Chinese characters plus numerals,
>   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>   Roman and Greek and Cyrillic and Bopomofo alphabets, symbols,
>   numerals, Japanese Kana, etc.  Block 2 contains less frequently used
>                                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>   Chinese characters plus some additional symbols.  We pack each of
>   ^^^^^^^^^^^^^^^^^^                                ***************
>   the Block 1 and 2 ranges in order into an initial segment of the
>   ****************************************************************
>   range 2121 to 7D7E where both bytes are restricted to the range 21
>   ******************
>   to 7E.  This packing is implemented by a simple macro.  Thus each
>                         ******************************
>   character in each Big5 block is mapped to a code consisting of two
>   printable ASCII bytes.
>
>   In addition to the the above, we need a way to distinguish between
>   Big5 Block 1, Big5 Block 2, GB, and ASCII.  We can do so by using
>   four tilde escape sequences:
>
>     ~{ to switch into GB (just as in the current HZ standard)
>
>     ~} to switch into ASCII (just as in the current HZ standard)
>
>     ~1 to switch into Big5 Block 1 (this is new)
>
>     ~2 to switch into Big5 Block 2 (this is new)
>
> -- Steve
>
===
> [simpson@math.psu.edu] further said:

>  > BTW, could you post your Big5<->HZS conversion algorithm?
>
> The programs are at ftp.math.psu.edu, /pub/simpson/chinese/hzps.  They
> are lightly hacked versions of Fung's GB <-> HZ converters.  At this
> point in time they are essentially untested.  The Big5 -> HZ+S routine
> is
>
>      big2hzp(b1, b2, a1, a2)
>          int b1, b2, *a1, *a2;
>      {
>          unsigned long n;
>
>          n = 157 * ((b1 < 0xC9) ? (b1 - 0xA1) : (b1 - 0xC9))
>                 + ((b2 < 0xA1) ? (b2 - 0x40) : (b2 - 0xA1 + 63));
>
>          *a1 = 0x21 + (int) (n / 94);
>
>          *a2 = 0x21 + (int) (n % 94);
>      }
>
> and the HZ+S -> Big5 routine is
>
>      hzp2big(p, a1, a2, b1, b2)
>          int p, a1, a2, *b1, *b2;
>      {
>          unsigned long n;
>          int r;
>
>          n = 94 * (a1 - 0x21) + (a2 - 0x21);
>
>          *b1 = ((p == 1) ? 0xA1 : 0xC9) + (int) (n / 157);
>
>          r = (int) n % 157;
>
>          *b2 = ((r < 63) ? (0x40 + r) : (0xA1 + r - 63));
>      }
>
> I hope I've got these algorithms right -- I haven't had time to test them.
>
> -- Steve
>
===
> [simpson@math.psu.edu] further said:
>
> Your file here is not an ASCII/Big5 file.  The character after Schr is
> decimal 148 or hexadecimal 0x94, which is not a legal byte in either
> ASCII or Big5.  ASCII consists only of the range 0 to 127, that is
> 0x00 to 0xFF.  Big5 bytes are in the range 0x40 to 0x7E and 0xA1 to
> 0xFE.
>
> Nevertheless, thanks for pointing this out.  I'm glad you made such a
> thorough test!  What's interesting here is that big2hzps translates
> the two characters after Schr as ~1 ,~}, where   is ASCII 17 or
> 0x11, i.e. Control Q, which is not in the HZ+S preferred range 0x21 to
> 0x7D.  We probably don't want this kind of thing to happen (it makes
> HZ+S less robust), so I'll fix big2hzps to avoid it.  By the way, Fung
> F. Lee's gb2hz has a similar problem.
>
>  > Maybe this is what we have overlooked: the IBM PC extended codes.
>
> I had not overlooked this.  I was well aware that HZ+S as I formulated
> it would not be able cope with IBM PC extended ASCII, or ISO-8859-1,
> or any similar character set, that is any character set which uses
> bytes in the range 0xA1 to 0xFE in a way that is incompatible with GB
> and Big5.  This is a limitation of HZ that carries over to HZ+S.
>
> To solve this, it would be possible (but awkward) to extend HZ+S by
> adding additional tilde escape sequences for ISO-8859-1, IBM PC
> extended ASCII, etc etc.  HZ+S would start looking more and more like
> ISO-2022-JP-2.
>
> -- Steve
>

From @UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU Sun May  1 17:54:08 1994
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:      B5encode/B5decode and HZ+S Block 1/2 definitions
Comments: To: Jing-Shin Chang <shin@HERMES.EE.NTHU.EDU.TW>
Comments: cc: ccnet-l@uga.cc.uga.edu, soft-authors@ifcss.org
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
Status: RO
Content-Length: 2190
X-Lines: 44

Jing-Shin Chang <shin@HERMES.EE.NTHU.EDU.TW> writes:
 > The recent postings from Prof. Simpson for HZ+S Version 0.4 can be modified
 > in a way that is conformant to ISO 2022 and uses only LOGICAL operations
 > (ANDs or ORs) instead of using multiplications and divisions in making
 > the mapping from Big5 codes to printable (or 7-bit ASCII) characters.
 > ......

Many thanks for your thoughtful contribution.

I am making the latest information on HZ+S available for anonymous FTP
at math.psu.edu, /pub/simpson/chinese/hzps.  Some technical advantages
of HZ+S are listed in the documents there.

My only motivation for proposing HZ+S was that the international
Chinese community seems ready for a standard 7-bit representation of
mixed Big5 / GB / ASCII for applications such as Internet e-mail and
news.  HZ+S was the simplest and most straightforward proposal I could
think of that meets these requirements.  I have no strong preference
for HZ+S as against other proposals that would accomplish the same
thing.  ISO-2022 compatibility is an additional desideratum.

We now have several proposals on the table: my HZ+S, Ya-Gui Wei's
HZ-2, a proposal by Yidao Cai using ~] and ~[, and Jing-Shin Chang's
b5encode.  There is also Jing-Shin's idea of using 7-bit CNS.  May I
suggest that Jing-Shin and other interested parties join the
software authors group at ifcss.org.  I think that is a good forum in
which to compare the purely technical aspects.  Broader Chinese
computing aspects can also be discussed on CCNET.

 > The original HZ and HZ+S proposal have an obvious problem for using
 > '~' (0x7e) '{' (0x7b), '}' (0x7d) '1' and '2' as escape codes. All
 > these codes belong to the printable ASCII area; therefore, they are
 > not compatible with ISO 2022.
 >
 > Hope the above idea and information are useful for the current Big5
 > -> 7-bit Big5 (or -> CNS) discussions. BTW. The CNS <-> Big5
 > converter had been uploaded to ifcss.org. Personally, I prefer to
 > use the 7-bit CNS for news exchange. The cost for using a BIG5 <->
 > HZ+S algorithm is essentially the same as using a BIGs <-> CNS
 > because the two programs are already there.
 >
 >         Shin -^^-

-- Steve

From @UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU Tue Jun  7 16:18:57 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 AA02179; Tue, 7 Jun 94 16:18:52 CDT
Message-Id: <9406072118.AA02179@ifcss.org>
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 5753; Tue, 07 Jun 94 17:16:37 EDT
Received: from UGA.CC.UGA.EDU (NJE origin LISTSERV@UGA) by UGA.CC.UGA.EDU (LMail V1.1d/1.7f) with BSMTP id 0767; Tue, 7 Jun 1994 17:16:34 -0400
Date:         Tue, 7 Jun 1994 21:46:06 +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:      Re: More on CNS
Comments: To: CCNET-L@uga.cc.uga.edu
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
Status: R

Just to clarify things a bit -

Wei-chang writes:

>The glyph pointed by ddfc is, to my judgement, identical with that by
>dcd1 (huo4 on my input table, but hu4 on my dictionary: "the sound of
>throw up").  So I think ddfc is duplicated.  This character is on Plain
>2 of CNS, code 4176.

Kuo4, I think, which is much more onomatopaeic!! (that is also the
pronunciation given by Ci'Hai~ (12/1977 isbn 17171.28)  What you say
concurs with what I have found

>Topologically (so to speaking), I cannot distinguish the glyphs pointed
>by c94a and a461 (wu4).  On the biggest dictionary that I have (**Please
>see appendix), I cannot find a character looks more like c94a than
>a461.  So I support Handa's guess, c94a is either incorrect or
>duplicated.

It is duplicated and means "to cut the feet off", just as it looks if you
think about it!       ___
                      ] L   Wu4! =3D Ouch!!

But see how Unicode regards these two characters in the list below..

Steve writes:-

>there are still questions about Japanese kana, the Russian alphabet, and
>Chinese characters and graphical symbols above F9D5..

The first two are clear enough, surely.  As to characters above F9D5, these
must be vendor specific or user-defined -- they do not come within the
"official" Big-5 code any more than C7FD - C8FD.

John.


The following is just for reference -- no guarantees :-)

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^


              Table 1                         Table 2
            ^^^^^^^^^^^                    ^^^^^^^^^^^^
       US-ASCII CHARACTER SET          EXTENDED CHARACTER SET

       0  1   2  3  4  5  6  7         8  9   A  B  C  D  E  F
      _________________________       _________________________
     |  C   |                  |     |      |                  |
   0 |  o   |{ } 0  @  P  `  p |   0 |      |{ } -  -  -  -  - |
   1 |  n   | !  1  A  Q  a  q |   1 |      | -  -  -  -  -  - |
   2 |  t   | "  2  B  R  b  r |   2 |      | -  -  -  -  -  - |
   3 |  r   | #  3  C  S  c  s |   3 |      | -  -  -  -  -  - |
   4 |  o   | $  4  D  T  d  t |   4 |      | +  +  +  +  +  + |
   5 |  l   | %  5  E  U  e  u |   5 |      | +  +  +  +  +  + |
   6 |      | &  6  F  V  f  v |   6 |      | +  +  +  +  +  + |
   7 |  C   | '  7  G  W  g  w |   7 |      | +  +  +  +  +  + |
   8 |  h   | (  8  H  X  h  x |   8 |      | +  +  +  +  +  + |
   9 |  a   | )  9  I  Y  i  y |   9 |      | +  +  +  +  +  + |
   A |  r   | *  :  J  Z  j  z |   A |      | +  +  +  +  +  + |
   B |  a   | +  ;  K  [  k  { |   B |      | +  +  +  +  +  + |
   C |  c   | ,  <  L  \  l  | |   C |      | +  +  +  +  +  + |
   D |  t   | -  =3D  M  ]  m  } |   D |      | +  +  +  +  +  + |
   E |  e   | .  >  N  ^  n  ~ |   E |      | +  +  +  +  +  + |
   F |  r   | /  ?  O  _  o { }|   F |      | +  +  +  +  + { }|
     |__s___|__________________|     |______|__________________|
                    ^^^^^^^^^^^              ^^^^^^^^^^^^^^^^^^
                    |          |            | GB/Big5 1st byte |
                    |          |            |                  |
                    |_______Big5 2nd byte (=D2+=D3 only)___________|
                    ^^^^^^^^^^^              ^^^^^^^^^^^^^^^^^^


Chinese Coding Methods
^^^^^^^^^^^^^^^^^^^^^^

GB
^^
A1A1 - A1FE   symbols
A2B1 - A2E2   dotted, circled and parenthesized Arabic numerals
A2E3 - A2E4   not used
A2E5 - A2EE   parenthesized Chinese numerals
A2EF - A2F0   not used
A2B1 - A2E2   dotted, circled and parenthesized Arabic numerals
A2F1 - A2FC   Roman numerals I to XII
A2FD - A2FE   not used
A3A1 - A3FE   two byte representations of US-ASCII characters
A4A1 - A4F3   Hiragana characters
A4F4 - A4FE   not used
A5A1 - A5F6   Katakana characters
A5F7 - A5FE   not used
A6A1 - A6D8   Greek characters
A6D9 - A6FE   not used
A7A1 - A7F1   Cyrillic characters
A7F2 - A7FE   not used
A8A1 - A8BA   Accented Latin characters
A8BB - A8C4   not used
A8C5 - A8E9   Bopomofo (National Phonetic) characters
A8EA - A9A3   not used
A9A4 - A9EF   Box drawings
A9F1 - AFFE   not used
B0A1 - D7F9   Simplified han`zi` ordered phonetically
D7FA - D7FE   not used
D8A1 - F7FE   Simplified han`zi` ordered by radical + stroke-count


Big5
^^^^
Each character in the Big5 code comprises one byte in the range
A1 to FE (94 characters) followed by one byte either in this
range or in the range 40 to 7E (63 characters)

A140 - A258     Punctuation marks, various signs and symbols
A259 - A261     Han`zi` (9 characters)
A262 - A2AE     Various graphic symbols
A2AF - A2B8     Full width digits
A2B9 - A2C2     Roman numerals
A2C3 - A2CB     Hang=D5Zhou numerals
A2B9 - A2C2     Short form 10, 20, 30
A2CF - A2E8     Full width Latin upper case characters
A2E9 - A343     Full width Latin lower case characters
A244 - A25B     Full width Greek upper case characters
A35C - A373     Full width Greek lower case characters
A374 - A3BA     Bopomofo alphabet
A3BB - A3BF     Pin yin tone marks
A3C1 - A3E1     (Special technical symbols)
A3E2 - A3FE     (??)
A440 - C67E     Han`zi` PLANE 1
C6A1 - C7B0     Hiragana and Katakana
C7B1 - C7C7     Cyrillic alphabet
C7E9 - C7FC     Circled and parenthesized digits
C7FD - C8FD     Unused
C940 - C949     Han`zi` PLANE 2
C94A            CJK Compatibility Ideograph-FA0C (WU4 =3D cut the feet off)
C94B - DDFB     Han`zi` PLANE 2
DDFC            CJK Compatibility Ideograph-FA0D  (KUO4 =3D vomit)
DDFD - F9D5     Han`zi` PLANE 2

From @UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU Sat Jun 11 00:34:41 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 AA23866; Sat, 11 Jun 94 00:34:33 CDT
Message-Id: <9406110534.AA23866@ifcss.org>
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 9670; Sat, 11 Jun 94 01:32: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 1722; Sat, 11 Jun 1994 01:32:08 -0400
Date:         Sat, 11 Jun 1994 14:30:11 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:      Update on CCCII
Comments: To: asiandoc@magnus.acs.ohio-state.edu, ccnet-l@uga.cc.uga.edu,
          mule@etl.go.jp
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
Status: R

[This message is posted to a number of lists, I apologize for any
redundancy caused by this fact.]

On a recent trip to Taipei, I had the opportunity to meet some of the
people involved in the design and implementation of CCCII and asked them
some of the questions I had accumulated over the time. Before I start to
expose this here further, I will give a short intro on CCCII to the
benefit of those who see this acronym for the first time.

CCCII stands for Chinese Character Code for Information Interchange.
As this name suggests, one of its design goals was to create one
single codeset which would include *all* Characters in existence, or
at least all Characters defined by other codesets, so as to make it
possible that CCCII would be useful as an intermediate code between
two particular codesets. A second design goal was to encode what is
today generally referred to as the character-glyph model: The notion
that one (abstract) character can have more than one concret glyph
representing it. In the case of Chinese Characters this goes even
further and includes not only differences in form of the glyph, but
also completely different characters, commonly known as borrowed
characters, which at certain times or places came to stand in place of
a certain character.

Both of these design goals are unique to CCCII and were appealing to
our team, which was looking for a convenient way to encode a
considerable of texts from the Chinese Buddhist Canon and other
sources. It seemed especially fit for the use of researchers working
with historical materials that contain a large number of premodern
characters.

Alas, we met a number of unexpected problems:

First of all, only one company was selling an implementation, which
was a clumsy hardware based solution, expensive and only available for
the PC. We bought it and came to dislike it, because it did'nt even
allow us to use a decent editor in place of the PE2 like tool that
came with it.

Second, we constantly came across characters, which were defined
several times in the codespace and we could not find a convenient and
consistent way to decide which character to use (BTW, this was one of
the reasons for the RLG group to part ways with CCCII and create their
one variations, which is now widely used in US research libraries
under the name EACC: they followed the principle one glyph = one
code).

Third we accumulated a fair amount of characters which we came across
in our texts, but which were missing from CCCII. We also found that
several hundred characters from the CJK UniHan Repertoire in Unicode
were not in CCCII. Later we learned of the amendments to CNS
11643-1992, which also included a fair number of characters
(approx. 2000 out of a total of 48000) not included in CCCII. The
information on CCCII was hard to get and we did not know, if it were
still supported at all. After a year of continuing effort, we could
not even get a complete printed documentation...

These were some of the questions I posed to the people I met in
Taipei. I will summarize here some of the things I heard:

1. CCCII is not dead, it is currently being revised to bring it up to
date as a true interchange code. After this revision is complete
(scheduled for mid 1995) it will once again be a superset of all
existing codes, compatible with CNS, the UniHan Repertoire and EACC.
It will also include the ca 7000 CNS characters currently under revision,
which will be added to CNS as the 8th level, bringing the number of
characters there to ca. 55000. I was told that the main work of this
revision is done (with public taiwanese funding) by a team working in
Beijing. Currently assigned codepoints will in general not be altered.

2. The possible multiple encoding of glyphs will stay, as this the
basis the code is build on. If it is not appropriate or possible to
use this feature (for example to encode modern text in simplified
characters, it would be unwanted to always assign a simplified glyph
to one specific traditional form, were several are possible) the
following ways are recommended to handle this problem:

- Unify all encoding to one specific codepoint and give this codepoint
the relevant semantic in the context of the project.

- Take whatever is convenient and take the according precautions when
searching or otherwise using the text. For printing it will not matter
:-)

The best way would of course be to encode it at the right position
according to the context. This requires the greatest effort and will
usually be done in the process of proofreading.  All of these
strategies requires knowledge of what glyphs are encoded at multiple
places, and where.  This information has not yet been available to us,
but the revision of CCCII will also produce such a list and hopefully
will make it available, a database produced at our institute will also
provide this kind of cross-reference.

3. With the increasing processing power of personal computers,
purely software based implementations of CCCII become possible. I saw
protoypes at two companies, some implementations are available. Be
aware though of the following facts:

- Some products implement only a part of CCCII (e.g. 22000 / 33000
characters, where the "full" implementation currently has ca. 58000,
some are only network-server based implementations).

- All I have seen was PC-based, although I was told that UNIX
implementations exist. Ports to Windows (as an add-in similar to
TWINBRIDGE) are on its way, the Macintosh seems to be a possible
target only further down the road.

- The prices are a fraction of what the hardware based systems costed.
Reasonable site licenses are available.
Information is available from:

  Global Ventures (Asia) S.A.
  Teresa Ju
  Tel +886-3-352-9010
  Fax +886-3-352-0891

 (I have no connection whatsoever with this company)

- Some of the implementations let you use your favorite english
editor, you will have to put up with the fact that the characters are
somehow stretched to fill the same space as four single byte
characters.

Some bitmaps for CCCII are available as part of the public domain
CCDB, available at NCTUCCCA.EDU.TW in /CHINESE/CCDB.  We are looking
into the possibility of using this material for porting CCCII to mule.
Advice in this matter would be highly appreciated. The bitmaps are of
rather different styles and the size is 64 by 64 dots. Input tables
for input by pronounciation (= Pinyin), FourCorner and Cangjie will
become available.


4. One of the options we were considering was switching to the use of
CNS instead of CCCII, since it's design seemed to be somewhat more
consistent. Given the fact, that CCCII will be a superset of all codes
including CNS, and that nobody seemed to be interested in supporting
CNS, we dropped that option, but we will continue to use
crossfreferences to CNS to validate our information on the characters
defined by CCCII.



Christian Wittern

g53150@sakura.kudpc.kyoto-u.ac.jp
International Research Institute for Zen Buddhism
Hanazono University
8-1 Tsubonouchi-cho Nishinokyo Nakakyo-ku
Kyoto, Japan

Tel (075) 811-5181 ext. 208
Fax (075) 811-9664

From shin@hermes.ee.nthu.edu.tw Fri Oct 14 05:32:20 1994
Return-Path: <shin@hermes.ee.nthu.edu.tw>
Received: from nthu.edu.tw by ifcss.org (4.1/IFCSS-Mailer)
	id AA17468; Fri, 14 Oct 94 05:27:11 CDT
Received: from hermes.ee.nthu.edu.tw ([140.114.28.27]) by nthu.edu.tw with SMTP id <181879(1)>; Fri, 14 Oct 1994 18:30:56 +0800
Received: by hermes.ee.nthu.edu.tw (4.1/SMI-4.0/shin-1.0)
	id AA26078; Fri, 14 Oct 94 18:23:24 CST
Date: 	Sat, 15 Oct 1994 08:23:24 +0800
From: shin@hermes.ee.nthu.edu.tw (Jing-Shin Chang)
Message-Id: <9410141023.AA26078@hermes.ee.nthu.edu.tw>
To: ccnet-l@uga.cc.uga.edu, soft-authors@ifcss.org
Subject: GB symbols arranged in reversed order ?
Status: R


Hi, ccnetters,

I found that the special symbol GB:a7b6 (upper case X) and a7b7 (upper case PHI)
and their lower-case version: GB: a7e6 (phi) and a7e7 (x) are in different
order. (Intuitively, it should be PHI, X, ..., phi, x..., isn't it?) I got
such a GB code table from a PostScript hardcopy, which is generate by a
program I got from ifcss (or cnd?) one or two years ago.

When I checked such situation with cxterm with both 'cclib16s' and
'cclib16f', such reversed order is still the same. Therefore, I am wondering
if the official GB code really assigned the codes in this way
(... X, PHI, ..., phi, x ...) or someone who compiled those font files
(or someone who provided a code list) had made some mistake such that the
characters are arranged so strangely.)

In ETen's Big5 mapping, both the upper case and lower case symbols are in the
same order, i.e, ... PHI (C849), X (C84A), ... phi (a7e6), x (a7e7) ... ;
in fact, I would guess that ETen's extension in this part is copied from GB's
special symbols, since the char sequences are the same for all such
special symbols, except for the above two swapped characters.

If the official GB codes are in fact has the same order for the PHI/X and
phi/x characters, then I guess many font files in ifcss.org need to be
re-examined. Any comments or information? My mapping table is wrong?
Thanks for your information.

Jing-Shin -^^-

From owner-ccnet-l@UGA.CC.UGA.EDU Mon May 15 18:12:56 1995
Received: from jolt.eng.umd.edu (jolt.eng.umd.edu [129.2.102.5]) by bacchus.eng.umd.edu (8.6.10/8.6.4) with ESMTP id SAA15127 for <yjj@bacchus.eng.umd.edu>; Mon, 15 May 1995 18:12:48 -0400
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 SAA24396 for <yjj@GLUE.UMD.EDU>; Mon, 15 May 1995 18:12:42 -0400
Message-Id: <199505152212.SAA24396@jolt.eng.umd.edu>
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 2985; Mon, 15 May 95 18:09:27 EDT
Received: from UGA.CC.UGA.EDU (NJE origin LISTSERV@UGA) by UGA.CC.UGA.EDU (LMail V1.2a/1.8a) with BSMTP id 0087; Mon, 15 May 1995 13:24:01 -0400
Date:         Mon, 15 May 1995 10:19:44 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: CNS 11643 fonts
Comments: To: CCNET-L@UGA.CC.UGA.EDU
To: Multiple recipients of list CCNET-L <CCNET-L@UGA.CC.UGA.EDU>
Status: RO

On Sat, 13 May 1995, Douglas L. Schiffer wrote:

> From what I've been able to gather, Big 5 is simply a 2 byte way of
> encoding the first two planes of CNS, with only a few exceptions:
>
>     Big 5 characters C94A & DDFC are not in planes 1,2 or 14.
>     Also, Big5 C255 is in CNS plane 14.
>
> The two sets are in nearly identical ordering, with only a few "jogs"
> out of sequence.  CNS 11643 seems to an ISO 2022 code, with 3 bytes
> of data instead of the more normal 2.  I think there is also some
> thing called "plane locking" to cut down the bytes per character to
> something a little over 2, with ordinary text.
>

CNS 11643 Set 1 to Set 7 are ISO registered character sets, and I believe
they are all 2-bytes sets. Big5 is not, because it does not compliant with
ISO 2022.

> I'd love to see some sample CNS files, with Big 5 translations. If I
> could find these, then I can add CNS support to my toolkit.  Even better
> still would be a standards document, but these things seem to be as
> rare as hen's teeth.      :-)

A response to my post says ftp.ifcss.org/software/fonts/cns carries CNS font.
But I just tried and failed to connect to ftp.ifcss.org.

If not consider the exceptions you mentioned above, I delieve translation
function is possible. Also mapping table can be found in X11R5 nls related
document on ftp site export.lcs.mit.edu.

Jimmy Han (jimmy.han@fx.com)


From owner-ccnet-l@UGA.CC.UGA.EDU Thu Jun 22 03:39:57 1995
Received: from jolt.eng.umd.edu (jolt.eng.umd.edu [129.2.102.5]) by bacchus.eng.umd.edu (8.6.10/8.6.4) with ESMTP id DAA07391 for <yjj@bacchus.eng.umd.edu>; Thu, 22 Jun 1995 03:39:51 -0400
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 DAA22323 for <yjj@GLUE.UMD.EDU>; Thu, 22 Jun 1995 03:39:48 -0400
X-UIDL: 803867682.002
Message-Id: <199506220739.DAA22323@jolt.eng.umd.edu>
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 6453; Thu, 22 Jun 95 03:37:27 EDT
Received: from UGA.CC.UGA.EDU (NJE origin LISTSERV@UGA) by UGA.CC.UGA.EDU (LMail V1.2a/1.8a) with BSMTP id 9779; Thu, 22 Jun 1995 03:37:21 -0400
Date:         Wed, 21 Jun 1995 08:50:00 EST
Reply-To: dschiffer@HORIZONSBBS.COM
Sender: Chinese Computing Network <CCNET-L@UGA.CC.UGA.EDU>
From: "Douglas L. Schiffer" <dschiffer@HORIZONSBBS.COM>
Organization: New Horizons BBS (315)337-3610 v.34
Subject:      Unicode Font holes
To: Multiple recipients of list CCNET-L <CCNET-L@UGA.CC.UGA.EDU>
Status: RO

I looked at my UNIHAN24 font to see which codepoints were blank.
There were 1268 codepoints with no characters (I have one of the
earlier copies that leaves the cell blank rather than putting
a radical as a makeshift substitute.)

Next, I whipped up a dBase program to extract the Unicode Xreference
info for those characters that are missing. This let me see which
character sets stood the best chance to fill in the holes.

Here's a run-down:

GB:

        '1'   GB12345:       142
        '3'   GB7589-87      257
        '5'   GB7590-87      168
        '7'   'modern'        25
        '8'   GB8565-89       76

            The rest had no GB entry. As expected, none had a code
            of '0', as those would have been copied from a GB2312-80
            bitmap.  Slim pickin's, and nobody I've ever heard of
            has any of these font files.

BIG5:
        one character (U+5f5e = C255)  One got away!

CNS:
        '1'  plane 1           1     above Big 5 character
        'E'  plane 14        666     the characters of the beast! :-)

        If someone could find a CNS 11643-1986 font, plane 14, we'd
        have over 1/2 the holes filled!

JIS:
        '1'  JISX0212        497
        'I'  IBM Ext.          5

        JIS 0212 fonts *DO* exist.  Here's another possible source.

KSC:
        '1'  KSC 5657-1991    78

        Not worth the effort to track down one of these.

ANSI:
        all                   18

        Why bother!

CCCII:
        all                  594

        Here's another possible one.  CCCII fonts exist, and this
        has about half the needed characters.


The most likely sets:
----------------------
CCCII OR JIS0212 OR CNS     1002

If we could dredge up these 3 sets, and copy the needed characters
then we'd fill almost all the holes. The remaining ~260 could be
filled by hand.


From owner-ccnet-l@UGA.CC.UGA.EDU Fri Aug 11 14:43:45 1995
Date:         Fri, 11 Aug 1995 19:41: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: pass chinese characters through mail
To: Multiple recipients of list CCNET-L <CCNET-L@UGA.CC.UGA.EDU>
Status: R

Wei Wang <weiwang@merit.edu> writes:
> My last reply and testing message came back to me, but the Chinese
> characters didn't show up on the screen right. I checked the message and
> found out the following three lines were deleted by the mail list server
> from the header part of the message:

> MIME-Version: 1.0
> Content-Type: TEXT/PLAIN; charset=ASCII
> Content-Transfer-Encoding: QUOTED-PRINTABLE

You can tell the list server not to delete these lines by sending it
(the list server, listserv@uga.cc.uga.edu, _not_ the mailing list)
the command

SET CCNET-L IETFHDR

I did this some time ago, so the list server sent me your message with
these header lines intact, and the local MIME software decoded the
quoted-printable stuff automatically.

So if your aim is merely to get 8-bit text between two MIME-capable
mailers without trusting the network, your method will indeed work.

However, one could use the "charset" parameter to tell the receiving
software what character set one is using.  Some MIME software (including
the the stuff here) can use this information to decide how to display
the text.  For example (Unix/X only), in some systems, including those
based on metamail, one can add lines in the mailcap file to view the
message in a cxterm if it has a particular value of "charset".  My local
setup maps the character set of the message to Unicode and displays the
result in a Unicode window (9term).  Perhaps other systems can select
fonts on the basis of the "charset" parameter.

The proposed name for the widely used mixture of ASCII and high-bit GB is
CN_GB, but this has not yet been presented to the IETF.  Similarly, the
proposed name for the widely used mixture of ASCII and Big-5 is CN_BIG-5.
One is not supposed to use names before they are registered, and private
charset names should begin with "X-".  So perhaps we could settle on the
"charset" values X-CN_GB and X-CN_BIG-5 for the interim, and your header
would be

MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=X-CN_GB
Content-Transfer-Encoding: QUOTED-PRINTABLE


From owner-ccnet-l@UGA.CC.UGA.EDU Fri Jan 12 02:25:59 1996
Received: from uga.cc.uga.edu (uga.cc.uga.edu [128.192.1.5]) by ccic.ifcss.org (8.6.11/8.6.11) with SMTP id CAA16206 for <yjj@IFCSS.ORG>; Fri, 12 Jan 1996 02:25:52 -0500
Message-Id: <199601120725.CAA16206@ccic.ifcss.org>
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R3)
   with BSMTP id 3121; Fri, 12 Jan 96 02:18:52 EST
Received: from UGA.CC.UGA.EDU (NJE origin LISTSERV@UGA) by UGA.CC.UGA.EDU (LMail V1.2a/1.8a) with BSMTP id 4826; Fri, 12 Jan 1996 02:18:47 -0500
Date:         Fri, 12 Jan 1996 15:18:58 +0800
Reply-To: Shann Wei-Chang <shann@MATH.NCU.EDU.TW>
Sender: Chinese Computing Network <CCNET-L@UGA.CC.UGA.EDU>
From: Shann Wei-Chang <shann@MATH.NCU.EDU.TW>
Subject:      Big-5 and CNS coding
To: Multiple recipients of list CCNET-L <CCNET-L@UGA.CC.UGA.EDU>
Status: R

Hi,

In http://www.math.ncu.edu.tw/~shann/chprog.html (this page in English),
you will find Big-5 tables in PostScript format (taken from Prof. Simpson's
TeX pk files and dvips), and a short essay comparing Big-5 and CNS codes
(this page in Chinese).

The page chprog.html and the tree beneath it are still growing.

-Shann

From owner-ccnet-l@UGA.CC.UGA.EDU Thu Jan 18 09:02:43 1996
Received: from uga.cc.uga.edu (uga.cc.uga.edu [128.192.1.5]) by ccic.ifcss.org (8.6.11/8.6.11) with SMTP id JAA26055 for <yjj@IFCSS.ORG>; Thu, 18 Jan 1996 09:02:40 -0500
Message-Id: <199601181402.JAA26055@ccic.ifcss.org>
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R3)
   with BSMTP id 5844; Thu, 18 Jan 96 08:55:02 EST
Received: from UGA.CC.UGA.EDU (NJE origin LISTSERV@UGA) by UGA.CC.UGA.EDU (LMail V1.2a/1.8a) with BSMTP id 7637; Thu, 18 Jan 1996 08:55:00 -0500
Date:         Thu, 18 Jan 1996 08:54:53 -0500
Reply-To: Doug Schiffer <dschiffer@CYBER2.SERVTECH.COM>
Sender: Chinese Computing Network <CCNET-L@UGA.CC.UGA.EDU>
From: Doug Schiffer <dschiffer@CYBER2.SERVTECH.COM>
Subject:      CCCII project update
To: Multiple recipients of list CCNET-L <CCNET-L@UGA.CC.UGA.EDU>
Status: R

I've been working on the CCCII codeset, writing a Visual Basic program that
lets you display the various font files (reducing in size to 32x32 pixels).
The program is mostly up and running.  It lets you browse through the font
files, select a character, and copy its bitmap to the clipboard.

I've been transforming the database files that came with the fonts (located at
ftp://NCTUCCCA.EDU.TW/Chinese/CCDB). I converted them to standard dbase file
format, and then I used a relational database manager to change the radical
information (encoded as CCCII characters) to a single number 1-214.  In the
process, I found the following errors in the database:
                  listed
    CCCII code    radical    correct radical
     217E7C        2E58       2C4B (r 40 + 12)
     233D53        2D5B       2D6B (r162 +  8)
     254A36        2E63       2D63 (r154 + 10)

I've updated my database with these values. I now have a radical index for
both "NF" and "RARELY" sets, in radical+stroke order for these sets. Soon,
my VB program will be able to search on radical & stroke info for those 2 sets.

 *------------------------------------------------------------------------*
*   Doug Schiffer      email:  dschiffer@servtech.com                      *
*                      www:    http://www.servtech.com/public/dschiffer    *
 *------------------------------------------------------------------------*

From owner-ccnet-l@UGA.CC.UGA.EDU Fri Feb  2 13:05:55 1996
Received: from uga.cc.uga.edu (uga.cc.uga.edu [128.192.1.5]) by ccic.ifcss.org (8.6.11/8.6.11) with SMTP id NAA02820 for <yjj@IFCSS.ORG>; Fri, 2 Feb 1996 13:05:49 -0500
Message-Id: <199602021805.NAA02820@ccic.ifcss.org>
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R3)
   with BSMTP id 2033; Fri, 02 Feb 96 12:58:23 EST
Received: from UGA.CC.UGA.EDU (NJE origin LISTSERV@UGA) by UGA.CC.UGA.EDU (LMail V1.2a/1.8a) with BSMTP id 6452; Fri, 2 Feb 1996 12:58:21 -0500
Date:         Fri, 2 Feb 1996 13:04:35 -0500
Reply-To: Yuan Jiang <yjj@IFCSS.ORG>
Sender: Chinese Computing Network <CCNET-L@UGA.CC.UGA.EDU>
From: Yuan Jiang <yjj@IFCSS.ORG>
Subject:      regular expression in CJK
To: Multiple recipients of list CCNET-L <CCNET-L@UGA.CC.UGA.EDU>
Status: R

With the increasing use of Unicode, the issue of
regular expression is surfacing.  This is important
for text searching/parsing.  From what I can think

1) [a-z], [A-Z], [0-9] should be extended to any user
defined code segment.

2) \w, \b based on the concept of word don't apply to
CJK. \s regarding space does even apply (am I right?).

Anything else that should be added to the regular expression
considering the features of CJK?

Yuan

From owner-ccnet-l@UGA.CC.UGA.EDU Fri Apr  5 15:19:44 1996
Received: from uga.cc.uga.edu (uga.cc.uga.edu [128.192.1.5]) by ccic.ifcss.org (8.6.11/8.6.11) with SMTP id PAA13488 for <yjj@IFCSS.ORG>; Fri, 5 Apr 1996 15:19:43 -0500
Message-Id: <199604052019.PAA13488@ccic.ifcss.org>
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R3)
   with BSMTP id 0153; Fri, 05 Apr 96 15:12:06 EST
Received: from UGA.CC.UGA.EDU (NJE origin LISTSERV@UGA) by UGA.CC.UGA.EDU (LMail V1.2a/1.8a) with BSMTP id 6256; Fri, 5 Apr 1996 15:12:05 -0500
Date:         Fri, 5 Apr 1996 15:11:14 -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:      Re: Big5 and GB codes to Pinyin
Comments: To: Fabrizio Pregadio <pregadio@UNIVE.IT>
To: Multiple recipients of list CCNET-L <CCNET-L@UGA.CC.UGA.EDU>
In-Reply-To:  <199604051953.OAA03826@leibniz.math.psu.edu>
Status: R

Fabrizio Pregadio writes:
 > Sorry, the software I've been happy with to convert from GuoBiao into
 > pinyin is gb2pinyin. HC 1.5 and 3.0 made me happy a few moments earlier,
 > when I needed to convert Big5 into GuoBiao to be able to use gb2pinyin.

I have a version of a program called c2t which does GB -> PinYin
conversion and also does Big5 -> PinYin conversion.  It is available
by anonymous FTP at ftp.math.psu.edu, /pub/simpson/chinese/c2t.tar.Z.
That is the Unix version; the DOS version is
/pub/simpson/chinese/msdos/c2t.zip.

Stephen G. Simpson
Department of Mathematics, Pennsylvania State University
333 McAllister Building, University Park, State College PA 16802
Office 814-863-0775           Fax 814-865-3735
Email simpson@math.psu.edu    Home 814-238-2274
World Wide Web http://www.math.psu.edu/simpson/

From owner-ccnet-l@UGA.CC.UGA.EDU Sun Jul  7 23:04:09 1996
Received: from uga.cc.uga.edu (uga.cc.uga.edu [128.192.1.5]) by ccic.ifcss.org (8.6.11/8.6.11) with SMTP id XAA26840 for <yjj@IFCSS.ORG>; Sun, 7 Jul 1996 23:04:07 -0400
Message-Id: <199607080304.XAA26840@ccic.ifcss.org>
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R3)
   with BSMTP id 5460; Sun, 07 Jul 96 22:56:50 EDT
Received: from UGA.CC.UGA.EDU (NJE origin LISTSERV@UGA) by UGA.CC.UGA.EDU (LMail V1.2a/1.8a) with BSMTP id 1337; Sun, 7 Jul 1996 22:56:50 -0400
Date:         Mon, 8 Jul 1996 10:57:14 SGP
Reply-To: xihy@VNET.IBM.COM
Sender: Chinese Computing Network <CCNET-L@UGA.CC.UGA.EDU>
From: XI HongYu <xihy@VNET.IBM.COM>
Subject:      Re: Two questions
To: Multiple recipients of list CCNET-L <CCNET-L@UGA.CC.UGA.EDU>
Status: R

Dear Lars Bo Christensen,

I'm not sure is there a standard (China Gov or ISO) for tone pinyin code
page.  If you dev a set of font, you can use for yourself.  But other one
may creat another font set.  You cannot share files with other person.

If you really need to build tone pinyin code.  You may need use COMBINE
system.  It means if one normally one char use one byte,  but if the char
with tone, it will take 2 byte.   For example, "ren(3)" (people) will use
4 bytes,  3 bytes for "ren" and 1 byte for tone.  But it will only display
3 char position on screen.

Thai and Vietnamese have same problem.  They are use COMBINE system to
mark tone.


  /------------------------+----------------------------\  XX   XX IIII
  | XI, HongYu  ~{^I:lSn~} |  RS/6000, ASEAN/South Asia |   XX XX   II
  | eml: xihy@vnet.ibm.com |  IBM World Trade Asia Corp |    XXX    II
  | Tel: (65) 320-1992     |  80 Anson Road, IBM Towers |    XXX    II
  | Fax: (65) 225-9444     |  Singapore 079907          |   XX XX   II
  \------------------------+----------------------------/  XX   XX IIII

From owner-ccnet-l@UGA.CC.UGA.EDU Wed Jan 29 15:56:59 1997
Received: from listmail.cc.uga.edu (listmail.cc.uga.edu [128.192.232.10]) by ccic.ifcss.org (8.6.11/8.6.11) with ESMTP id PAA18386 for <yjj@IFCSS.ORG>; Wed, 29 Jan 1997 15:56:51 -0500
Message-Id: <199701292056.PAA18386@ccic.ifcss.org>
Received: from uga.cc.uga.edu by listmail.cc.uga.edu (LSMTP for Windows NT v1.0a) with SMTP id D3B66670 ; Wed, 29 Jan 1997 15:48:09 -0500
Received: from UGA.CC.UGA.EDU (NJE origin LISTSERV@UGA) by UGA.CC.UGA.EDU (LMail V1.2a/1.8a) with BSMTP id 2249; Wed, 29 Jan 1997 15:46:38 -0500
Date:         Wed, 29 Jan 1997 15:47:14 -0500
Reply-To: Richard S Cook <rscook@WORLD.STD.COM>
Sender: Chinese Computing Network <CCNET-L@UGA.CC.UGA.EDU>
From: Richard S Cook <rscook@WORLD.STD.COM>
Subject:      a flexible encoding standard
Comments: cc: Jose Manuel Tesoro <joel@iohk.com>
To: Multiple recipients of list CCNET-L <CCNET-L@UGA.CC.UGA.EDU>
Status: RO

After recently reading the short article in WIRED magazine titled "Lost in
Translation" (Sept. '96, pp.130-1, Jose Manuel Tesoro <joel@iohk.com>), I
would like to offer a few comments.  I think that from the perspective of
anyone interested in Chinese literature it is a great pity that so many of
the great classical texts are not readily available in computerized form,
due to lack of a suitable standard.  As was noted by a contributor on the
CCNET listserv recently, Chinese characters are truly infinite.  This
should not prevent an adequate standard from being developed for the main
Classical texts. (Readers interested in descriptions of encoding schemes
now in use might check out the following:
http://www.iijnet.or.jp/iriz/irizhtml/kanjibas/cefintro.htm.)  What is
truly needed however is a flexible encoding standard, permitting users to
create unusual characters as needed.  Given the fact that most if not all
square-script characters follow rules of composition based on a limited
number of possible components, it should be possible to create most any
character (in scaleable outline format suitable for laser printing) simply
by defining the relative proportions and placement of its components.
Thus, for the purpose of entering a classical text, all the standard or
currently used chars. could be entered (e.g. in Big5), and then
non-standard ones built-up and entered in as needed, according to a
standard for composing supplemental graphs.  Such a standard could also
significantly reduce the size of the actual fonts, since rather than
redundant info for rendering a particular "radical", for example, being
given in every character in the font in which it occurs, a link would
exist between all characters having the same components.  Some roman
TrueType fonts (for example) employ a similar technique in adding
diacritics to standard roman characters.  Thus, for example, Fontographer
permits typographers to draw each lower-case vowel only once, and each
kind of diacritic only once, and create various "new" characters
(combinations of vowel and diacritic) by means of "linked references".
This can substantially reduce the ultimate font size.  It seems to me that
a similar technique would be well employed in Chinese typography.  Users
could compose needed high resolution characters on the fly, and embedded
in each such character would be info necessary to render, sort and access
it.

Just a few thoughts ... any comments or references would be welcome.

Richard

From owner-ccnet-l@UGA.CC.UGA.EDU Thu Jan 30 11:19:38 1997
Received: from listmail.cc.uga.edu (listmail.cc.uga.edu [128.192.232.10]) by ccic.ifcss.org (8.6.11/8.6.11) with ESMTP id LAA02834 for <yjj@IFCSS.ORG>; Thu, 30 Jan 1997 11:19:31 -0500
Message-Id: <199701301619.LAA02834@ccic.ifcss.org>
Received: from uga.cc.uga.edu by listmail.cc.uga.edu (LSMTP for Windows NT v1.0a) with SMTP id 5E4EB790 ; Thu, 30 Jan 1997 11:11:41 -0500
Received: from UGA.CC.UGA.EDU (NJE origin LISTSERV@UGA) by UGA.CC.UGA.EDU (LMail V1.2a/1.8a) with BSMTP id 1123; Thu, 30 Jan 1997 11:10:02 -0500
Date:         Thu, 30 Jan 1997 23:34:04 +0800
Reply-To: gko@mail.net.tw
Sender: Chinese Computing Network <CCNET-L@UGA.CC.UGA.EDU>
From: Georges KO <gko@mail.net.tw>
Organization: The Church of Emacsology, Taipei branch, Monastery #106
Subject:      Re: a flexible encoding standard
To: Multiple recipients of list CCNET-L <CCNET-L@UGA.CC.UGA.EDU>
In-Reply-To:  Richard S Cook's message of Wed, 29 Jan 1997 15:47:14 -0500
Status: RO

Richard S Cook <rscook@WORLD.STD.COM> writes:

[...About composing characters...etc.]
> Just a few thoughts ... any comments or references would be welcome.

        Have you looked at the Boshiamy input method? It can be a good
starting  point... Basically, this method  consists  of splitting each
character into small  components that  can be input according to their
shape, to their meaning or   to their sound, without  Chinese-specific
keyboard.

        For example, my  name  in Pinyin is  `ke' (mu4  ke3),  so it's
input by `tto', `t'  as `t'ree and  `to'  for `ke3' (shape). If  there
were  characters  composed of  the  `water' radical or `grass' radical
with my name, then they would be input  with `wtto' and `rtto' (`r' as
`r'oots).  No more `huh... which tone is it?' :) !

        Of  course,  it's  just  an  input  method,  but  it's  a good
reference for an exhaustive list of possible components.

        For  more information, look  at http://www.boshiamy.com.tw and
any IFCSS mirror for this input method.

        G.
--
 Georges KO [ gko@mail.net.tw http://mtc.ntnu.edu.tw:52021/~m52021 ]
                              Home page closed from Feb. 1st to Feb. 16th

From owner-ccnet-l@UGA.CC.UGA.EDU Thu Jan 30 12:12:29 1997
Received: from listmail.cc.uga.edu (listmail.cc.uga.edu [128.192.232.10]) by ccic.ifcss.org (8.6.11/8.6.11) with ESMTP id MAA05173 for <yjj@IFCSS.ORG>; Thu, 30 Jan 1997 12:12:28 -0500
Message-Id: <199701301712.MAA05173@ccic.ifcss.org>
Received: from uga.cc.uga.edu by listmail.cc.uga.edu (LSMTP for Windows NT v1.0a) with SMTP id C5C29E30 ; Thu, 30 Jan 1997 12:04:41 -0500
Received: from UGA.CC.UGA.EDU (NJE origin LISTSERV@UGA) by UGA.CC.UGA.EDU (LMail V1.2a/1.8a) with BSMTP id 4744; Thu, 30 Jan 1997 12:02:59 -0500
Date:         Fri, 31 Jan 1997 01:03:27 +0800
Reply-To: Jacob Morrison <Jacob.Morrison@CDC.COM>
Sender: Chinese Computing Network <CCNET-L@UGA.CC.UGA.EDU>
From: Jacob Morrison <Jacob.Morrison@CDC.COM>
Subject:      Re: a flexible encoding standard
Comments: To: Georges KO <gko@mail.net.tw>
To: Multiple recipients of list CCNET-L <CCNET-L@UGA.CC.UGA.EDU>
In-Reply-To:  <32f0c83851c9002@cdshub.cdc.com>
Status: RO

I agree that Bosiamy is a nice input method (that's what I use), but
I don't think it slices things finely enough for use with the many
character variations. For example, you would need to encode the
difference between a two-dot water radical and a three-dot water
radical. Another big issue is making a canonical decomposition and order,
allowing a character to be identified unambiguously from its components.

Someone from mainland china put together
an input method that handles all the 22,000 CJK characters in Unicode.
I might be able to find the info on it somewhere.

There was talk on the Unicode (see http://unicode.org) mailing list a
while back about this problem. They would certainly be interested in a
solution.

Regards,
Jake

Control Data Asia/Pacific             Jacob.Morrison @ cdc.com

On Thu, 30 Jan 1997, Georges KO wrote:

> Richard S Cook <rscook@WORLD.STD.COM> writes:
>
> [...About composing characters...etc.]
> > Just a few thoughts ... any comments or references would be welcome.
>
>         Have you looked at the Boshiamy input method? It can be a good
> starting  point... Basically, this method  consists  of splitting each
> character into small  components that  can be input according to their
> shape, to their meaning or   to their sound, without  Chinese-specific
> keyboard.
>
>         For example, my  name  in Pinyin is  `ke' (mu4  ke3),  so it's
> input by `tto', `t'  as `t'ree and  `to'  for `ke3' (shape). If  there
> were  characters  composed of  the  `water' radical or `grass' radical
> with my name, then they would be input  with `wtto' and `rtto' (`r' as
> `r'oots).  No more `huh... which tone is it?' :) !
>
>         Of  course,  it's  just  an  input  method,  but  it's  a good
> reference for an exhaustive list of possible components.
>
>         For  more information, look  at http://www.boshiamy.com.tw and
> any IFCSS mirror for this input method.
>
>         G.
> --
>  Georges KO [ gko@mail.net.tw http://mtc.ntnu.edu.tw:52021/~m52021 ]
>                               Home page closed from Feb. 1st to Feb. 16th
>

From owner-ccnet-l@UGA.CC.UGA.EDU Thu Jan 30 13:20:39 1997
Received: from listmail.cc.uga.edu (listmail.cc.uga.edu [128.192.232.10]) by ccic.ifcss.org (8.6.11/8.6.11) with ESMTP id NAA08062 for <yjj@IFCSS.ORG>; Thu, 30 Jan 1997 13:20:38 -0500
Message-Id: <199701301820.NAA08062@ccic.ifcss.org>
Received: from uga.cc.uga.edu by listmail.cc.uga.edu (LSMTP for Windows NT v1.0a) with SMTP id 4D44A020 ; Thu, 30 Jan 1997 13:12:56 -0500
Received: from UGA.CC.UGA.EDU (NJE origin LISTSERV@UGA) by UGA.CC.UGA.EDU (LMail V1.2a/1.8a) with BSMTP id 9999; Thu, 30 Jan 1997 13:11:15 -0500
Date:         Thu, 30 Jan 1997 13:12:09 -0500
Reply-To: Richard S Cook <rscook@WORLD.STD.COM>
Sender: Chinese Computing Network <CCNET-L@UGA.CC.UGA.EDU>
From: Richard S Cook <rscook@WORLD.STD.COM>
Subject:      Re: a flexible encoding standard
To: Multiple recipients of list CCNET-L <CCNET-L@UGA.CC.UGA.EDU>
Status: RO

Just a brief note of clarification ... as some responding to my earlier
comments have seen, I was suggesting a different sort of encoding scheme,
one which would define certain components univerally occurring (or
possible) in Chinese characters, define configurations of these components
for common characters, and define a method for composing uncommon
characters as needed.  I was not simply talking about another input
method, though some have noted that certain input methods do function
along componential lines.

To further explain, I think the current state of Chinese encoding is just
a brute strength approach ... something similar to what would be required
if an English typographer were required to anticipate every word which a
potential typist might ever want to type when using the font being
designed.  Certainly, when kerning is considered, a roman typographer does
try to take into account what combinations of letters are probable .. he
doesn't kern useless pairs which are unlikely ever to be adjacent.  Why is
it necessary in Chinese typography to have incredibly enormous character
sets to satisfy the huge periodic and local graphical divergences?  Would
we like to type English if the fonts were built on a word by word basis,
so that to type "electronic", we'd have to sort out things like
"elecampane" and "eleemosynary"?  And what if Shakespearian, Chaucerian or
Beowulfian spellings were included?  An English font too might have
millions of "characters" ... one per variant spelling of each vocabulary
item. Really ... the best way cannot be ever bigger and bigger character
sets ...

From owner-ccnet-l@UGA.CC.UGA.EDU Thu Jan 30 13:50:15 1997
Received: from listmail.cc.uga.edu (listmail.cc.uga.edu [128.192.232.10]) by ccic.ifcss.org (8.6.11/8.6.11) with ESMTP id NAA09323 for <yjj@IFCSS.ORG>; Thu, 30 Jan 1997 13:50:13 -0500
Message-Id: <199701301850.NAA09323@ccic.ifcss.org>
Received: from uga.cc.uga.edu by listmail.cc.uga.edu (LSMTP for Windows NT v1.0a) with SMTP id 644AF4A0 ; Thu, 30 Jan 1997 13:42:10 -0500
Received: from UGA.CC.UGA.EDU (NJE origin LISTSERV@UGA) by UGA.CC.UGA.EDU (LMail V1.2a/1.8a) with BSMTP id 2053; Thu, 30 Jan 1997 13:40:43 -0500
Date:         Thu, 30 Jan 1997 19:46:43 +0100
Reply-To: Werner Lemberg <xlwy01@UXP1.HRZ.UNI-DORTMUND.DE>
Sender: Chinese Computing Network <CCNET-L@UGA.CC.UGA.EDU>
From: Werner Lemberg <xlwy01@UXP1.HRZ.UNI-DORTMUND.DE>
Subject:      Re: a flexible encoding standard
Comments: To: Richard S Cook <rscook@WORLD.STD.COM>
To: Multiple recipients of list CCNET-L <CCNET-L@UGA.CC.UGA.EDU>
In-Reply-To:  <199701301823.TAA21763@uxp1.hrz.uni-dortmund.de>
Status: RO

On Thu, 30 Jan 1997, Richard S Cook wrote:

> Just a brief note of clarification ... as some responding to my earlier
> comments have seen, I was suggesting a different sort of encoding scheme,
> one which would define certain components univerally occurring (or
> possible) in Chinese characters, define configurations of these components
> for common characters, and define a method for composing uncommon
> characters as needed.  I was not simply talking about another input
> method, though some have noted that certain input methods do function
> along componential lines.

Maybe SKIP is what you want. Jack Halpern developed it for his
Japanese-English dictionary. It's a very convenient searching method for
CJK characters:

you have basically 4 classes: characters which can be separated
horizontally, characters which can be separated vertically, characters
which are enclosed (at least on two sides) and characters which do not fit
in any of these categories. This yields a number between 1 and 4. The next
step is simply to count the number of strokes on the left and right (upper
and lower/inner and outer) side; this process yields another two numbers
(Halpern further refines this scheme but this is not so important here).
Of course this description is rudimentary.

Doing this you get a very fine-grained splitting into groups; if I
remember correctly the largest group consists of about 20 characters.
And you don't need to learn radicals... Nevertheless, this method is only
suitable to search characters you know how it looks.

> Why is
> it necessary in Chinese typography to have incredibly enormous character
> sets to satisfy the huge periodic and local graphical divergences?

It's irrelevant IMHO how the characters are stored; maybe it's possible to
logically split CJK characters into smaller units. But if you want to
print them you again need the whole glyph since it's impossible to compose
a CJK glyph by describing the components alone. You need further
information where and how the components are positioned and scaled (this
is the way how some composite CJK TrueType fonts are done).

>  Would
> we like to type English if the fonts were built on a word by word basis,
> so that to type "electronic", we'd have to sort out things like
> "elecampane" and "eleemosynary"?  And what if Shakespearian, Chaucerian or
> Beowulfian spellings were included?  An English font too might have
> millions of "characters" ... one per variant spelling of each vocabulary
> item. Really ... the best way cannot be ever bigger and bigger character
> sets.

In our computer age it's _really_ irrelevant how large the character
set(s) are. Much more important is to investigate how to _access_ the
characters in an easy-to-understand way (see above SKIP).


    Werner

From owner-ccnet-l@UGA.CC.UGA.EDU Tue Mar 11 20:15:24 1997
Received: from listmail.cc.uga.edu (listmail.cc.uga.edu [128.192.232.10]) by ccic.fas.harvard.edu (8.6.11/8.6.11) with ESMTP id UAA19295 for <yjj@IFCSS.ORG>; Tue, 11 Mar 1997 20:15:19 -0500
Message-Id: <199703120115.UAA19295@ccic.fas.harvard.edu>
Received: from uga.cc.uga.edu by listmail.cc.uga.edu (LSMTP for Windows NT v1.0a) with SMTP id C22EA300 ; Tue, 11 Mar 1997 20:06:51 -0500
Received: from UGA.CC.UGA.EDU (NJE origin LISTSERV@UGA) by UGA.CC.UGA.EDU (LMail V1.2c/1.8c) with BSMTP id 5261; Tue, 11 Mar 1997 20:05:57 -0500
Date:         Wed, 12 Mar 1997 09:07:05 +0800
Reply-To: Jacob Morrison <Jacob.Morrison@CDC.COM>
Sender: Chinese Computing Network <CCNET-L@UGA.CC.UGA.EDU>
From: Jacob Morrison <Jacob.Morrison@CDC.COM>
Subject:      Re: Q: GB, unicode and java
Comments: To: Ji Zhang <zhang@TAPPET.IME.NRC.CA>
To: Multiple recipients of list CCNET-L <CCNET-L@UGA.CC.UGA.EDU>
In-Reply-To:  <33256f8b5381002@cdshub.cdc.com>
Status: R

Ji Zhang,

Unicode is a superset of GB 2312 (and most other
character sets). Unicode does not use escape
codes like ISO 2022 to encode other character sets.

I am only just getting started with Java, so I don't
know all the details. Things also change in JDK 1.1.

The ideal way is to convert the GB in your source file
to UTF-8 (an 8-bit encoding of Unicode) before compiling.
I understand that there is a new command line switch
in the JDK 1.1 compiler to do this automatically for you.

If you need a GB->UTF-8 converter, look at the utf7 package (Unix)
on ftp.ifcss.org.

The Chinese may not display correctly on all platforms (only
ISO 8859-1 display is supported in the initial implementations),
though this should be fixed now.

You may also be able to embed GB directly in "byte" or String variables,
though this may not work very well.

For common knowlege, see the JDK docs :-)

Regards,
Jake

On Tue, 11 Mar 1997, Ji Zhang wrote:

> Hi there,
>
> It is said that java accepts unicode for output.
> Could unicode experts tell me what is the escape
> code for access GB, what is the escape code for
> exit GB ?  Is a code mapping needed from GB to
> unicodes or simplely keep GB as it is ?
>
> Will it look like:
>    \uhhhh \uhhhh \uhhhh \uhhhh \uhhhh \uhhhh ... \uhhhh
>      ||                                            ||
>     begin   gb     gb     gb     gb     gb   ...  exit
> in java ?
>
> Regards,
>
> Ji Zhang <zhang@tappet.ime.nrc.ca>
>
> BTW, I do not want to "read" any docs at unicode.org.
> I just want to know a bit commom knowledge.
>

From owner-ccnet-l@UGA.CC.UGA.EDU Tue Mar 11 23:28:28 1997
Received: from listmail.cc.uga.edu (listmail.cc.uga.edu [128.192.232.10]) by ccic.fas.harvard.edu (8.6.11/8.6.11) with ESMTP id XAA26929 for <yjj@IFCSS.ORG>; Tue, 11 Mar 1997 23:28:27 -0500
Message-Id: <199703120428.XAA26929@ccic.fas.harvard.edu>
Received: from uga.cc.uga.edu by listmail.cc.uga.edu (LSMTP for Windows NT v1.0a) with SMTP id BDFCEBF0 ; Tue, 11 Mar 1997 23:20:00 -0500
Received: from UGA.CC.UGA.EDU (NJE origin LISTSERV@UGA) by UGA.CC.UGA.EDU (LMail V1.2c/1.8c) with BSMTP id 4239; Tue, 11 Mar 1997 23:19:07 -0500
Date:         Tue, 11 Mar 1997 23:24:21 -0500
Reply-To: Erik Peterson <eepeter@EROLS.COM>
Sender: Chinese Computing Network <CCNET-L@UGA.CC.UGA.EDU>
From: Erik Peterson <eepeter@EROLS.COM>
Subject:      Re: Q: GB, unicode and java
Comments: To: Jacob Morrison <Jacob.Morrison@CDC.COM>
To: Multiple recipients of list CCNET-L <CCNET-L@UGA.CC.UGA.EDU>
In-Reply-To:  <199703120107.UAA27870@mx05.erols.com>
Status: R

Some additions to message from Jacob Morrison:

>The ideal way is to convert the GB in your source file
>to UTF-8 (an 8-bit encoding of Unicode) before compiling.
>I understand that there is a new command line switch
>in the JDK 1.1 compiler to do this automatically for you.

  The Java Development Kit version 1.1 (JDK 1.1) comes with a
program separate from the compiler called native2ascii.  It
can convert GB2312 (or Big5 or many other encodings) in the source file
into the \uNNNN sequences that the compiler understands as Unicode characters.
  It is used as follows:
native2ascii -encoding GB2312 source.file dest.file
  At least on Windows95, it is important to capitalize GB2312 (or BIG5).

  The java.io package also supports the ability to read in documents
encoded in GB and convert it into Unicode on the way in.  Haven't worked
with this much yet though.

>If you need a GB->UTF-8 converter, look at the utf7 package (Unix)
>on ftp.ifcss.org.

  You can also check out my on-line GB/Big5->UTF-8 converter at
http://www.erols.com/eepeter/fileg2b.html
  You can specify a file name on your local computer and it will
return that file to the browser converted to UTF-8.  Conversion
to HZ is also supported.

>The Chinese may not display correctly on all platforms (only
>ISO 8859-1 display is supported in the initial implementations),
>though this should be fixed now.

  It is fixed in JDK1.1, but only in Canvas widgets using drawString
or drawChars.  Extended font support for TextComponent (TextArea and
TextField) has not yet been added to the Windows virtual machine.

>You may also be able to embed GB directly in "byte" or String variables,
>though this may not work very well.

  I've tried this also with some success, although the resultant
String is hard to manipulate and compare with other Strings.

>For common knowlege, see the JDK docs :-)

  Unfortunately, the JDK docs are still developing on this topic.

Erik Peterson
http://www.erols.com/eepeter/chtools.html


>Regards,
>Jake
>
>On Tue, 11 Mar 1997, Ji Zhang wrote:
>
>> Hi there,
>>
>> It is said that java accepts unicode for output.
>> Could unicode experts tell me what is the escape
>> code for access GB, what is the escape code for
>> exit GB ?  Is a code mapping needed from GB to
>> unicodes or simplely keep GB as it is ?
>>
>> Will it look like:
>>    \uhhhh \uhhhh \uhhhh \uhhhh \uhhhh \uhhhh ... \uhhhh
>>      ||                                            ||
>>     begin   gb     gb     gb     gb     gb   ...  exit
>> in java ?
>>
>> Regards,
>>
>> Ji Zhang <zhang@tappet.ime.nrc.ca>
>>
>> BTW, I do not want to "read" any docs at unicode.org.
>> I just want to know a bit commom knowledge.
>>
>
>

From owner-ccnet-l@UGA.CC.UGA.EDU Wed Apr  9 23:26:45 1997
Received: from listmail.cc.uga.edu (listmail.cc.uga.edu [128.192.232.10]) by ccic.fas.harvard.edu (8.6.11/8.6.11) with ESMTP id XAA16365 for <yjj@IFCSS.ORG>; Wed, 9 Apr 1997 23:26:41 -0400
Message-Id: <199704100326.XAA16365@ccic.fas.harvard.edu>
Received: from uga.cc.uga.edu by listmail.cc.uga.edu (LSMTP for Windows NT v1.0a) with SMTP id 53E98B20 ; Wed, 9 Apr 1997 23:18:26 -0400
Received: from UGA.CC.UGA.EDU (NJE origin LISTSERV@UGA) by UGA.CC.UGA.EDU (LMail V1.2c/1.8c) with BSMTP id 4481; Wed, 9 Apr 1997 23:18:01 -0400
Date:         Wed, 9 Apr 1997 23:18:18 -0400
Reply-To: Wei Wang <weiwang@MERIT.EDU>
Sender: Chinese Computing Network <CCNET-L@UGA.CC.UGA.EDU>
From: Wei Wang <weiwang@MERIT.EDU>
Subject:      Re: your mail
Comments: To: Neil Walker <NWalker@dynix.com.au>
To: Multiple recipients of list CCNET-L <CCNET-L@UGA.CC.UGA.EDU>
In-Reply-To:  <c=AU%a=_%p=Dynix_Australia_%l=CLAVEN-970410024115Z-800@claven.dynix.com.au>
Status: R

Here is the info I just dug out of the web (check
http://www.starglobe.com.sg/):

xMASS version 2.4 is a set of efficient and user-friendly software
tools that provides a multilingual environment for both end users
and application developers. It provides a multilingual input
server, a Unicode based text editor, a universal X-terminal
emulator and a comprehensive set of C language libraries that
contain APIs suitable for the development of mutilingual
applications. It can help to ease the development of multilingual
applications and will speed up software localization effort. It
can also be integrated as part of application modules to enhance
input methods and input environment for multiple natural
languages.

=2E.....

The xMASS version 2.4 offering consists of three components,
namely, MINE (Multilingual Input for Novice and Expert users),
MLedit (Multilingual editor) and UXterm (Universal X-terminal).

           ***    ***    ***

So my guess is that it does not turn a Unix system magically into
a "Chinese environment". I'm not saying that it is not good. In
fact, I was pretty impressed by the MASS demo back in 1993 or
1994. (It is not that I am really knowledgeable about things --
just that a friend of mine was on the MASS team at the National
University of Singapore.)

Regards,
--
Wei Wang    http://home.merit.edu/~weiwang/
~{=CD=F5=CE=B0~}    weiwang@merit.edu       (313) 764-2874

On Thu, 10 Apr 1997, Neil Walker wrote:

->I have heard of a product called MASS from Singapore. It has Unicode
->support in on XWindows. I am sure there must be more info on the Web.

From owner-ccnet-l@UGA.CC.UGA.EDU Wed Apr  9 23:27:16 1997
Received: from listmail.cc.uga.edu (listmail.cc.uga.edu [128.192.232.10]) by ccic.fas.harvard.edu (8.6.11/8.6.11) with ESMTP id XAA16386 for <yjj@IFCSS.ORG>; Wed, 9 Apr 1997 23:27:14 -0400
Message-Id: <199704100327.XAA16386@ccic.fas.harvard.edu>
Received: from uga.cc.uga.edu by listmail.cc.uga.edu (LSMTP for Windows NT v1.0a) with SMTP id 5FCA77B0 ; Wed, 9 Apr 1997 23:18:51 -0400
Received: from UGA.CC.UGA.EDU (NJE origin LISTSERV@UGA) by UGA.CC.UGA.EDU (LMail V1.2c/1.8c) with BSMTP id 4519; Wed, 9 Apr 1997 23:18:14 -0400
Date:         Thu, 10 Apr 1997 11:13:56 +0800
Reply-To: Jacob Morrison <Jacob.Morrison@CDC.COM>
Sender: Chinese Computing Network <CCNET-L@UGA.CC.UGA.EDU>
From: Jacob Morrison <Jacob.Morrison@CDC.COM>
Subject:      Re: your mail
Comments: To: Neil Walker <NWalker@DYNIX.COM.AU>
To: Multiple recipients of list CCNET-L <CCNET-L@UGA.CC.UGA.EDU>
In-Reply-To:  <334c53786877002@cdshub.cdc.com>
Status: R

On Thu, 10 Apr 1997, Neil Walker wrote:

> I have heard of a product called MASS from Singapore. It has Unicode
> support in on XWindows. I am sure there must be more info on the Web.

See http://www.starglobe.com.sg/
It also works on Windows.

Jake

From owner-ccnet-l@UGA.CC.UGA.EDU Sat Apr  5 01:48:49 1997
Received: from listmail.cc.uga.edu (listmail.cc.uga.edu [128.192.232.10]) by ccic.fas.harvard.edu (8.6.11/8.6.11) with ESMTP id BAA02470 for <yjj@IFCSS.ORG>; Sat, 5 Apr 1997 01:48:47 -0500
Message-Id: <199704050648.BAA02470@ccic.fas.harvard.edu>
Received: from uga.cc.uga.edu by listmail.cc.uga.edu (LSMTP for Windows NT v1.0a) with SMTP id 5B069610 ; Sat, 5 Apr 1997 1:40:34 -0500
Received: from UGA.CC.UGA.EDU (NJE origin LISTSERV@UGA) by UGA.CC.UGA.EDU (LMail V1.2c/1.8c) with BSMTP id 0603; Sat, 5 Apr 1997 01:39:17 -0500
Date:         Sat, 5 Apr 1997 08:38:50 +0000
Reply-To: Christian Wittern <cwitter@GWDG.DE>
Sender: Chinese Computing Network <CCNET-L@UGA.CC.UGA.EDU>
Comments:     Authenticated sender is <cwitter@popper.gwdg.de>
From: Christian Wittern <cwitter@GWDG.DE>
Subject:      Word97 and Unicode
To: Multiple recipients of list CCNET-L <CCNET-L@UGA.CC.UGA.EDU>
Status: RO

Dear Colleagues,

You might be aware of this, but it is completely new to me.

I recently had a look at Word 97. I played with (late beta Versions)
of the English and Chinese programs on English, Japanese and Chinese
Windows  95 as well as German Win NT 4.0.

The internal file format of Word 97 is now in Unicode. There seems to
be no difference in Fileformats between Western and East-Asian
versions. Now, finally it is not longer necessary to keep copies of
the program in two, three or four different languages and operating
systems, just to accomodate the need of processing multiple Asian
languages. It is now possible to create a file, say, on Japanese
Windows in English Word97  and open it in Chinese Windows and Chinese
Word 97 and the Characters will display correctly without the need of
any conversion! (Since the standard font names are different, there
might be a need to set up the font mapping for the Japanese to the
Chinese fonts - this is done once and forever).

Although the file format is Unicode, the CJK glyphs are still seen
through the limitations of the national encodings. This means that
Word 97 running on Chinese Windows will only display Characters from
Big5, Japanese Word only those from JIS; Characters outside of these
ranges are displayed as a 'missing glyph' question mark, but are not
in any way distorted, deleted or mixed up. This is still true even if
the font used contains all the 20000+ CJK glyphs from the Unicode
standard, like for example Bitstreams Cyberbit (free download from
http://www.bitstream.com). This situation only changes when Word 97 is
running on NT: With the proper font installed, it will happily display
all CJK glyphs thus finally, after *years* of pain, making it possible
to mix Asian and European text, with Sanskrit and whatever in one
document.  To some extend, this is even possible in English WIndows
95, where it is possible to install the fonts from the Internet
Explorer Language Pack (www.microsoft.com and all over the planet,
search for ie3lpktw.exe, ie3lpkcn.exe and so forth).

Even the English version of Word97, running in a CJK environment, now
is smart enough to register a switch of the Keyboard from alphabetical
to ideographic input and will adjust the font accordingly.

It seems the day finally has come where we can switch our
textprocessing to Unicode and forget about things like Big5, JIS, KSC
and the like to concentrate on the work we originally planned to do
with the help of a computer.

The next major problem seems to be a convenient input method, but with
Visual Basic lurking in the background, I think I can come up with
some provisional hack to solve this.

All the best,


Christian Wittern              Visit the Database of Chinese Buddhist texts
University of Goettingen       at http://www.gwdg.de/~cwitter

From owner-ccnet-l@UGA.CC.UGA.EDU Wed Apr 30 10:41:00 1997
Received: from listmail.cc.uga.edu (listmail.cc.uga.edu [128.192.232.10]) by ccic.fas.harvard.edu (8.6.11/8.6.11) with ESMTP id KAA14707 for <yjj@IFCSS.ORG>; Wed, 30 Apr 1997 10:40:52 -0400
Message-Id: <199704301440.KAA14707@ccic.fas.harvard.edu>
Received: from uga.cc.uga.edu by listmail.cc.uga.edu (LSMTP for Windows NT v1.1a) with SMTP id <0.BD3FACB0@listmail.cc.uga.edu>; Wed, 30 Apr 1997 10:32:01 -0400
Received: from UGA.CC.UGA.EDU (NJE origin LISTSERV@UGA) by UGA.CC.UGA.EDU (LMail V1.2c/1.8c) with BSMTP id 3837; Wed, 30 Apr 1997 10:31:25 -0400
Date:         Wed, 30 Apr 1997 22:30:42 +0800
Reply-To: Jacob Morrison <Jacob.Morrison@CDC.COM>
Sender: Chinese Computing Network <CCNET-L@UGA.CC.UGA.EDU>
From: Jacob Morrison <Jacob.Morrison@CDC.COM>
Subject:      Re: state of mime compliance
Comments: To: Simon Yeh <syeh@CSFCORP.COM>
To: Multiple recipients of list CCNET-L <CCNET-L@UGA.CC.UGA.EDU>
In-Reply-To:  <335e369645e0002@cdshub.cdc.com>
Status: R

Simon,

On Wed, 23 Apr 1997, Simon Yeh wrote:

> I wonder what is current state of MIME-compliance of Chinese capable
> MUA (mail user agent), both commercial and freeware? Such as what
> character sets, parameters (hints?), are supported. Can user customize
> these settings?

There is a Chinese version of pine, which is a solid UA for Unix, DOS,
and OS/2. I have seen a few localized Chinese Windows UAs, but they were
not all that full featured. MIME UAs generally have configurable character
set for messages going out, though most people have it set for ISO-8859-1
:-( I think the Chinese version of Netscape has menus in Chinese.

My company (Control Data) has localized our Windows UA for Chinese
(simplified and traditional), Korean and Japanese. I think it is
quite nice ;-)

>
> Has any product support or plan to support those encoding schemes
> (iso-2022-cn, iso-2022-cn-ext, cn-gb, cn-big5, cn-gb12345, cn-gb-isoir165)
> proposed by rfc1922?

There are two approaches: entering the data natively or converting the
data for transmission.

If your OS natively supports a particular encoding, you just enter the
data and give it the proper tag. Examples are cn-gb and cn-big5. MULE
(Multilingual EMACS) can work with ISO-2022-cn, and EMACS has a mail
interface, so I guess that counts.

>
> And, more curiously, what are the realities, instead of just a claim?
>

I am not sure that encodings other than cn-gb and cn-big5 (and
maybe ISO-2022-CN for interfacing with X.400) are really useful.
For average use in closed systems, this is just fine. For interchange,
I think Unicode is a better choice.

Having said that, I am planning to add support for them as in our
mail server system. I am already adding support for conversions between
GB 2312, Big5, CNS 11643, Unicode and ISO-2022-CN; adding additional
character set conversions is not a big deal.

I might add it to our UA as well, if there is a demand. The Japanese
version of Eudora already does this for ISO-2022-JP.

>
>
> --- Simon Yeh
>

Regards,
Jake

From owner-ccnet-l@UGA.CC.UGA.EDU Tue Jun 10 00:20:26 1997
Received: from listmail.cc.uga.edu (listmail.cc.uga.edu [128.192.232.10]) by ccic.fas.harvard.edu (8.6.11/8.6.11) with ESMTP id AAA23543 for <yjj@IFCSS.ORG>; Tue, 10 Jun 1997 00:20:25 -0400
Message-Id: <199706100420.AAA23543@ccic.fas.harvard.edu>
Received: from uga.cc.uga.edu by listmail.cc.uga.edu (LSMTP for Windows NT v1.1a) with SMTP id <0.DB882AC0@listmail.cc.uga.edu>; Tue, 10 Jun 1997 0:11:35 -0400
Received: from UGA.CC.UGA.EDU (NJE origin LISTSERV@UGA) by UGA.CC.UGA.EDU (LMail V1.2c/1.8c) with BSMTP id 8072; Tue, 10 Jun 1997 00:11:00 -0400
Date:         Tue, 10 Jun 1997 00:11:26 -0400
Reply-To: "Richard S. Cook" <rscook@WORLD.STD.COM>
Sender: Chinese Computing Network <CCNET-L@UGA.CC.UGA.EDU>
From: "Richard S. Cook" <rscook@WORLD.STD.COM>
Subject:      http://www.unicode.org/unihan/
Comments: To: CHINESE-MAC <CHINESE-MAC@YORKU.CA>,
          Kenyon Chinese Listserv <CHINESE@KENYON.EDU>
To: Multiple recipients of list CCNET-L <CCNET-L@UGA.CC.UGA.EDU>
Status: R

Hi All,
I'm posting this info because, well, it's just truly astonishing, and I
don't recall seeing mention of it here (perhaps because it's pretty new).
If you haven't seen it yet, check out:

<A HREF=http://www.unicode.org/unihan/>Unihan</A>

This data base, maintained by a person named Jenkins and hosted by Apple
Computer

<A HREF=http://www.blueneptune.com/~tseng>jenkins@apple.com</A>

has image maps for the whole Unicode 2.0 Chinese character set,
comparative encoding info on various schemes, and even dictionary
definitions, albeit, very terse.


_____________________________
Richard S. Cook
Somerville, Massachusetts USA
email:   rscook@world.std.com
http://world.std.com/~rscook/
>>>>>>>>>>>>>>*<<<<<<<<<<<<<<

From owner-ccnet-l@UGA.CC.UGA.EDU Thu Dec 18 07:23:56 1997
Received: from listmail.cc.uga.edu (listmail.cc.uga.edu [128.192.232.10]) by ccic.fas.harvard.edu (8.6.11/8.6.11) with ESMTP id HAA28203 for <yjj@IFCSS.ORG>; Thu, 18 Dec 1997 07:23:51 -0500
Message-Id: <199712181223.HAA28203@ccic.fas.harvard.edu>
Received: from uga.cc.uga.edu by listmail.cc.uga.edu (LSMTP for Windows NT v1.1a) with SMTP id <0.BE3B11A0@listmail.cc.uga.edu>; Thu, 18 Dec 1997 7:22:48 -0500
Received: from UGA.CC.UGA.EDU (NJE origin LISTSERV@UGA) by UGA.CC.UGA.EDU (LMail V1.2c/1.8c) with BSMTP id 4052; Thu, 18 Dec 1997 07:21:43 -0500
Date:         Thu, 18 Dec 1997 20:20:08 +0800
Reply-To: szingr <szingr@PUBLIC.SZPTT.NET.CN>
Sender: Chinese Computing Network <CCNET-L@UGA.CC.UGA.EDU>
From: szingr <szingr@PUBLIC.SZPTT.NET.CN>
Subject:      Re: new-line (Re:GB in unicode on NT)
Comments: To: Ji Zhang <zhang@TAPPET.IME.NRC.CA>
To: CCNET-L@UGA.CC.UGA.EDU
Status: R

FYI

/* FixCRLF takes a pointer to a wide character (Unicode) string and searches
*  for old-fashioned ASCII \n and \r characters and hammers them into Unicode
*  line and paragraph separator characters.
*/
void FixCRLF(wchar_t * ps)
{
        do {

                if (*ps == (wchar_t)'\n')       // translate linefeed to
                        *ps = 0x2028;           // Unicode line separator

                if (*ps == (wchar_t)'\r')       // translate carriage return to
                        *ps = 0x2029;           // Unicode paragraph separator

        }       while (*ps++ != (wchar_t)NULL);

}       // FixCRLF


----------
From:   Ji Zhang[SMTP:zhang@TAPPET.IME.NRC.CA]
Sent:   Wednesday, December 17, 1997 3:39 AM
To:     CCNET-L@UGA.CC.UGA.EDU
Subject:        Q: new-line (Re:GB in unicode on NT)

>        wchar_t         str[] = {0x8fd9, 0x662f};

Can str[] be a Chinese article ?
How to deal with new-lines or CRLFs ?
What are the values for CR LF in unicode ?
It seems I have to scan str[] one wchar by one wchar
and count the positions to draw an article.

Ji Zhang  <zhang@tappet.ime.nrc.ca>

From owner-ccnet-l@UGA.CC.UGA.EDU Thu Dec 18 10:24:21 1997
Received: from listmail.cc.uga.edu (listmail.cc.uga.edu [128.192.232.10]) by ccic.fas.harvard.edu (8.6.11/8.6.11) with ESMTP id KAA00303 for <yjj@IFCSS.ORG>; Thu, 18 Dec 1997 10:24:19 -0500
Message-Id: <199712181524.KAA00303@ccic.fas.harvard.edu>
Received: from uga.cc.uga.edu by listmail.cc.uga.edu (LSMTP for Windows NT v1.1a) with SMTP id <0.F6592EA0@listmail.cc.uga.edu>; Thu, 18 Dec 1997 10:23:20 -0500
Received: from UGA.CC.UGA.EDU (NJE origin LISTSERV@UGA) by UGA.CC.UGA.EDU (LMail V1.2c/1.8c) with BSMTP id 8027; Thu, 18 Dec 1997 10:22:14 -0500
Date:         Thu, 18 Dec 1997 10:26:44 -0500
Reply-To: Ji Zhang <zhang@TAPPET.IME.NRC.CA>
Sender: Chinese Computing Network <CCNET-L@UGA.CC.UGA.EDU>
From: Ji Zhang <zhang@TAPPET.IME.NRC.CA>
Subject:      Does TextOutW respond with 0x2028 or 0x2029
To: CCNET-L@UGA.CC.UGA.EDU
Status: R

Thanks to szingr <szingr@PUBLIC.SZPTT.NET.CN> for the
C function:

void FixCRLF(wchar_t * ps)
{
        do {

                if (*ps == (wchar_t)'\n')       // translate linefeed to
                        *ps = 0x2028;           // Unicode line separator

                if (*ps == (wchar_t)'\r')       // translate carriage return to
                        *ps = 0x2029;           // Unicode paragraph separator

        }       while (*ps++ != (wchar_t)NULL);

}       // FixCRLF

Does TextOutW respond with 0x2028 or 0x2029 and
to do moving cursor to first colomn of next line ?
It seems No !

BTW, How to rotate chinese char 90 deg or 180, 270 deg
before calling TextOutW(...) ? Does lfOrientation
 = 900 work on your NT ?

Or, can I take advantage of MS MFC to get the bitmap of a
Chinese char (MS IE Song TTF font), then I rotate
and draw bitmap myself ?

I need to draw few Chinese Chars for y = f (x) drawing.

Regards,

Ji Zhang <zhang@tappet.ime.nrc.ca>

(if you want 1998 Chinese Calendar with a graphic "tiger"
in PostScript, you can get from my workstation at URL:
   http://tappet.ime.nrc.ca:8001/1998_1.ps
I do not have a color PS printer, so that I am not sure
if there is any problem for printing. I viewed it by
xpsview, ghostview on unix and GSVIEW on PC, looked
good. Let me know, if you can print, then I would
up-load to ftp site. 1998_2.ps to 1998_8.ps can be
gotten from:
   http://www.cathay.net/Calendar/   Cat Hay Net WWW Site
   http://uwalpha.uwinnipeg.ca:8001/fhy/  Uwalpha WWW Site
   http://www.ifcss.org/ftp-pub/org/fhy/Calendar/ CCIC WWW Site
   ftp://ccic.ifcss.org/pub/org/fhy/Calendar/ CCIC ftp Site
   ftp://herb.biol.uregina.ca/pub/fhy/Calendar/  Herb ftp Site
)

Merry Xmas to ccnet subscribers.
   http://tappet.ime.nrc.ca:8001/music/  has few
   Xmas music in .mid format

Ji Zhang <zhang@tappet.ime.nrc.ca>

From owner-ccnet-l@UGA.CC.UGA.EDU Thu Dec 18 13:29:05 1997
Received: from listmail.cc.uga.edu (listmail.cc.uga.edu [128.192.232.10]) by ccic.fas.harvard.edu (8.6.11/8.6.11) with ESMTP id NAA03009 for <yjj@IFCSS.ORG>; Thu, 18 Dec 1997 13:29:04 -0500
Message-Id: <199712181829.NAA03009@ccic.fas.harvard.edu>
Received: from uga.cc.uga.edu by listmail.cc.uga.edu (LSMTP for Windows NT v1.1a) with SMTP id <0.C6D6B610@listmail.cc.uga.edu>; Thu, 18 Dec 1997 13:28:07 -0500
Received: from UGA.CC.UGA.EDU (NJE origin LISTSERV@UGA) by UGA.CC.UGA.EDU (LMail V1.2c/1.8c) with BSMTP id 0603; Thu, 18 Dec 1997 13:27:01 -0500
Date:         Thu, 18 Dec 1997 10:24:27 -0800
Reply-To: Jimmy Han <jhan@CISCO.COM>
Sender: Chinese Computing Network <CCNET-L@UGA.CC.UGA.EDU>
From: Jimmy Han <jhan@CISCO.COM>
Organization: Cisco Systems, Inc.
Subject:      Re: Does TextOutW respond with 0x2028 or 0x2029
Comments: To: Ji Zhang <zhang@TAPPET.IME.NRC.CA>
To: CCNET-L@UGA.CC.UGA.EDU
Status: R

I don't think TextOut will take care of control chars, even for ascii
chars. To rotate charaters, use lfEscapement.

-
Jimmy Han

Ji Zhang wrote:
> Does TextOutW respond with 0x2028 or 0x2029 and
> to do moving cursor to first colomn of next line ?
> It seems No !
>
> BTW, How to rotate chinese char 90 deg or 180, 270 deg
> before calling TextOutW(...) ? Does lfOrientation
>  = 900 work on your NT ?
>
> Or, can I take advantage of MS MFC to get the bitmap of a
> Chinese char (MS IE Song TTF font), then I rotate
> and draw bitmap myself ?
>
> I need to draw few Chinese Chars for y = f (x) drawing.
>
> Regards,
>
> Ji Zhang <zhang@tappet.ime.nrc.ca>
>

