From CCNET-L@uga.cc.uga.edu Fri Feb  1 12:15:56 1991
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.64/5.10) with SMTP id AA24724; Fri, 1 Feb 91 12:14:50 -0500
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 2958; Fri, 01 Feb 91 12:13:24 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 2930;
 Fri, 01 Feb 91 12:13:23 EST
Date:         Fri, 1 Feb 91 12:09:50 EST
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:      Encoding Schemes
Comments: To: CCMAN-L@UGA.BITNET, CCNET-L@UGA.BITNET
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
Status: RO

Hello, Friends:

      I am trying to survey those well established encoding/decoding
schemes in major operating systems.  I know the existence of tens
of self-written schemes, but now I am mostly interested on those official
ones which are supported by major operating systems.

      For example, UUENCODE is the official scheme for UNIX system.
Another scheme called BTOA/ATOB is also available on local machines
as "user-supported" software.  That's all.  But many people have
pointed out that these two schemes are only available on UNIX and
are not widely supported in other operating systems.

      There should be at least one similar schemes in every major
operating system, including VMS, MVS, MTS, etc.  BINARY <--> ASCII
conversion is a common needs for transmitting binary files via
E-mail.

      It is very much appreciated if you can find out what scheme your
system uses and let me know.  I need this information badly.

      Thank you in advance.

-- Ruopeng

From CCNET-L@uga.cc.uga.edu Sun Feb  3 19:50:17 1991
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.64/5.10) with SMTP id AA08106; Sun, 3 Feb 91 19:48:49 -0500
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 8160; Sun, 03 Feb 91 19:48:01 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 0438;
 Sun, 03 Feb 91 19:47:58 EST
Date:         Sun, 3 Feb 91 19:45:33 EST
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:      Chinese Text Broadcasting
Comments: To: CCMAN-L@UGA.BITNET, CCNET-L@UGA.BITNET
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
Status: RO

                     Chinese Text Broadcasting Via E-mail
                     ====================================

Purpose:  Establish a standard way for broadcasting Chinese text via
          E-mail.

Keywords:  Standardization,  Broadcasting.

Fundamental Choices:

   (1) Which Text Coding Scheme To Adopt --- Guo Biao or Big5?
       After extensive consultation and careful evaluation, I propose
       to use Guo Biao based software rather than Big5.
   (2) What Encoding Scheme To Adopt --- uuencode/uudecode, atob/btoa,
       or various other self-written schemes?
          It seems that uuencode/uudecode is one of the most popular
       schemes and is also supported in some major operating system
       like UNIX.  So I TENTATIVELY propose adopting uuencode/uudecode
       as the standard encoding scheme.
          (But this is not final choice.  Other options are still
       open.  I am not confident yet about this choice)

Interface and Device Drivers:

   (1) Basic Working Environment is assumed to be IBM PC compatibles.
       Then there is already a well established interface --- BYX.
       The screen driver and printer driver and other necessary
       facilities are provided in BYX.
          CC-DOS, Chinese Wordstar and any other Guo Biao based
       Chinese software should also provide a complete and independent
       interface on PC.  (This is true at least in theory.) So those
       who use any of these softwares don't have to switch to BYX.

   (2) Optional Working Environments:  These include X-Windows,
       Sun Stations, Macintosh, and even an ordinary VT220 terminal
       on VMS system.
          For each of these working environments, a complete
       interface including screen driver and printer driver
       needs to be written, if those do not exist by now.
       It requires a big amount of work.  It is not feasible,
       technically and financially, for us to write such device
       drivers.
          Fortunately, the majority (more than 80 percent) of
       the recipients in this proposed Chinese text network are
       expected to be PC-based people.  So we can simply go
       ahead to build the network and aim at PC based recipients
       at present.  We can gradually find ways for those who
       work in the "optional working environments".

Other Ways To Transmit Files:

   (1) FTP --- This is mainly available in Internet.
   (2) BITFTP --- This is a public service provide at a node at
               Princeton University.  This can partially process
               Internet's FTP for BITNET users.
   (3) BITNET Protocol --- There is a special protocol for transmitting
               binary files between BITNET users, (but not available
               for users not on BITNET).
   (4) PC to PC Connection through Telephone.

      There are two disadvantages with the above-mentioned methods.
   First, each of these facility is only available to a special
   category of computer users, not to everybody.  Second, they lack
   the capability of broadcasting.
      Based on these reasons, I strongly recommend to adopt an
   encoding/decoding scheme as our official scheme.  (Standardization)

Rupert Zhu
Dept of Combinatoric and Optimization
University of Waterloo
February 3, 1991
=====================================================================

From CCNET-L@uga.cc.uga.edu Mon Feb  4 13:26:22 1991
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.64/5.10) with SMTP id AA13398; Mon, 4 Feb 91 13:25:37 -0500
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 9719; Mon, 04 Feb 91 13:24:01 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 6655;
 Mon, 04 Feb 91 12:59:27 EST
Date:         Mon, 4 Feb 91 10:27:00 CST
Reply-To: "J. Ding" <B366JDX%UTARLVM1.BITNET@uga.cc.uga.edu>
Sender: Chinese Computing Network <CCNET-L%UGA.BITNET@uga.cc.uga.edu>
From: "J. Ding" <B366JDX%UTARLVM1.BITNET@uga.cc.uga.edu>
Subject:      Re: Chinese Text Broadcasting
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
In-Reply-To:  Your message of Sun, 3 Feb 91 19:45:33 EST
Status: RO

Re: message from Rupert

One fast way to standarize may be "offering it for free". :-)

Since you said that the basic environment is PC, you may just try to develop
a PC-based encode/decode program. And make the source code available in one
or more common used hi-level language(say, BASIC). You send out the source
code, the users will easily take care of the rest part.

The Hi-level source code could be used by any mainframe OS.

You may contact Yan Yongxin to see if it is possible to put his outdated
basic BYX package available for FTP. So those who merely uses the pacage
for reading news don't have to buy a very complete package. It is good
for his business too, he should know that. If this fails, try some other
domestic Gou-Biao based software. Again, if you have the free ware, you
get the "power" to standarize.
                                 --JD

From CCNET-L@uga.cc.uga.edu Mon Feb  4 14:40:27 1991
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.64/5.10) with SMTP id AA13839; Mon, 4 Feb 91 14:39:53 -0500
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 9971; Mon, 04 Feb 91 14:17:27 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 8899;
 Mon, 04 Feb 91 13:54:59 EST
Date:         Mon, 4 Feb 91 12:51:34 CST
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:      An Coding Method for Chinese "Han" Characters
Comments: To: CCNET-L@uga.cc.uga.edu
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
Status: RO

There is an interesting coding method called "Six-Digit Coding Method" for
Chinese "Han" characters.  The method is based on the shape of Han characters.
Interested readers may read the 'Communication of the ACM', May 1990 issue,
(vol. CACM-33, No.5, pp491-494), authored by J. Qiao, Y. Qiao and S. Qiao.


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

From CCNET-L@uga.cc.uga.edu Mon Feb  4 14:41:08 1991
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.64/5.10) with SMTP id AA13852; Mon, 4 Feb 91 14:40:38 -0500
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 0072; Mon, 04 Feb 91 14:23:54 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 9525;
 Mon, 04 Feb 91 14:09:22 EST
Date:         Mon, 4 Feb 91 11:08:08 -0800
Reply-To: Ed Lai <lai%APPLE.COM@uga.cc.uga.edu>
Sender: Chinese Computing Network <CCNET-L%UGA.BITNET@uga.cc.uga.edu>
From: Ed Lai <lai%APPLE.COM@uga.cc.uga.edu>
Subject:      Re: Chinese Text Broadcasting
Comments: To: CCNET-L@uga.cc.uga.edu
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
Status: RO

>   (1) Which Text Coding Scheme To Adopt --- Guo Biao or Big5?
>       After extensive consultation and careful evaluation, I propose
>       to use Guo Biao based software rather than Big5.
>   (2) What Encoding Scheme To Adopt --- uuencode/uudecode, atob/btoa,
>       or various other self-written schemes?
>          It seems that uuencode/uudecode is one of the most popular
>       schemes and is also supported in some major operating system
>       like UNIX.  So I TENTATIVELY propose adopting uuencode/uudecode
>       as the standard encoding scheme.
>          (But this is not final choice.  Other options are still
>       open.  I am not confident yet about this choice)

If we are using GB and then turn around to use uuencode, then it would be
very silly. GB was not designed as an internal code, rather it is meant to
be used as communication, as such it can be used directly. What is popularly
called GB, i.e. the one used in CCDOS is not GB but a modified GB, however it
can be trivally converted back and forth from pure GB. I have proposed that
pure GB be used as the communication, since then there are a number of other
proposals. These proposals differs in the detail but they all stick to the
principle of using pure GB as the communication code.

The advantage of using pure GB over uuencode or atob is that there is no
growth in size of text in the encoded form. But the real advantage is that
you no longer need to decode in batch mode and things can be decoded on the
fly, allowing for far more transparent processing.

/* 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 lai@apple.com Mon Feb  4 16:38:00 1991
Received: from apple.com by sirius.ctr.columbia.edu (5.64/5.10) with SMTP id AA14573; Mon, 4 Feb 91 16:37:44 -0500
Received: by apple.com (5.61/25-eef)
	id AA03638; Mon, 4 Feb 91 13:37:13 -0800
	for yjj@sirius.ctr.columbia.edu
Date: Mon, 4 Feb 91 13:37:13 -0800
From: Ed Lai <lai@apple.com>
Message-Id: <9102042137.AA03638@apple.com>
To: yjj@sirius.ctr.columbia.edu
Subject: Re: Chinese Text Broadcasting
Status: RO

I understand that since I was one of the first one to propose a solution.
Pure GB is 7 bit (and easily converted from CCDOS-GB by stripping off the
high bit) and in the printable ASCII range, so there is no problem sending
pure GB by e-mail. Such experiment has been peformred on the net and in
soc.culture.china long ago.

From CCNET-L@uga.cc.uga.edu Mon Feb  4 19:48:44 1991
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.64/5.10) with SMTP id AA15614; Mon, 4 Feb 91 19:48:15 -0500
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 1726; Mon, 04 Feb 91 19:44:19 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 1463;
 Mon, 04 Feb 91 19:44:14 EST
Date:         Mon, 4 Feb 91 19:42:43 EST
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:      Pure GB ?
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
Status: RO

Thanks to Ed Lai for providing information about the "pure Guo Biao"
coding.  But I am a little confused about the relation of this "pure
GB" with the well known GB coding.

In the Table of  Guo Biao (GB2312-80):  Each characters is coded
as two bytes of high order characters (the highest bit non-zero.
I examined the resulting text after editing with BYX editor,
the bytes are indeed high order ones.  It is the same case
with CC-DOS editing, I presume.

Now I have two questions:

(1) Where can I get a coding table for "pure GB"?
(2) Is there an existing program converting between pure GB and
    popular GB?  (If so, may I have a look at the source code?)

Thank you in advance.

-- Rupert

From CCNET-L@uga.cc.uga.edu Mon Feb  4 20:24:15 1991
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.64/5.10) with SMTP id AA15871; Mon, 4 Feb 91 20:23:48 -0500
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 1798; Mon, 04 Feb 91 20:22:41 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 1978;
 Mon, 04 Feb 91 20:22:38 EST
Date:         Mon, 4 Feb 91 19:21:49 CST
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:  A Coding Method for Chinese "Han" Characters
Comments: To: CCNET-L@uga.cc.uga.edu
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
Status: RO

>Is this the same thing as described in _The Stroke Encoding of Dictionary
>Consultation_?  If so, I advise against it.  Too cumbersome.

This method is obviously not a perfect approach.  The main shortcomings
are (Just my personal view. Maybe I am wrong, please comment).

(1) One must see or know the structure of a word, then can he/she code it.

(2) The different types of division patterns make the coding complex.

(3) Since it is based on the shape of the Han characters, for different
    Han-Zi font style,  there might be different codings. (To solve this
    problem, the authors simply chose the widely used Old Song style font
    to establish their coding system.)

However,  it does have some advantages over some other coding systems.

(1) One code for one character (although I guess that sometimes the designers
    must artificially enforce so,  because two characters with the similar
    shapes may have the same code.)

(2) Coding is based on the shape.  Because of the number of different
    Chinese dialects and the difficulties of pronouncing correctly,  this
    method is really a good approach, especially for printing workers
    or typists, etc.

In other words,  for such a rich and complex Chinese Han characters set,
we may not be able to find a simple coding method. There have to be some
tradeoffs.  Maybe there will be a "perfect" hybrid method.  Research must
be carried on.

--Jianxun Ding at TAMU

From CCNET-L@uga.cc.uga.edu Tue Feb  5 11:11:27 1991
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.64/5.10) with SMTP id AA19212; Tue, 5 Feb 91 11:10:24 -0500
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 3283; Tue, 05 Feb 91 11:09:27 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 6842;
 Tue, 05 Feb 91 11:06:42 EST
Date:         Tue, 5 Feb 91 09:04:22 MST
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:      Pure GB, encoding methods, and Six Digit method
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
In-Reply-To:  <9102050046.AA18871@kythera>
Status: RO

The popularly used 8-bit GB is Pure GB with the most significant bit
set on each byte.  One of the reason for setting the high bit on GB
text is to distinguish it from the other seven bit text in a document.

After "leaping without looking" and proposing a seven-bit encoding
scheme for transmission of Chinese, I have come to feel that Pure GB
is the way to go.  uuencode/uudecode is widely used, but they
occassionally have problems with certain characters (i.e. space).
btoa/atob seems to work quite well, but has the undesirable
side-effect, like uuencode, of making a larger file than the original.

Now all that needs to be done is find some sort of common agreement on
how to distinguish Pure GB from other 7-bit text when transmitting :-)

As for the Six Digit encoding method, I dabbled with it a bit.  It has
the advantage of a one to one mapping, but used by itself, it is a
little unwieldy and means another input method to be learned.

Has anyone contacted the authors to find out if they have done more
work on the input end of things?
-----------------------------------------------------------------------------
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 Feb  5 11:12:54 1991
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.64/5.10) with SMTP id AA19226; Tue, 5 Feb 91 11:12:03 -0500
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 3283; Tue, 05 Feb 91 11:09:27 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 6842;
 Tue, 05 Feb 91 11:06:42 EST
Date:         Tue, 5 Feb 91 09:04:22 MST
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:      Pure GB, encoding methods, and Six Digit method
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
In-Reply-To:  <9102050046.AA18871@kythera>
Status: RO

The popularly used 8-bit GB is Pure GB with the most significant bit
set on each byte.  One of the reason for setting the high bit on GB
text is to distinguish it from the other seven bit text in a document.

After "leaping without looking" and proposing a seven-bit encoding
scheme for transmission of Chinese, I have come to feel that Pure GB
is the way to go.  uuencode/uudecode is widely used, but they
occassionally have problems with certain characters (i.e. space).
btoa/atob seems to work quite well, but has the undesirable
side-effect, like uuencode, of making a larger file than the original.

Now all that needs to be done is find some sort of common agreement on
how to distinguish Pure GB from other 7-bit text when transmitting :-)

As for the Six Digit encoding method, I dabbled with it a bit.  It has
the advantage of a one to one mapping, but used by itself, it is a
little unwieldy and means another input method to be learned.

Has anyone contacted the authors to find out if they have done more
work on the input end of things?
-----------------------------------------------------------------------------
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 Wed Feb  6 12:03:47 1991
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.64/5.10) with SMTP id AA26525; Wed, 6 Feb 91 11:59:25 -0500
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 7352; Wed, 06 Feb 91 11:58:11 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 6120;
 Wed, 06 Feb 91 11:58:08 EST
Date:         Wed, 6 Feb 91 11:55:00 EST
Reply-To: Dorothy Day <DAY%IUBACS.BITNET@uga.cc.uga.edu>
Sender: Chinese Computing Network <CCNET-L%UGA.BITNET@uga.cc.uga.edu>
From: Dorothy Day <DAY%IUBACS.BITNET@uga.cc.uga.edu>
Subject:      UUencoding and XXencoding
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
Status: RO

This is the UUDECODE.DOC document from version 4.13 of Richard E. Mark's
UUencode/UUdecode programs, which also handle XXencoding as explained below.
The latest version I know of on Simtel (ftp WSMR-SIMTEL20.ARMY.MIL) is
UUEXE402.ZIP dated 900525 in the PD1:<MSDOS.FILUTL> directory. I believe it
includes all the features outlined below.
        ---Dorothy Day
-------------------------------------------------------------------------

UU-encoding is a way to code a file which may contain any characters into
a standard character set that can be reliably sent over diverse networks.


THE CHARACTER ENCODING:

The basic scheme is to break groups of 3 eight bit characters (24 bits) into
4 six bit characters and then add 32 (a space) to each six bit character
which maps it into the readily transmittable character.  Another way of
phrasing this is to say that the encoded 6 bit characters are mapped into
the set:
        `!"#$%&'()*+,-./012356789:;<=>?@ABC...XYZ[\]^_
for transmission over communications lines.

As some transmission mechanisms compress or remove spaces, spaces are changed
into back-quote characters (a 96).  (A better scheme might be to use a bias
of 33 so the space is not created, but this is not done.)

Another newer less popular encoding method, called XX-encoding uses the set:
        +-01..89ABC...XYZabc...xyz

In my opinion, XX-encoding is superior to UU-encoding because it uses more
"normal" characters that are less likely to get corrupted.  In fact several
of the special characters in the UU set do not get thru an EBCDIC to ASCII
translation correctly.  Conversely, an advantage of the UU set is that it does
not use lower case characters.  Now-a-days both upper and lower case are sent
with no problems; maybe in the communications dark ages, there was a problem
with lower case.

This "UU" encode/decode pair can handle either XX or UU encoding.  The encode
program defaults to creating a UU encoded file; but can be run with a "-x"
option to create an XX encoding.

The decode program defaults to autodetect.  However the program can get
confused by comment lines preceeding the actual encoded data.  The decode
mode can be forced to UU or XX with the "-u" or "-x" parameter.

Another option is for the actual map table to be inserted at the front of the
file.  The format for this is discussed later.  The table parameters are
detected and used by this decode program.  (A table will override the "-x" or
"-u" parameters.)  The encode program can be run with a "-t" option which
tells it to put the table into the encoded file.

A third encode mapping is the one used by Brad Templeton's ABE program.  This
is not handled by these programs as the check and control information
surrounding the actual encoded data is in a different form.


COMPOSING A LINE OF ENCODED CHARACTERS:

A small number of eight bit characters are encoded into a single line and a
count is put at the start of the line.  (Most lines in an encoded file have 45
encoded characters.  When you look at a UU-encoded file note that most lines
start with the letter "M".  "M" is decimal 77 which, minus the 32 bias, is 45.)

This encode program puts a check character at the end of each line.  The check
is the sum of all the encoded characters, before adding the mapping, modulo 64.

Note: Horton 9/1/87 UUENCODE has a bug in the line check algorithm; it uses the
sum of the original, not the encoded characters.  This decode program accepts
either form of line check character.

The line check characters are generated by default by this encode program.
However they can be supressed with the "-L" option.  One reason to supress
them is if they will be decoded by one of the old Horton decoders.  Most
decoders either accept this form of check or simply stop looking after the
line length is exhausted.  My feelings are mixed about the line level check
because errors of this type essentially never occur.  Furthermore file errors
will be detected by the CRC checks on the entire file (see below).
Opinions solicited.

The decode program checks the line level checksum by default.  Sometimes there
is junk at the end of the line which causes spurious line checksum errors.
To suppress checking of line checksums when decoding, use the "-L" option.

I have encountered various other ways that encoders end lines.  One encoder
put a "M" at both the start and end of the line.  Another used a line count
character.  This decode program checks all of these.  I would not be surprised
if some encoder out there ends lines with astrological symbols.  If you
encounter some other wierd form of encoded file, let me know.


PACKAGING THE LINES INTO FILES:

The lines of encoded data can be preceded by comments and by network addressing
information.  The encoded data is directly preceded by a line containing:

             begin <file-mode> <file-name>

This line is created by the encoding program.  The decode program scans the
file looking for "begin" in column 1.

The final end of encoded data is an encoded line with zero encoded characters
(a back-quote), followed by a line containing "end".

For integrity checking, various encode programs insert checksums for the
entire file.  This decode tries to check for all known types of file checksums.
This is discussed in more detail later.

This encode program puts a header line, containing the section number and
file name, in front of every section:

         "section <number> of uuencode of file <file name>"

At the end of a section the encode program inserts a line containing checksum
and file size information.  This can be suppressed with the "-c" option.

All the "integrity fields" (the checksum, the line check, and the section
header line) are inserted in a way that they will be ignored by other UUDECODE
programs that cannot handle them.  This decode program does not require any of
these fields; if not present, integrity checking is not done.  This program
pair is 100% downward compatible!


SPLITING UP LONG FILES:

Long files are broken into several sections before transmission.  This is
done because very large files are cumbersome to handle and because some
networks require files to be less than 64K bytes.

This encode program automatically breaks large encoded files into sections.
This split is controlled by several options.  First the "-s" option tells
encode not to split the file.  The "-s nnn" option tells encode to split the
file into hunks of "nnn" lines.  The default is 950 lines which is about 59k.
Sometimes extensive comments are put into the first file; thus it may be
necessary for the first file to contain fewer encoded lines.  The "-h nnn"
option tells encode to leave room for "nnn" additional lines in the first file.

If the data file being encoded is called FOO.ZIP, then the encode program
names the encoded files FOO1.UUE, FOO2.UUE, etc.

The decode program searches for the various sections, scans over preliminary
comments and decodes all as if they were one big file.  Decode is passed the
base file name "FOO".

Decode can (but rarely does) get confused and thinks header lines are encoded
data.  If so, edit the file and try again.  This has only happened once to me
and I have decoded a lot of files.

When decode encounters a premature end-of-file or some data which is not
decodable, it assumes the end of a file section.  decode is conservative when
it encounters data it cannot decode.

Usually this undecodable data is valid "trailer" data put at the end of file
for data transmission purposes.  However the file may be bad.  So decode
continues to scan the file, if decode then encounters a line which is decodable
it assumes the file is bad.  Or if there are more than 30 lines remaining in
the file, decode assumes the file is bad.

When decode encounters a valid end of file section it must get the next file
in sequence.  If the file name ends with a number, decode tries the next file
name in numeric sequence.  Otherwise decode asks for a file name.  If this
file does not contain decodable data, decode asks for another file to try.

The "SECTION" line inserted by the encode program is used for validity checking
only.  If not present, decode will accept any file containing encoded lines.


OTHER FILE FORMS:

Sometimes files come across in shell archives that automatically check
sequencing and call uudecode for you on the UNIX systems.  If you prefer to
download the raw files to MS-DOS, this decode program will filter thru simple
shell scripts and decode the data automatically.

There is one more rarely used feature of ENCODE: many input files can be
encoded into one large encode file.  (I have never seen this used.)  The end
of an input file is a zero length encoded line, followed by another "begin"
line instead of by an "end" line.  This decode program will decode this sort of
file; but the encode will only handle a single input file.


FILE LEVEL CHECKSUMS:

There are three types of file checksums found in encoded files:

       UUENCODE 2.14 and below inserted lines that gave the section
       size and the original input file size.  This is supplanted
       by a better technique in 3.07; but 3.07 UUDECODE still checks
       and validates the old form

       UUENCODE 3.07 and Rahul Dhesi''s encode scripts compute a Unix
       "sum -r" on the encoded sections and on the original input file.
       A difference is that UUENCODE 3.07 puts the expected "sum -r"
       and size at the end of a file while Rahul''s scripts put them at
       begining.  This UUDECODE analyzes either.

       The third form of checksum is a full 32 bit CRC that Rahul''s script
       inserts.  My code does not handle this.  Rahul has written the
       BRIK program to check them.  If there is a "sum -r" failure, BRIK
       analysis should be considered.


TABLE LINES:

Some encoded files but the mapping used at the front of the encoded file,
just in front of the "begin" line.  The format for this is:

                   table
                   first 32 characters
                   second 32 characters

All this starts in column 1.

If decode encounters a table specification, it uses it and overrides any
command line parameters.  Encode will create the table lines if run with
the "-t" parameter.


COMPLETION CODES:

On successful completion, UUDECODE sets ERRORLEVEL to 0.  If there are any
problems, ERRORLEVEL is set to non-zero.

Most of the options to UUDECODE are obvious.  However, the "-e" option needs
more explanation.  The purpose of "-e" is to automatically run an un-archiver
(like ZOO or PKUNPAK) when UUDECODE successfully completes.  If the "-e"
option is given, UUDECODE calls BAT file UNARCUUE on successful completion.
UNARCUUE is passed two parameters:

                the filename decoded (with no extension)
                the file extension.

Normally the file extension tells which un-archiver to call.  The UNARCUUE
BAT file, can test these parameters and call the necessary un-archiver.


This works well for me.  On UNIX I find a program I want in three sections:
              PRG1, PRG2, PRG3.
I copy the three files down to my PC as PRG1.UUE, PRG2.UUE, and PRG3.UUE.  I
then just enter UUDECODE PRG and the thing decodes.


Done privately and not for profit (freeware).  Suggestions appreciated.
The programs are written in Turbo Pascal 5.5 with about 5% TASM for speed.


Richard Marks
931 Sulgrave Lane
Bryn Mawr, PA 19010

From CCNET-L@uga.cc.uga.edu Thu Feb  7 01:44:58 1991
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.64/5.10) with SMTP id AA02135; Thu, 7 Feb 91 01:43:33 -0500
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 9181; Thu, 07 Feb 91 01:41:53 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 4236;
 Thu, 07 Feb 91 01:41:50 EST
Date:         Thu, 7 Feb 91 01:37:19 EST
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:      which one is more popular?
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
Status: RO

Hi, Friends:  Now we have to Guo Biao under consideration.  One is
the "pure GB", the other is "popular GB".

Pure GB uses ASCII 7-bit characters 33 to 127 inclusive.  Note that
ASCII 127 is a non-printable control character and has a chance to
corrupt during E-mail transmission.  When handling a mix of Chinese
text with English, some more control characters have to be put
in, therefore higher chance to be caught in trouble during transmission.

Another fundamental question is:  Which GB scheme is more widely
used in various Chinese wordprocessors and device drivers ?

For PC hardware, the popular GB scheme is prevailing.
On UNIX minicomputer, virtually none of the two GB is used.
I have no idea about the VMS machines, X-windows and MacIntosh
machines.  Can anyone shed some light for me?

I am trying to find some convincing reasons showing that direct
pure GB transmission is superior than the proposed "popular GB + uuencode"
transmission.  But so far, I have not been convinced.

-- Rupert

From CCNET-L@uga.cc.uga.edu Thu Feb  7 03:46:37 1991
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.64/5.10) with SMTP id AA02696; Thu, 7 Feb 91 03:46:11 -0500
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 9336; Thu, 07 Feb 91 03:46:00 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 5727;
 Thu, 07 Feb 91 03:45:54 EST
Date:         Thu, 7 Feb 91 01:42:54 MST
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: which one is more popular?
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
In-Reply-To:  <9102070705.AA28958@kythera>
Status: RO

Actually, pure GuoBiao is 33 to 126 for each byte.  This means 0x2121
through 0x7e7e is the range of pure GuoBiao and 0xa1a1 through 0xfefe
is the range of "popular" GuoBiao.

As I mentioned before, I think pure GuoBiao is the way to go, because
it consists of the "safe" characters to send by email.

So if pure GuoBiao is to be used as a transmission standard, there
needs to be some way of indicating which parts of a document are
supposed to be GuoBiao, and which parts are supposed to be ASCII.
This is where the problems start.

The Japanese use ^[$B (^[ == escape) to start a Kanji string and ^[(B
to end a Kanji string.  But as Ed Lai pointed out sometime earlier,
the escape character presents problems also.  There was a discussion
on sci.lang.japan on reconstructing text that had the escape
characters stripped, and there was no good solution presented.

In a Unix environment, there doesn't seem to be much of a problem
transmitting the escape character, but on Mac/PC based BBS's, and
other phone connection activities, it can be a problem.

The ^N (Shift Out) ^O (Shift In) sequences are used for Korean Hangul
N-byte text, but I don't know if it causes problems in transmission.
I suppose I should check on this.

Perhaps using "popular" GuoBiao with uuencode/xxencode/btoa would be a
handy temporary solution, but its not a "satisfying" solution :-)

Maybe a solution will be easier to arrive at when an international
standard character set (ISO/IEC DIS 10646 or Unicode) is introduced.
The ISO/IEC DIS 10646 draft mentions that there is an effort to make
one standard from a number of existing Chinese standards, including
GuoBiao.
-----------------------------------------------------------------------------
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 Thu Feb  7 03:48:06 1991
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.64/5.10) with SMTP id AA02701; Thu, 7 Feb 91 03:47:24 -0500
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 9336; Thu, 07 Feb 91 03:46:00 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 5727;
 Thu, 07 Feb 91 03:45:54 EST
Date:         Thu, 7 Feb 91 01:42:54 MST
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: which one is more popular?
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
In-Reply-To:  <9102070705.AA28958@kythera>
Status: RO

Actually, pure GuoBiao is 33 to 126 for each byte.  This means 0x2121
through 0x7e7e is the range of pure GuoBiao and 0xa1a1 through 0xfefe
is the range of "popular" GuoBiao.

As I mentioned before, I think pure GuoBiao is the way to go, because
it consists of the "safe" characters to send by email.

So if pure GuoBiao is to be used as a transmission standard, there
needs to be some way of indicating which parts of a document are
supposed to be GuoBiao, and which parts are supposed to be ASCII.
This is where the problems start.

The Japanese use ^[$B (^[ == escape) to start a Kanji string and ^[(B
to end a Kanji string.  But as Ed Lai pointed out sometime earlier,
the escape character presents problems also.  There was a discussion
on sci.lang.japan on reconstructing text that had the escape
characters stripped, and there was no good solution presented.

In a Unix environment, there doesn't seem to be much of a problem
transmitting the escape character, but on Mac/PC based BBS's, and
other phone connection activities, it can be a problem.

The ^N (Shift Out) ^O (Shift In) sequences are used for Korean Hangul
N-byte text, but I don't know if it causes problems in transmission.
I suppose I should check on this.

Perhaps using "popular" GuoBiao with uuencode/xxencode/btoa would be a
handy temporary solution, but its not a "satisfying" solution :-)

Maybe a solution will be easier to arrive at when an international
standard character set (ISO/IEC DIS 10646 or Unicode) is introduced.
The ISO/IEC DIS 10646 draft mentions that there is an effort to make
one standard from a number of existing Chinese standards, including
GuoBiao.
-----------------------------------------------------------------------------
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 Thu Feb  7 12:59:33 1991
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.64/5.10) with SMTP id AA04988; Thu, 7 Feb 91 12:57:51 -0500
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 0425; Thu, 07 Feb 91 12:34:44 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 4519;
 Thu, 07 Feb 91 12:34:41 EST
Date:         Thu, 7 Feb 91 12:33:32 -0500
Reply-To: 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:      Re: which one is more popular?
Comments: To: ccnet-l@uga.cc.uga.edu
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
In-Reply-To:  <9102070846.AA02381@leibniz.math.psu.edu>
Status: RO

Mark Leisher wrote:

> Actually, pure GuoBiao is 33 to 126 for each byte.  This means 0x2121
> through 0x7e7e is the range of pure GuoBiao and 0xa1a1 through 0xfefe
> is the range of "popular" GuoBiao.

> As I mentioned before, I think pure GuoBiao is the way to go, because
> it consists of the "safe" characters to send by email.

Well, not completely safe, because even some of the printable ASCII
characters (33 to 126) are not handled correctly in EBCDIC.  This
implies that your file can get corrupted if your mail path goes
through an IBM mainframe running VM.  Fortunately, Internet mail is
not usually gatewayed through IBM mainframes.

Mark's comments make a lot of sense to me.  The CCDOS format (i.e.
GuoBiao with both high bits set to 1, what Rupert Zhu has been calling
"popular GuoBiao") will not work at all because the mailers will strip
the high bits.  Even CCDOS + UUENCODE is not completely safe, again
because of the EBCDIC problem.  Also, as Ed Lai pointed out, a major
disadvantage of UUENCODE, ATOB, etc. is that the files cannot be
displayed or printed before decoding.

> So if pure GuoBiao is to be used as a transmission standard, there
> needs to be some way of indicating which parts of a document are
> supposed to be GuoBiao, and which parts are supposed to be ASCII.
> This is where the problems start.

This problem exists, but it can be solved.  The most elegant solution
I have seen was proposed and implemented by Fung Fung Lee, Ricky
Yeung, and others.  Namely, the HZ standard.  Roughly speaking, the
idea of HZ is to enclose 7-bit GuoBiao between brackets that look like
~{ and ~}.  Here the tilde ~ functions as an escape character.  In
this way, 7-bit GuoBiao can be mixed with ASCII.  The ASCII parts of
the file are immediately readable on any ASCII terminal.  The GuoBiao
parts are immediately readable (and printable) using any software that
understands GuoBiao.

Documentation and software implementing the HZ standard is available
for anonymous ftp on june.cs.washington.edu.  There are simple
utilities to print HZ files, display them on X-Windows, and convert
between HZ and other file formats (including CCDOS and BIG-5).

Mark, can you see any drawbacks to HZ as a proposed standard for
Chinese e-mail?  I see only two.

First, HZ files use all of the printable ASCII characters, hence are
not handled correctly by IBM mainframes using EBCDIC.  But, as I said
above, this problem is not really very severe.

Second, HZ is based on GuoBiao, hence can't transmit traditional
Chinese characters correctly.  For example, any GuoBiao-based
transmission standard will confuse the traditional characters Mian4
("face") and Mian4 ("noodle"), because they correspond to one and the
same simplified character.  This problem is serious, because most of
the international Chinese community uses traditional characters.

Perhaps what we really need is another transmission standard, similar
to HZ but based on BIG-5 instead of GuoBiao.  That way everybody could
be happy.  The files could be displayed or printed correctly in either
traditional or simplified characters.  This could be done without
decoding or conversion of any kind.  The only problem would be that,
in order to edit the files with a GuoBiao-based editor (such as Byx),
you would need conversion utilities.  But the needed utilities are
available on june.cs.washington.edu.

Comments?

From CCNET-L@uga.cc.uga.edu Thu Feb  7 13:20:17 1991
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.64/5.10) with SMTP id AA05108; Thu, 7 Feb 91 13:09:38 -0500
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 0540; Thu, 07 Feb 91 13:08:48 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 5906;
 Thu, 07 Feb 91 13:06:01 EST
Date:         Thu, 7 Feb 91 13:01:00 EST
Reply-To: yawei%UCS.INDIANA.EDU@uga.cc.uga.edu
Sender: Chinese Computing Network <CCNET-L%UGA.BITNET@uga.cc.uga.edu>
From: yawei%UCS.INDIANA.EDU@uga.cc.uga.edu
Subject:      Displaying pure GB text online
Comments: To: ccnet-l <ccnet-l@uga.cc.uga.edu>
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
Status: RO

After Ed Lai proposed to send Chinese text using pure GB codes during
the summer of 1989, I proposed to distinguish Chinese and English text
by adding the string 'zW' to the beginning of each line of the Chinese
texts. This scheme later came to be known as the 'zW' scheme and several
encoder/decoders for MacIntosh HZTalk, CCDOS on IBM PC, etc. were posted
to public networks (SCC), along with many sample files. Ed Lai and
Kwok Lai et al. had also put considerable effort into developing softwares
for converting between 'zW' and BIG-5 based systems.

Several other schmes were later proposed to distinguish Chinese
and ASCII texts. I admit that I like some of them better than 'zW',
since they permit intra-line mixing of texts. (Especially the HZ
scheme. Softwares written for 'zW' can in most cases be easily patched
to run HZ). The authors of those schemes are probably still on CCNET
so I'll let them speak for themselves.

Following is a program ZWWATCH I wrote around that time for displaying
'zW' coded text on-line. It is a TSR running under CCDOS on PCs,
which allows you to use compatible terminal emulator programs
to enter and read Chinese text on-line, just like you would with
English e-mails. I am posting this here as an incentive for
futher improvement -- I no longer have much time to spend on this
subject.

I had also started to develop another version of ZWWATCH which would
run indepedently of CCDOS, and got moderate success. Unfortunately,
the lack of suitable public domain fonts at the time, the losing
of some of my source codes in a hard disk crash, and my involvement
in China News Digest and other projects forced me to halt my efforts
on this project.

yawei
zWN:QG9p#
(The above line is my Chinese name, which you would be seeing now
if you are reading this message using zwwatch.)



From:   AQUA::YAWEI        "mr. yawei"  8-SEP-1989 23:25:17.46
Subj:   Real-time 'zW'-encoder/decoder for CC-DOS

Subject: Real-time 'zW'-encoder/decoder for CC-DOS

  This message contains the Assembler version of the 'zW'-decoder/
encoder for CC-DOS. It is a real-time encoder/decoder. (I'll post
the Assembler version of the file encoder/decoder in a later date.)


What Do You Mean By "Real-Time Encoder/Decoder"?

  The program, ZWWATCH.COM, works as a memory resident program. It
is to be loaded after CC-DOS. Once it is loaded, you can continue
to run other programs, such as terminal emulators, and any
Chinese input/output is automatically encode/decoded.
  ZWWATCH can be divided into 3 parts:
  (1) screen driver: any 'zW' data sent to the screen is immediately
decoded and displayed as Chinese characters;
  (2) printer driver: any 'zW' data sent to the printer is
automatically decoded and printed as Chinese characters;
  (3) keyboard driver: any Chinese character coming from the
keyboard is automatically converted into 'zW' format data.


What Can I Use ZWWATCH For?

  You can use it to view or print a 'zW' encoded file very
conveniently. For example, you can use the DOS TYPE command
to display a 'zW'-file and it will be displayed as Chinese.
Similarly, you can send a 'zW'-file to the printer and it
will be printed as Chinese.
  The most powerful way to use ZWWATCH, however, is to use it
with a terminal emulator that runs under CC-DOS. You can then
log into your mainframe account, read the 'zW'-formatted e-mail
directly, and reply to your mails directly in 'zW'-formatted
Chinese. Remember that 'zW' was primarily designed for Chinese
terminal emulators, with which you can exchange Chinese e-mail
and news just as you would with English mail/news. With ZWWATCH
we are very close to this goal.
  Actually, in some aspect, ZWWATCH may be even better than a
Chinese terminal emulator program, because it lets you exchange
Chinese mails while at the same time allows you to keep your
familiar terminal emulator, along with all its fancy features
such as file transfer protocols, etc.


How Can I Get a Copy of ZWWATCH?

  Very simple. At the end of this message you will find a BASIC
program (Oops! Another BASIC program!). Use an ASCII-compatible
editor to seperate it and save it under the name "zwwatch.bas",
and run it with BASICA or GWBASIC. ZWWATCH.COM will be generated
on your disk. (You can delete the BASIC program afterward.)
  ZWWATCH.COM is NOT a BASIC program. It was programmed in
Assembler. As an assembler program, its compactness in size
(it is only 1100 bytes!) and power is better than many C programs.


How do I Use ZWWATCH?

  1. Loading ZWWATCH.
  After CC-DOS and its printer driver has been loaded, you simply
type "ZWWATCH" to the DOS prompt to load it. After ZWWATCH is loaded
you are immediately returned to the DOS prompt, so that you can use
another DOS command or run another program.
  2. Reading a 'zW'-encoded file using ZWWATCH.
  You may simply use the DOS "TYPE" command to read a 'zW'-encoded
Chinese file.
  Note that the 'zW' line header is not removed by ZWWATCH. This
arrangement is intentional, so that you can tell a 'zW' file apart
from a normal CC-DOS file.
  3. Printing a 'zW'-encoded file using ZWWATCH.
  You may send the 'zW' file to the printer by "COPY filename PRN"
or other DOS commands. The file will be decoded and printed as
Chinese. The printed output does NOT contain the 'zW' line headers.
  Note that ZWWATCH only operates in the "terminal mode" of the
'zW' scheme. If this is not desirable, you'll need the file
decoding programs I posted earlier.
  4. Entering Chinese data in 'zW' format using ZWWATCH.
  ZWWATCH automatically converts all Chinese data you enter from the
keyboard into the 'zW' format. However, there's one thing you need
to specifically remember: if the first character of the current line
is not a Chinese character, you need to press Alt-Z (when the cursor
is in the first column) to force the current line into 'zW' mode.
  5. Inactivating/Reactivating ZWWATCH.
  When it is no longer desirable to have ZWWATCH active, you may
type "ZWWATCH off" to turn it off. You can later type "ZWWATCH ON"
to turn it back on.


Using Terminal Emulation Programs under ZWWATCH and CC-DOS

  Many English-oriented programs uses screen-output methods that
are not compatible with CC-DOS. Fortunately, there seem to be a
higher percentage of communication/terminal emulation programs
that run under CC-DOS.
  Generally, if a program runs under CC-DOS, it should have no
problem with ZWWATCH.
  The following text deals with how to get a terminal emulation
program to run under CC-DOS. Some of it applies to other programs
as well.
  1. A program must not write to the screen buffer directly.
  If the program gives you a choice (such as PROCOMM), you should
choose the screen write method to BIOS or DOS. If a program writes
to the screen directly and does not offer alternative choice of
screen write methods, there is no way to get it run under CC-DOS.
  2. A program must not access the video hardware directly.
  This is especially important as the program could foolishly
disrupt the graphic setup. Short of patching the program, there
may be one way out of this, if the program only access the video
hardware at 1 or a few occassions:  many versions of CC-DOS offers
a key to switch to ASCII mode. The programs are less likely to do
any damaged in the ASCII mode, therefore you can start the program
in ASCII mode and then switch to Chinese mode after the program is
safely started.
  3. Setting up the terminal specification properly in your main-
frame account.
  Most versions of CC-DOS have fewer than 25-line displays. You should
change the terminal page size immediately after you log into your
account, otherwise the text will scroll out of the screen before you
can read it.
  In VAX VMS, the command "set terminal /page=n" should change the
page size of the terminal. (Experiment with the value of n until
you find a proper value. The value is usually 9 for CGA systems and
16 for Hercules.) I don't have a simple procedure for changing
the page size in Unix.


Running Terminal Emulators under CC-DOS.

  The following is a collection of solutions for getting terminal
emulators to run under CC-DOS and therefore ZWWATCH. If you find
the information here incorrect, or if you have information for
terminal emulation programs not mentioned here, please notify me.
  1. PROCOMM.
  You need to change the screen write method to BIOS. The procedure:
Alt-S for setup, then find the "general setup" menu, you'll find
the "screen write method" entry.
  2. PROCOMM PLUS.
  Supposedly this program does not offer a choice of screen write
methods and always write to the screen directly. Therefore it
does not run under CC-DOS.
  3. Kermit.
  Should run on CGA systems, may have problem with Hercules. If you
have problem, switch CC-DOS to ASCII mode, run Kermit and open a
connection, then switch back to Chinese mode.
  Kermit seems to have problem with the VT-100 clear screen sequence.
If this is the case, change your terminal discription to a dumn
terminal. (In VMS, type "$set terminal /device=unknown".)
  4. PC-TALK III.
  Should run on CGA without modifications, may have problem with
Hercules. See "Kermit" for solution.
  5. Others.
  If you can get other communication/terminal emulation programs
to run under CC-DOS, send me a note at "yawei@iubacs.bitnet" or
"yawei@gold.bacs.indiana.edu".


Software License, Warranties, and Liabilities.

  This is a copyrighted software. However, you're granted a license
to use and copy it freely under the following conditions:
  (1) you do not modify, delete or omit any materials in the original
program and its documentation;
  (2) you do not sell it for profit;
  (3) you do not use it in a commercial or business setting or in
a way that is directly related to your salary-paying job;
  (4) you do not use it in a way that is contrary to the spirit
of achieving democracy in China;
  (5) you try to find some Chinese material that is of general
interest and spend the time to type it into a computer and post it
to SCC (or other public forum) in 'zW' format. It can be about
politics, society, Chinese word processing, etc. I would especially
like to see some articles on the different ways to input Chinese
data.
  If you would like to use this program for commercial, business,
or anti-democratic purposes, please get a license from me.
  This program does not carry any guarantee or warranty whatsoever.
The author will not be liable for any mental, physical or property
damage as a result of use, misuse, or abuse of this software.

yagui wei
zWN:QG9p#
yawei@iubacs.bitnet
yawei@gold.ucs.indiana.edu
1989.9.9
[Today's Mao's 13rd D-Day. May he rest in pieces.]

-----cut here and save as "zwwatch.bas"------------------------------
100 ' Program to generate ZWWATCH.COM
110 ' (c) Copyright by Yagui Wei 1989 (yawei@gold.ucs.indiana.edu)
120 ON ERROR GOTO 1170
130 RESTORE:READ T:FOR I = 1 TO T:READ N:X#=X#+N:NEXT I
140 READ TOT# :IF TOT#<>X# THEN 1170
150 CLS:LOCATE 12,5:PRINT "Now writing file standby please "
160 RESTORE
170 OPEN "R", #1,"ZWWATCH.COM",1
180 FIELD #1, 1 AS N$
190 READ N
200 FOR I = 1 TO N
210 READ N:LSET N$=CHR$(N):
220 PUT #1 :NEXT I:CLOSE
230 PRINT "ZWWATCH.COM CREATED * *":GOTO 1180
240 DATA  1175
250 DATA  233, 232, 3, 0, 0, 0, 0, 0, 0, 0, 0, 0
260 DATA  0, 0, 0, 0, 0, 0, 1, 80, 83, 81, 82, 180, 3
270 DATA  43, 219, 156, 46, 255, 30, 3, 1, 10, 210, 90, 89, 91
280 DATA  88, 195, 80, 83, 81, 82, 139, 202, 46, 198, 6, 15, 1
290 DATA  0, 128, 249, 0, 116, 63, 43, 219, 178, 0, 180, 2, 156
300 DATA  46, 255, 30, 3, 1, 180, 8, 156, 46, 255, 30, 3, 1
310 DATA  60, 122, 117, 39, 46, 198, 6, 15, 1, 1, 128, 249, 2
320 DATA  114, 28, 178, 1, 180, 2, 156, 46, 255, 30, 3, 1, 180
330 DATA  8, 156, 46, 255, 30, 3, 1, 60, 87, 117, 6, 46, 198
340 DATA  6, 15, 1, 2, 139, 209, 180, 2, 156, 46, 255, 30, 3
350 DATA  1, 90, 89, 91, 88, 195, 46, 128, 62, 18, 1, 0, 116
360 DATA  36, 128, 252, 10, 116, 36, 128, 252, 9, 116, 31, 61, 13
370 DATA  14, 116, 15, 61, 10, 14, 116, 10, 128, 252, 2, 117, 11
380 DATA  232, 125, 255, 235, 6, 46, 198, 6, 15, 1, 0, 46, 255
390 DATA  46, 3, 1, 60, 10, 117, 8, 46, 198, 6, 15, 1, 0
400 DATA  235, 239, 60, 13, 116, 244, 46, 128, 62, 15, 1, 2, 117
410 DATA  4, 12, 128, 235, 223, 60, 122, 117, 5, 232, 56, 255, 116
420 DATA  16, 46, 128, 62, 15, 1, 0, 117, 16, 46, 198, 6, 15
430 DATA  1, 255, 235, 198, 46, 198, 6, 15, 1, 1, 235, 190, 46
440 DATA  128, 62, 15, 1, 1, 117, 182, 60, 122, 116, 178, 46, 198
450 DATA  6, 15, 1, 255, 60, 87, 117, 168, 46, 198, 6, 15, 1
460 DATA  2, 46, 198, 6, 16, 1, 0, 235, 154, 0, 46, 128, 62
470 DATA  18, 1, 0, 116, 5, 128, 252, 0, 116, 8, 46, 255, 46
480 DATA  11, 1, 180, 6, 207, 60, 10, 117, 8, 46, 198, 6, 25
490 DATA  2, 0, 235, 236, 60, 13, 116, 244, 46, 128, 62, 25, 2
500 DATA  2, 117, 4, 12, 128, 235, 220, 46, 128, 62, 25, 2, 0
510 DATA  117, 20, 60, 122, 116, 8, 46, 198, 6, 25, 2, 255, 235
520 DATA  200, 46, 198, 6, 25, 2, 1, 235, 197, 46, 128, 62, 25
530 DATA  2, 1, 117, 31, 60, 87, 116, 19, 46, 198, 6, 25, 2
540 DATA  255, 80, 184, 122, 0, 156, 46, 255, 30, 11, 1, 88, 235
550 DATA  161, 46, 198, 6, 25, 2, 2, 235, 158, 235, 151, 0, 0
560 DATA  0, 49, 0, 61, 87, 122, 117, 4, 184, 122, 87, 207, 61
570 DATA  88, 122, 117, 7, 46, 198, 6, 18, 1, 1, 207, 61, 89
580 DATA  122, 117, 7, 46, 198, 6, 18, 1, 0, 207, 46, 128, 62
590 DATA  18, 1, 0, 116, 54, 80, 30, 43, 192, 142, 216, 14, 88
600 DATA  57, 6, 66, 0, 116, 33, 46, 161, 5, 1, 59, 6, 66
610 DATA  0, 117, 23, 46, 161, 3, 1, 59, 6, 64, 0, 117, 13
620 DATA  250, 141, 6, 135, 1, 163, 64, 0, 140, 14, 66, 0, 251
630 DATA  31, 88, 128, 252, 1, 118, 5, 46, 255, 46, 7, 1, 114
640 DATA  39, 46, 128, 62, 144, 2, 0, 116, 241, 46, 128, 62, 144
650 DATA  2, 1, 117, 6, 184, 87, 0, 235, 13, 144, 46, 128, 62
660 DATA  144, 2, 2, 117, 219, 46, 161, 145, 2, 11, 192, 202, 2
670 DATA  0, 46, 128, 62, 144, 2, 1, 114, 23, 119, 10, 184, 87
680 DATA  0, 46, 198, 6, 144, 2, 2, 207, 46, 161, 145, 2, 46
690 DATA  198, 6, 144, 2, 0, 207, 156, 46, 255, 30, 7, 1, 61
700 DATA  0, 44, 117, 22, 232, 196, 253, 117, 17, 184, 122, 0, 46
710 DATA  199, 6, 145, 2, 87, 0, 46, 198, 6, 144, 2, 2, 207
720 DATA  168, 128, 117, 92, 46, 128, 62, 15, 1, 2, 117, 122, 60
730 DATA  9, 117, 3, 184, 32, 0, 60, 13, 144, 144, 116, 11, 60
740 DATA  32, 114, 105, 119, 5, 184, 33, 0, 235, 32, 60, 39, 117
750 DATA  5, 184, 47, 0, 235, 23, 60, 96, 117, 5, 184, 46, 0
760 DATA  235, 14, 60, 34, 117, 24, 46, 131, 54, 147, 2, 1, 46
770 DATA  161, 147, 2, 46, 163, 145, 2, 46, 198, 6, 144, 2, 2
780 DATA  184, 33, 0, 207, 46, 163, 145, 2, 46, 198, 6, 144, 2
790 DATA  2, 184, 35, 0, 207, 36, 127, 46, 128, 62, 15, 1, 0
800 DATA  117, 28, 46, 128, 62, 16, 1, 0, 117, 20, 46, 198, 6
810 DATA  144, 2, 1, 46, 163, 145, 2, 184, 122, 0, 46, 198, 6
820 DATA  16, 1, 1, 207, 207, 90, 87, 87, 65, 84, 67, 72, 32
830 DATA  40, 67, 41, 32, 67, 111, 112, 121, 114, 105, 103, 104, 116
840 DATA  32, 89, 97, 103, 117, 105, 32, 87, 101, 105, 32, 49, 57
850 DATA  56, 57, 46, 32, 65, 108, 108, 32, 114, 105, 103, 104, 116
860 DATA  115, 32, 114, 101, 115, 101, 114, 118, 101, 100, 46, 10, 13
870 DATA  82, 101, 97, 108, 45, 116, 105, 109, 101, 32, 39, 122, 87
880 DATA  39, 45, 101, 110, 99, 111, 100, 101, 114, 47, 100, 101, 99
890 DATA  111, 100, 101, 114, 32, 102, 111, 114, 32, 67, 67, 45, 68
900 DATA  79, 83, 46, 10, 13, 122, 87, 33, 48, 35, 122, 35, 87
910 DATA  33, 49, 35, 45, 86, 80, 78, 68, 35, 45, 35, 65, 35
920 DATA  83, 35, 67, 35, 73, 35, 73, 35, 45, 49, 96, 66, 107
930 DATA  35, 45, 77, 81, 66, 107, 51, 76, 80, 114, 35, 46, 10
940 DATA  13, 122, 87, 87, 119, 85, 95, 35, 58, 78, 58, 81, 71
950 DATA  57, 112, 35, 46, 87, 119, 85, 95, 49, 35, 65, 116, 82
960 DATA  59, 71, 80, 48, 102, 72, 40, 35, 46, 10, 13, 0, 85
970 DATA  110, 107, 110, 111, 119, 110, 32, 112, 97, 114, 97, 109, 101
980 DATA  116, 101, 114, 32, 115, 112, 101, 99, 105, 102, 105, 101, 100
990 DATA  46, 32, 36, 90, 87, 84, 69, 82, 77, 32, 105, 115, 32
1000 DATA  110, 111, 119, 32, 111, 110, 46, 32, 36, 90, 87, 84, 69
1010 DATA  82, 77, 32, 105, 115, 32, 110, 111, 119, 32, 111, 102, 102
1020 DATA  46, 32, 36, 190, 129, 0, 172, 60, 32, 116, 251, 60, 13
1030 DATA  116, 62, 36, 223, 60, 79, 117, 48, 172, 36, 223, 60, 78
1040 DATA  117, 16, 184, 88, 122, 205, 22, 141, 22, 196, 4, 180, 9
1050 DATA  205, 33, 235, 34, 144, 60, 70, 117, 21, 184, 89, 122, 205
1060 DATA  22, 198, 6, 18, 1, 0, 141, 22, 215, 4, 180, 9, 205
1070 DATA  33, 235, 9, 144, 141, 22, 166, 4, 180, 9, 205, 33, 184
1080 DATA  87, 122, 205, 22, 61, 122, 87, 117, 2, 205, 32, 184, 16
1090 DATA  53, 205, 33, 137, 30, 3, 1, 140, 6, 5, 1, 186, 135
1100 DATA  1, 184, 16, 37, 205, 33, 184, 22, 53, 205, 33, 137, 30
1110 DATA  7, 1, 140, 6, 9, 1, 186, 149, 2, 184, 22, 37, 205
1120 DATA  33, 184, 23, 53, 205, 33, 137, 30, 11, 1, 140, 6, 13
1130 DATA  1, 186, 26, 2, 184, 23, 37, 205, 33, 141, 54, 233, 3
1140 DATA  172, 10, 192, 116, 8, 138, 208, 180, 2, 205, 33, 235, 243
1150 DATA  141, 22, 233, 3, 205, 39
1160 DATA  95437
1170 PRINT "* * ERROR VERIFY DATA * * * "
1180 CLOSE : END

From CCNET-L@uga.cc.uga.edu Thu Feb  7 13:21:22 1991
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.64/5.10) with SMTP id AA05150; Thu, 7 Feb 91 13:20:05 -0500
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 0551; Thu, 07 Feb 91 13:09:50 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 6039;
 Thu, 07 Feb 91 13:08:17 EST
Date:         Thu, 7 Feb 91 13:07:00 EST
Reply-To: yawei%UCS.INDIANA.EDU@uga.cc.uga.edu
Sender: Chinese Computing Network <CCNET-L%UGA.BITNET@uga.cc.uga.edu>
From: yawei%UCS.INDIANA.EDU@uga.cc.uga.edu
Subject:      Chinese Prisoner Name List
Comments: To: ccnet-l <ccnet-l@uga.cc.uga.edu>
Comments: cc: rzhu <rzhu@watmath.waterloo.edu>
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
Status: RO

Following is a list of Chinese names of Chinese political
prisoners compiled by Ed Lai (lai@apple.com) around the
end of 1989.

The text is in 'zW' format.

zW#A#i# #Q#i#l#o#n#g# 0,FtAz#
zW#B#a#i# #D#o#n#g#p#i#n#g# 0W6+F=#
zW#B#a#i# #N#a#n#f#e#n#g# 0WDO7g#
zW#B#a#n# #H#u#i#j#i#e# 0`;a=\#
zW#B#a#o# #T#o#n#g# 1+M.#
zW#B#a#o# #Z#u#n#x#i#n# 0|WqPE#
zW#B#i#a#n# #H#a#n#w#u# 1e::Nd#
zW#C#a#o# #S#i#y#u#a#n# 2\K<T4#
zW#C#a#o# #W#e#i#g#u#o# 2\N@9z#
zW#C#h#a#i# #L#i#n#g# 2qAa#
zW#C#h#e# #H#o#n#g#n#i#a#n# 35:jDj#
zW#C#h#e#n# #H#o#n#g#g#e#n# 3B:j8y#
zW#C#h#e#n# #J#i#a#n# 3B<a#
zW#C#h#e#n# #P#e#i#s#i# 3BEeK9#
zW#C#h#e#n# #S#h#e#n#g#f#u# 3BJ"8##
zW#C#h#e#n# #X#u#e#d#o#n#g# 3BQ'6+#
zW#C#h#e#n# #Y#i#z#i# 3BR;ZQ#
zW#C#h#e#n# #Z#i#m#i#n#g# 3BWSCw#
zW#C#h#e#n#g# #M#i#n#g#y#u#a#n# 3LCwT6#
zW#C#u#i# #J#i#a#n#c#h#a#n#g# 4^=!2}#
zW#D#a#i# #Q#i#n#g# 4wGg#
zW#D#a#i# #Z#h#o#n#g# 4wVR#
zW#F#a#n#g# #K#e# 7=?K#
zW#F#e#n#g# #C#o#n#g#d#e# 7b4S5B#
zW#F#e#n#g# #J#i#n# 7k=x#
zW#G#a#o# #J#i#n#t#a#n#g# 8_=uLC#
zW#G#a#o# #S#h#a#n# 8_I=#
zW#G#a#o# #X#i#a#o#s#h#i# 8_O~J+#
zW#G#a#o# #Y#u# 8_h$#
zW#G#e# #Y#a#n#g# 8jQo#
zW#G#o#n#g# #C#h#u#a#n#c#h#a#n#g# 9(4+2}#
zW#G#u#o# #H#a#i#f#e#n#g# 9y:#7e#
zW#G#u#o# #W#e#n#s#h#e#n# 9yNDIn#
zW#H#a#o# #J#i#n#g#g#u#a#n#g# :B>"9b#
zW#H#e# #Q#u#n#y#i#n#g# :NH:S"#
zW#H#e# #Z#h#a#o#h#u#i# :N3/;T#
zW#H#u# #J#i#w#e#i# :z<(N0#
zW#H#u# #L#i#a#n#g#b#i#n#g# :zA<1x#
zW#H#u#a#n#g# #D#e#b#e#i# ;F5B11#
zW#J#i#n# #T#a#o# =pLN#
zW#L#a#o# #M#u# @OD>#
zW#L#i# #H#o#n#g#l#i#n# @n:iAV#
zW#L#i# #J#i#a#n# @nhE#
zW#L#i# #J#i#a#n#g# @n=-#
zW#L#i# #L#u# @nB;#
zW#L#i# #T#a#o# @nLN#
zW#L#i# #W#e#i#d#o#n#g# @nN@6+#
zW#L#i# #W#e#i#g#u#o# @nN@9z#
zW#L#i# #X#i#a#o#h#u# @nP!;"#
zW#L#i# #X#i#u#p#i#n#g# @nPcF<#
zW#L#i# #Z#h#i#g#u#o# @nVN9z#
zW#L#i#a#n# #Z#h#e#n#g#g#u#o# A.U~9z#
zW#L#i#a#n#g# #Q#i#a#n#g# A:G?#
zW#L#i#n# #S#h#a#o#r#o#n#g# AVUQHY#
zW#L#i#u# #C#o#n#g#s#h#u# Au4TJi#
zW#L#i#u# #F#u#'#a#n# Au8#02#
zW#L#i#u# #G#a#n#g# Au8U#
zW#L#i#u# #H#u#a#n#w#e#n# Au;@ND#
zW#L#i#u# #J#i#a#n# Au=!#
zW#L#i#u# #Q#i#a#n#g# AuG?#
zW#L#i#u# #W#e#i#d#o#n#g# AuN@6+#
zW#L#i#u# #X#i#a#o#b#o# AuO~2(#
zW#L#i#u# #X#i#a#o#l#o#n#g# AuO~Az#
zW#L#i#u# #X#i#n#g#q#i# AxPGFZ#
zW#L#i#u# #Y#u#b#i#n# AuSq1u#
zW#L#u# #D#e#c#h#e#n#g# B,5B3I#
zW#L#u# #Z#h#a#i#x#i#n#g# B,U*PG#
zW#L#u# #Z#h#e#n#g#q#i#n#g# B,U}Ge#
zW#L#u# #Z#h#o#n#g#s#h#u# B7VPJ`#
zW#L#u#a#n# #J#i#k#u#i# ho<*?|#
zW#L#u#o# #H#o#n#g#j#u#n# B^:l>|#
zW#M#a# #H#o#n#g#l#i#a#n#g# Bm:jA<#
zW#M#a# #S#h#a#o#f#a#n#g# BmIY7=#
zW#M#e#n#g# #D#u#o# CO6`#
zW#O#u# #Z#o#n#g#y#o#u# E7WZSS#
zW#P#a#n# #Q#i#a#n#g# EKG?#
zW#P#a#n#g# #Z#i#b#i#n# ESWS1s#
zW#P#e#n#g# #J#i#a#m#i#n# Em<RCq#
zW#Q#i#a#n# #R#o#n#g#m#i#a#n# G.HYCc#
zW#Q#i#n# #B#e#n#l#i# GU1>A"#
zW#Q#i#n#g# #W#e#i#d#o#n#g# #(#Q#i#n#?#)# GXN*6+#
zW#Q#i#u# #L#i#n# Gqwk#
zW#Q#u# #Z#u#o#j#i#e# GzWw=\#
zW#R#e#n# #W#a#n#d#i#n#g# HNn5n.#
zW#S#h#a#o# #L#i#a#n#g#c#h#e#n# I[A<3<#
zW#S#h#a#o# #Y#a#n#x#i#a#n#g# I[Q`Oi#
zW#S#h#e#n# #J#i#z#h#o#n#g# Ir<LVP#
zW#S#u# #S#h#a#o#z#h#i# KUI\VG#
zW#S#u# #X#i#a#o#k#a#n#g# KUO~?5#
zW#S#u#n# #J#i#h#o#n#g# Ko<L:l#
zW#S#u#n# #L#u# KoB7#
zW#S#u#n# #Y#a#n#c#a#i# KoQe2F#
zW#T#a#n#g# #J#i#a#n#z#h#o#n#g# LF<aVR#
zW#W#a#n# #R#u#n#n#a#n# MrHsDO#
zW#W#a#n#g# #C#h#a#n#g#'#a#n# Mu3$02#
zW#W#a#n#g# #C#h#a#n#g#h#o#n#g# Mu3$:i#
zW#W#a#n#g# #C#h#a#o#h#u#a# Mu3,;*#
zW#W#a#n#g# #D#a#n# Mu5$#
zW#W#a#n#g# #G#u#i#y#u#a#n# Mu9sQt#
zW#W#a#n#g# #H#a#n#w#u# Mu::Nd#
zW#W#a#n#g# #H#o#n#g# Mu:g#
zW#W#a#n#g# #J#i#a#n#j#u#n# Mu=(>|#
zW#W#a#n#g# #J#u#n#t#a#o# Mu>|LN#
zW#W#a#n#g# #L#i#a#n#x#i# MuA,O2#
zW#W#a#n#g# #M#i#a#o#g#e#n# MuCn8y#
zW#W#a#n#g# #P#e#i#g#o#n#g# MuE`9+#
zW#W#a#n#g# #R#u#o#s#h#u#i# MuHtK.#
zW#W#a#n#g# #R#u#o#w#a#n#g# MuHtM{#
zW#W#a#n#g# #W#e#i#l#i#n# MuN,AV#
zW#W#a#n#g# #Y#o#u#c#a#i# MuSP2E#
zW#W#a#n#g# #Z#h#e#n#g#y#u#n# MuU}TF#
zW#W#a#n#g# #Z#h#i#x#i#n# MuVNPB#
zW#W#e#i# #Y#i#n#g#c#h#u#n# N$S-4:#
zW#W#e#n#g# #Z#h#e#n#g#m#i#n#g# NLU}Cw#
zW#W#u# #J#i#d#o#n#g# Nb<L6+#
zW#W#u# #R#a#n#y#u#a#n# Nb\[fB#
zW#W#u# #Z#h#i#j#u#n# NbV>>|#
zW#W#u#e#r# #k#a#i#x#i# Na6{?*O##
zW#X#i#a# #K#a#i# OD?-#
zW#X#i#a#o# #B#i#n#g# #(#B#i#n#?#)# Ot1s#
zW#X#i#o#n#g# #D#a#y#o#n#g# P\4sSB#
zW#X#i#o#n#g# #W#E#I# P\l?#
zW#X#i#o#n#g# #Y#a#n# P\lM#
zW#X#u# #G#u#o#m#i#n#g# Pl9zCw#
zW#X#u# #X#i#a#o#w#e#i# PmP!^1#
zW#Y#a#n# #J#i#a#q#i# QO<RFd#
zW#Y#a#n# #X#u#e#r#o#n#g# QOQ)HY#
zW#Y#a#n#g# #G#e#c#h#u#a#n#g# Qn8o43#
zW#Y#a#n#g# #G#u#a#n#s#a#n# Qn9ZH}#
zW#Y#a#n#g# #T#a#o# QnLN#
zW#Y#a#n#g# #W#e#i# QnaM#
zW#Y#a#n#g# #X#i#a#o#'#a#o# QnP!0=#
zW#Y#a#n#g# #X#i#o#n#g# QnP[#
zW#Y#a#n#g# #Z#h#i#w#e#i# QnV>N0#
zW#Y#a#o# #Y#o#n#g#z#h#a#n# R&SBU=#
zW#Y#e# #W#e#n#f#u# R6ND8##
zW#Y#o#u# #D#i#a#n#q#i# SH5gFd#
zW#Y#u# #D#o#n#g#y#u#e# S`6+T@#
zW#Y#u# #G#u#a#n#g#y#u#a#n# SZ9bT6#
zW#Y#u# #H#a#o#c#h#e#n#g# SZ:F3I#
zW#Y#u# #Y#u#n#g#a#n#g# SZTF8U#
zW#Y#u# #Z#h#e#n#b#i#n# S`Uq1s#
zW#Y#u# #Z#h#i#j#i#a#n# SZV><a#
zW#Y#u#a#n# #Z#h#i#m#i#n# T,VGCw#
zW#Y#u#a#n# #Z#h#i#m#i#n#g# T6V>Cw#
zW#Y#u#a#n# #Z#h#i#q#i#a#n#g# T,V>G?#
zW#Z#h#a#i# #W#e#i#m#i#n# 5TN*Cq#
zW#Z#h#a#n# #X#i#n#g#h#u# U9PK;"#
zW#Z#h#a#n#g# #B#o#l#i# UE2.sR#
zW#Z#h#a#n#g# #J#i#a#n#z#h#o#n#g# UE=(VR#
zW#Z#h#a#n#g# #L#i#n# UEAV#
zW#Z#h#a#n#g# #M#i#n#g# UECz#
zW#Z#h#a#n#g# #S#h#a#o#y#i#n#g# UEIYS"#
zW#Z#h#a#n#g# #S#h#e#n#g#m#i#n#g# UEIyCw#
zW#Z#h#a#n#g# #W#e#i#g#u#o# UEN09z#
zW#Z#h#a#n#g# #W#e#i#p#i#n#g# UEN0F=#
zW#Z#h#a#n#g# #W#e#n#k#u#i# UEND?|#
zW#Z#h#a#n#g# #X#i#a#n#y#a#n#g# UEOTQo#
zW#Z#h#a#n#g# #X#i#n#c#h#a#o# UEPB31#
zW#Z#h#a#n#g# #X#u#d#o#n#g# UEPq6+#
zW#Z#h#a#n#g# #Y#i# UERf#
zW#Z#h#a#n#g# #S#h#u# UEJc#
zW#Z#h#a#n#g# #Z#h#i#q#i#n#g# UEV>Ge#
zW#Z#h#a#o# #J#i#a#n#m#i#n#g# UT=(Cw#
zW#Z#h#a#o# #Y#i#q#i#a#n#g# UTR;G?#
zW#Z#h#a#o# #Y#u#e#t#a#n#g# UTT>LC#
zW#Z#h#e#n#g# #X#u#g#u#a#n#g# V#Pq9b#
zW#Z#h#e#n#g# #Y#i# V#Re#
zW#Z#h#o#u# #D#u#o# V\6f#
zW#Z#h#o#u# #F#e#n#g#s#u#o# V\7fKx#
zW#Z#h#o#u# #Y#a#n# # V\Qe#
zW#Z#h#o#u# #Y#o#n#g# V\SB#
zW#Z#h#o#u# #Z#h#i#f#e#n#g# V\VE7e#
zW#Z#h#u# #G#u#a#n#g#h#u#a# Vl9b;*#
zW#Z#h#u# #H#u#i#m#i#n#g# Vl;]Cw#
zW#Z#h#u# #L#i#n# VlAU#
zW#Z#u# #J#i#a#n#j#u#n# Wf=(>|#

From CCNET-L@uga.cc.uga.edu Thu Feb  7 13:22:03 1991
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.64/5.10) with SMTP id AA05154; Thu, 7 Feb 91 13:21:15 -0500
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 0560; Thu, 07 Feb 91 13:13:48 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 6214;
 Thu, 07 Feb 91 13:13:30 EST
Date:         Thu, 7 Feb 91 13:08:00 EST
Reply-To: yawei%UCS.INDIANA.EDU@uga.cc.uga.edu
Sender: Chinese Computing Network <CCNET-L%UGA.BITNET@uga.cc.uga.edu>
From: yawei%UCS.INDIANA.EDU@uga.cc.uga.edu
Subject:      Sample 'zW' text file
Comments: To: ccnet-l <ccnet-l@uga.cc.uga.edu>
Comments: cc: rzhu <rzhu@watmath.waterloo.edu>
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
Status: RO

    First Congress of Chinese Students in the USA

                 * Manifesto *

 (in 'zW' format.)

zW#
zW# # # # # # VP9zH+C@Q'IzQ'U_5ZR;4N4z1m4s;a#
zW#
zW# # # # # # # # # # # # P{# # QT#
zW#
zW# # # # # # #(R;>E0K>EDjF_TBH}J.HU!$V%<S8g#)#
zW#
zW# # NRCG#,VP9zAtC@Q'Iz:MQ'U_5D4z1m#,;3WE6TCqVw5DW7Gs#,;3WE6TWf9z5DV?
zW0.#,;3WE6TMF6/VP9zCqVwTK6/5D@zJ7TpHN8P#,4SH+C@8w5XW_5=R;Fp#,W/QOP{8f
zW3IA"VP9zH+C@Q'IzQ'U_WTVNA*:O;a!##
zW# # NRCGTZ4KP{8fNRCG6TCqVw5DV4WEW7Gs#,K|0|@(AKNRCG6TIz4f!"WTSI!"2F2z
zW!":MPR8#5H;y1>HKH(5DR*Gs#,K|0|@(AKNRCGH7HOHKCqSPH(Q!TqU~8.#,2NSkU~VN
zW:MVwTW9z<R!"CqWeC|TK5DPEDn#,K|JG!0Ne!$KD!1RT@4#,N^J}VP;*V>J?HJHKN*V.
zW7\67N~I|5DJBR5#,JGH+J@=gR;GP=x2=HKJ?5DA<V*Sk92J6#,JGHK@`Ig;a4SR0ByW_
zWOrNDCw#,4SBd:sW_Or=x2=5D@zJ731Aw!##
zW# # NRCGTZ4K1m4oNRCG6T!00K>E!1VP9zCqTK5D>4Rb!#Ub3!N04s5DHKCqTK6/#,1j
zWV>AKVP9zHKCq5DPB>uPQ#,K|OrTZVP9z4s5XIOKAE06~G'6`Dj5D7b=(W(VFVwRe:MR;
zWGP3s6q5D74HKCqJBNoLa3vAKLtU=#,K|JGUqPKVP;*5DO#M{V.9b!##
zW# # NRCGTZ4KG2Tp5K@nQn746/U~H(5DWoPP#,K{CG6TCqVwTK6/5DUrQ9:M6TCqTKHK
zWJ?5DFH:&#,1)B6AKK{CG5D10ASSkPW2P#,R21)B6AKK{CG5D?V>eSkPiHu!#=qHU5DVP
zW9z#,CqPDN4K@#,;pVV2;O"!#HKCqIsEP5K@nQn5DHUWS2;;a:\T6AK!##
zW# # NRCGTZ4KOTJ>NRCG5DME=aSkA&A?!#NRCG:#MbQ'WSA*:OFp@4#,2"7GW7GsHN:N
zWLXJb5D</ME@{Rf!#NRCG=+@{SC:#Mb5DSP@{Lu<~#,E,A&9$Ww#,;}PnA&A?#,44TlLu
zW<~#,4Y=x9zDZCqVw6/PB8_31TgHU5=@4!#NRCG5C5=5DV'3V#,3,T=AK9z=g!"VVWe:M
zWU~VNFg<{5D7VR0#,H+VP9z5DHKCqH:VZ#,FULlOBQW;FWSKo#,H+J@=gR;GPCqVwA&A?
zW:MNRCGU>TZR;Fp#,Ub>MJGNRCG5DA&A?KyTZ!##
zW# # @zJ7TZOrNRCG:t;=!#NRCG>vPDRT:MF=#,@mPT:M7G1)A&5DJV6N#,>-9}3$FZ<h
zW?`5D7\67#,U=J$1)U~:MW(VF#,HCCqVw!"WTSI!"F=5H!"7(VN5D@mOkTZVP9zJ5OV!#
zW#
zW

From CCNET-L@uga.cc.uga.edu Thu Feb  7 13:38:56 1991
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.64/5.10) with SMTP id AA05205; Thu, 7 Feb 91 13:38:35 -0500
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 0630; Thu, 07 Feb 91 13:38:11 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 7358;
 Thu, 07 Feb 91 13:38:10 EST
Date:         Thu, 7 Feb 91 13:24:00 EST
Reply-To: yawei%UCS.INDIANA.EDU@uga.cc.uga.edu
Sender: Chinese Computing Network <CCNET-L%UGA.BITNET@uga.cc.uga.edu>
From: yawei%UCS.INDIANA.EDU@uga.cc.uga.edu
Subject:      How safe is a character
Comments: To: ccnet-l <ccnet-l@uga.cc.uga.edu>
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
Status: RO

Just a little comment after reading comments about how "safe"
is an encoded (uuencode or atob or pure GB) file passing
through certain odd-ball computer systems.

Yes, certain characters are subject to distortion when passing
through certain mainframe systems. I don't remember the list
of these endangered characters but I think it includes "back
quot", "backslash", etc.

One of my friends happened to reside on one such machine. I had
extensive experience able exchanging various encoded files with
him. There's a difference between uuencoded and 'zW' (pure GB)
texts in terms of the "amount of damage" that they can substain:

- 'zW' (pure GB):  very tolerate. If a character is changed by
  the mail system, only one corresponding Chinese character is
  changed. One can still guess the meaning of the sentence from
  context.

- uuencode: depends. Sometimes the program would refuse to decode
   it altogether, in which case the encoded text is useless. Other
  times the decoding succeeds, but the damage seem quite extensive
  - affects more than one Chinese characters.

Exactly what coding scheme to use depends a lot on one's objective.
But I think its not a good idea to design an encoding scheme around
some software bugs - it's a case of confusing the ends and the means,
I think.

yawei

From CCNET-L@uga.cc.uga.edu Thu Feb  7 14:30:54 1991
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.64/5.10) with SMTP id AA05801; Thu, 7 Feb 91 14:29:48 -0500
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 0923; Thu, 07 Feb 91 14:29:09 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 9676;
 Thu, 07 Feb 91 14:29:06 EST
Date:         Thu, 7 Feb 91 14:27:34 -0500
Reply-To: 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:      How safe is a character
Comments: To: ccnet-l@uga.cc.uga.edu
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
In-Reply-To:  <9102071838.AA03235@leibniz.math.psu.edu>
Status: RO

Concerning the problem of ASCII files being damaged by e-mail
transmission via non-ASCII computers, Yawei writes:

> There's a difference between uuencoded and 'zW' (pure GB)
> texts in terms of the "amount of damage" that they can substain:
>
> - 'zW' (pure GB):  very tolerate. If a character is changed by
>  the mail system, only one corresponding Chinese character is
>  changed. One can still guess the meaning of the sentence from
>  context.
>
> - uuencode: depends. Sometimes the program would refuse to decode
>  it altogether, in which case the encoded text is useless. Other
>  times the decoding succeeds, but the damage seem quite extensive
>  - affects more than one Chinese characters.

Yes, thank you for pointing out my mistake.  I should have made it
clear that, while neither is perfect, CCDOS + UUENCODE is much worse
than pure GuoBiao (or ZW, or HZ) in terms of damage by non-ASCII
mailers.

> Exactly what coding scheme to use depends a lot on one's objective.
> But I think its not a good idea to design an encoding scheme around
> some software bugs - it's a case of confusing the ends and the means,
> I think.

I agree.  ASCII is an extremely well-established standard.  We
shouldn't contort ourselves merely to accommodate bugs in IBM's
EBCDIC-to-ASCII conversion programs.  In the present context, this
means we shouldn't propose XXencode as a standard for Chinese e-mail.
On the other hand, UUencoded files can become completely
unrecoverable.  So some kind of pure GuoBiao (or ZW or HZ) is a good
compromise.

From CCNET-L@uga.cc.uga.edu Thu Feb  7 14:38:54 1991
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.64/5.10) with SMTP id AA05844; Thu, 7 Feb 91 14:37:30 -0500
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 0943; Thu, 07 Feb 91 14:36:11 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 9877;
 Thu, 07 Feb 91 14:36:09 EST
Date:         Thu, 7 Feb 91 14:19:00 EST
Reply-To: Dorothy Day <DAY%IUBACS.BITNET@uga.cc.uga.edu>
Sender: Chinese Computing Network <CCNET-L%UGA.BITNET@uga.cc.uga.edu>
From: Dorothy Day <DAY%IUBACS.BITNET@uga.cc.uga.edu>
Subject:      re:which one is better
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
Status: RO

Stephen Simpson writes:

>Well, not completely safe, because even some of the printable ASCII
>characters (33 to 126) are not handled correctly in EBCDIC.  This
>implies that your file can get corrupted if your mail path goes
>through an IBM mainframe running VM.  Fortunately, Internet mail is
>not usually gatewayed through IBM mainframes.

Actually, a great deal of Bitnet mail passes through IBM mainframes,
and for this reason some encoding (UUencoding or XXencoding usually
works) is necessary to protect non-text files.
        --Dorothy Day

From CCNET-L@uga.cc.uga.edu Thu Feb  7 15:05:18 1991
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.64/5.10) with SMTP id AA06090; Thu, 7 Feb 91 15:04:08 -0500
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 1050; Thu, 07 Feb 91 15:03:34 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 1225;
 Thu, 07 Feb 91 15:03:33 EST
Date:         Thu, 7 Feb 91 14:24:00 EST
Reply-To: Dorothy Day <DAY%IUBACS.BITNET@uga.cc.uga.edu>
Sender: Chinese Computing Network <CCNET-L%UGA.BITNET@uga.cc.uga.edu>
From: Dorothy Day <DAY%IUBACS.BITNET@uga.cc.uga.edu>
Subject:      re: how safe...?
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
Status: RO

See the document I posted yesterday about which characters are used in
UUencode and XXencode; the latter avoids most of the problems known to
occur in EBCDIC translation of UUencoded files by using both upper and
lowercase letters and fewer non-alphanumeric characters.
        --D. Day

From CCNET-L@uga.cc.uga.edu Thu Feb  7 16:08:05 1991
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.64/5.10) with SMTP id AA06450; Thu, 7 Feb 91 16:07:37 -0500
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 1227; Thu, 07 Feb 91 16:06:56 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 3389;
 Thu, 07 Feb 91 16:06:54 EST
Date:         Thu, 7 Feb 91 16:06:18 -0500
Reply-To: 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:      re:which one is better
Comments: To: ccnet-l@uga.cc.uga.edu
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
In-Reply-To:  <9102071937.AA03348@leibniz.math.psu.edu>
Status: RO

Dorothy Day writes:

 > Actually, a great deal of Bitnet mail passes through IBM mainframes,
 > and for this reason some encoding (UUencoding or XXencoding usually
 > works) is necessary to protect non-text files.

I'm willing to believe that XXencoding usually works (at the cost of
making your files bigger by half).  But UUencoding usually doesn't
work, since it is not immune from the disease called EBCDIC.  (See
Yawei's recent message on "how safe is a character".)  That is the
reason for the existence of XXencode and similar workarounds.

Actually, there are some versions of UUencode that take account of
EBCDIC translation bugs, but the situation is complex. This is one
reason why people with Bitnet access but no Internet access often feel
deprived and harrassed.

UUencoding works fine for its intended purpose, namely to encode
non-ASCII files into printable ASCII.  Unfortunately, IBM mainframes
do not understand printable ASCII.

From CCNET-L@uga.cc.uga.edu Thu Feb  7 19:45:30 1991
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.64/5.10) with SMTP id AA08241; Thu, 7 Feb 91 19:44:01 -0500
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 1911; Thu, 07 Feb 91 19:42:49 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 9568;
 Thu, 07 Feb 91 19:41:25 EST
Date:         Thu, 7 Feb 91 15:57:40 CST
Reply-To: "J. Ding" <B366JDX%UTARLVM1.BITNET@uga.cc.uga.edu>
Sender: Chinese Computing Network <CCNET-L%UGA.BITNET@uga.cc.uga.edu>
From: "J. Ding" <B366JDX%UTARLVM1.BITNET@uga.cc.uga.edu>
Subject:      Re: which one is more popular?
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
In-Reply-To:  Your message of Thu, 7 Feb 91 01:42:54 MST
Status: RO

While everyone is arguing which method is super, which is poor, I noticed
that Rupert wants to take a real step forward to get the project going.


I also noticed that the similar topic seems extensively discussed back as
early as two years ago. Can anyone give me(a new comer) some idea of what
kind of real development has achieved or is it still a discussing topic?.
Specificly, any pilot scheme(no matter how good or bad) has been tested/adopted
among significant amount of people? How far has the HZ scheme reached?

Thanks to Prof. Seiichi Nomura here at UTA, I had a chance to look at the
Japanese E-mail news system. As Mark said in his mail yesterday, the Japanese
used <Esc>$B and <Esc>(B to block the Japanese from English. It may not be the
best but it is working. They also make several public domain software to push
the readers' market. For example, a PC based viewer (kermit interface) was
available for anonymous FTP.

I would like to see that some agreement could be reached asap for further
steps. Also more important, the project need people to donate time and skill.

I personaly prefer the Pure GuoBiao with certain escape(like zW and HZ). My
major argument is user interface/convenience. While most e-mail is still
relying on mainframe, most Chinese text displays rely on Vedio User Interface
(PC) or Graphic User Interface(Mac). An real time interface between VUI/GUI
and mainframe output is essencial. You can't expect users to read a message
by going through downloading, decoding, running CCDOS(or BYX) and finally
getting himself a garbage "Test" message. Offline coding/decoding will make
life really painful. So the pure GuoBiao scheme is preferable in my point of
view.

I don't know if such a viewer already existed. Yawei's real time viewer is
impressive, but its CC-DOS dependence makes a complicated world. Software
independence will be a better approach. Containing its own 16x16 fonts, the
TSR viewer should be made freeware along with one or two text converting
program for CC-DOS or BYX etc.(a piece of cake since they all Guobiao based).
If it gets popular, those Chinese software developers(CCDOS or BYX) will take
care of the futher interface work to promote their market. My point is simple,
devote some time to get a freeware viewer to first get as many users to READ
Chinse(in the format of news or something) to create a potential user market.
Leaving the good input/print function taken care of by commercial people.

Again, I appreciate Rupert's intention to push the project moving forward
and looking forward to working with some enthusiastic guys to get something
done.

Jian Ding
Computer Support Specialist                   B366JDX@UTARLVM1
Library -- U. Texas at Arlington              B366JDX@UTARLVM1.UTA.EDU

From CCNET-L@uga.cc.uga.edu Thu Feb  7 21:50:09 1991
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.64/5.10) with SMTP id AA08837; Thu, 7 Feb 91 21:49:13 -0500
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 2156; Thu, 07 Feb 91 21:48:50 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 2307;
 Thu, 07 Feb 91 21:48:48 EST
Date:         Thu, 7 Feb 91 19:49:50 EST
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:      Statistics of Bytes in Guo Biao Table
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
Status: RO

The following shows the statistics of bytes in the "8-bit Guo Biao"
table.  The "7-bit Guo Biao" can be obtained by subtracting 128 from
the 8-bit GB.   The codes less than 128 do not belong to 8-bit GB.
Only those codes which are greater 128 represent bytes in 8-bit GB coding.

Thanks to Mark for pointing out that 7-bit GB uses ASCII 33--126.
(I claimed yesterday that it was 33--127.)   --- Rupert

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

             Statistics of Bytes in 8-bit Guo Biao Coding
             ============================================

Total Number of      All       Characters:  44648
Total Number of Ordinary ASCII Characters:  29740
Total Number of Extended ASCII Characters:  14908


	   Frequency of Occurence of Each ASCII Character

Code Occurence   Code Occurence   Code Occurence   Code Occurence   Code Occuren
  9      4       163    173       187    176       211    175       235    173
 10      4       164    173       188    175       212    173       236    173
 32     11       165    173       189    173       213    174       237    175
 44      2       166    173       190    173       214    176       238    173
 46      2       167    173       191    174       215    175       239    173
 48    865       168     79       192    173       216    173       240    173
 49   1042       169     79       193    174       217    173       241    173
 50   1038       170     80       194    173       218    173       242    173
 51   1038       171     79       195    173       219    173       243    173
 52   1038       172     79       196    175       220    173       244    173
 53   1038       173     79       197    174       221    173       245    173
 54   1038       174     79       198    173       222    173       246    173
 55   1038       175     79       199    176       223    173       247    174
 56    850       176    173       200    174       224    173       248     79
 57    850       177    175       201    173       225    173       249     80
 58      1       178    174       202    177       226    174       250     80
 65   2697       179    174       203    173       227    173       251     80
 66   3619       180    175       204    173       228    173       252     79
 67   3618       181    174       205    174       229    173       253     79
 68   3618       182    173       206    174       230    173       254     80
 69   3619       183    174       207    173       231    173         0      0
 70   2710       184    174       208    174       232    173         0      0
161    173       185    174       209    174       233    173         0      0
162    174       186    176       210    175       234    174         0      0

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

From CCNET-L@uga.cc.uga.edu Thu Feb  7 21:59:55 1991
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.64/5.10) with SMTP id AA08866; Thu, 7 Feb 91 21:59:06 -0500
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 2174; Thu, 07 Feb 91 21:58:38 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 2479;
 Thu, 07 Feb 91 21:58:35 EST
Date:         Thu, 7 Feb 91 19:51:13 MST
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: which one is more popular?
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
In-Reply-To:  <9102071733.AA00640@kythera>
Status: RO

 >
 > Well, not completely safe, because even some of the printable ASCII
 > characters (33 to 126) are not handled correctly in EBCDIC.  This
 > implies that your file can get corrupted if your mail path goes
 > through an IBM mainframe running VM.  Fortunately, Internet mail is
 > not usually gatewayed through IBM mainframes.
 >

Hmm.  Good point.

 >
 > This problem exists, but it can be solved.  The most elegant solution
 > I have seen was proposed and implemented by Fung Fung Lee, Ricky
 > Yeung, and others.  Namely, the HZ standard.  Roughly speaking, the
 > idea of HZ is to enclose 7-bit GuoBiao between brackets that look like
 > ~{ and ~}.  Here the tilde ~ functions as an escape character.  In
 > this way, 7-bit GuoBiao can be mixed with ASCII.  The ASCII parts of
 > the file are immediately readable on any ASCII terminal.  The GuoBiao
 > parts are immediately readable (and printable) using any software that
 > understands GuoBiao.
 > ...
 > Mark, can you see any drawbacks to HZ as a proposed standard for
 > Chinese e-mail?  I see only two.
 >

The HZ and zW methods are both elegant methods.  The only immediate
problem with the HZ method is that the tilde character is interpreted
as a command indicator in some mailers.  The one that we have on our
Sun systems for instance.  But this problem can be avoided by using
another mailer.

The only other problem with the two methods I can see is the problem
with transmission through EBCDIC systems (as you mention below).  This
problem needs to be addressed for people who are limited to BITNET
access.

Dorothy Day's article reminded me that xxencode was designed to
circumvent problems with transmission through EBCDIC(yuch) systems.
Maybe this is the way to go.

-----------------------------------------------------------------------------
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 Thu Feb  7 22:00:42 1991
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.64/5.10) with SMTP id AA08871; Thu, 7 Feb 91 21:59:55 -0500
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 2174; Thu, 07 Feb 91 21:58:38 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 2479;
 Thu, 07 Feb 91 21:58:35 EST
Date:         Thu, 7 Feb 91 19:51:13 MST
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: which one is more popular?
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
In-Reply-To:  <9102071733.AA00640@kythera>
Status: RO

 >
 > Well, not completely safe, because even some of the printable ASCII
 > characters (33 to 126) are not handled correctly in EBCDIC.  This
 > implies that your file can get corrupted if your mail path goes
 > through an IBM mainframe running VM.  Fortunately, Internet mail is
 > not usually gatewayed through IBM mainframes.
 >

Hmm.  Good point.

 >
 > This problem exists, but it can be solved.  The most elegant solution
 > I have seen was proposed and implemented by Fung Fung Lee, Ricky
 > Yeung, and others.  Namely, the HZ standard.  Roughly speaking, the
 > idea of HZ is to enclose 7-bit GuoBiao between brackets that look like
 > ~{ and ~}.  Here the tilde ~ functions as an escape character.  In
 > this way, 7-bit GuoBiao can be mixed with ASCII.  The ASCII parts of
 > the file are immediately readable on any ASCII terminal.  The GuoBiao
 > parts are immediately readable (and printable) using any software that
 > understands GuoBiao.
 > ...
 > Mark, can you see any drawbacks to HZ as a proposed standard for
 > Chinese e-mail?  I see only two.
 >

The HZ and zW methods are both elegant methods.  The only immediate
problem with the HZ method is that the tilde character is interpreted
as a command indicator in some mailers.  The one that we have on our
Sun systems for instance.  But this problem can be avoided by using
another mailer.

The only other problem with the two methods I can see is the problem
with transmission through EBCDIC systems (as you mention below).  This
problem needs to be addressed for people who are limited to BITNET
access.

Dorothy Day's article reminded me that xxencode was designed to
circumvent problems with transmission through EBCDIC(yuch) systems.
Maybe this is the way to go.

-----------------------------------------------------------------------------
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 Thu Feb  7 22:00:54 1991
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.64/5.10) with SMTP id AA08879; Thu, 7 Feb 91 22:00:41 -0500
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 2175; Thu, 07 Feb 91 21:59:49 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 2503;
 Thu, 07 Feb 91 21:59:08 EST
Date:         Thu, 7 Feb 91 21:56:26 EST
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:      CHAR.C  --- A Piece of Utility
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
Status: RO

I used the following program to produce statistics of bytes information
in any file, text or binary.  It is helpful in analyzing file contents.

-- Rupert

--------------------------- CUT HERE ------------------------------
/*  char.c  */
/* Show the statistics on all ASCII characters 0--255   */
/* Author: Rupert Zhu    December/1990        */

#include  <stdio.h>
#include  <ctype.h>
#include  <math.h>
/* #define   ceil(X)    ( floor(X + 0.5) )    */

long   buffer[260];    /* buffer[i]== number of occurence of code i */
long   counter;       /* Count total number of characters  */
long   acount, bcount;  /* Count ordinary ASCII and extended ASCII */

void   printout(void);

main()
{
	int    c, i, j, count;

	for (i=0; i<=259; i++)
		buffer[i] = 0;

	counter = 0;            /*  the EOF character not counted  */
	while ( (c=getchar()) != EOF) {
			buffer[c]++;
			counter ++;
		}
/*	buffer[c]++;     */
	acount = 0;
	bcount = 0;
	for (i=0; i <= 127; i++)
		acount = acount + buffer[i];
	for (i=128; i <= 255; i++)
		bcount = bcount + buffer[i];
	printf("\nTotal Number of      All       Characters:  %ld", counter);
	printf("\nTotal Number of Ordinary ASCII Characters:  %ld", acount);
	printf("\nTotal Number of Extended ASCII Characters:  %ld\n", bcount);
	printout();
}

void    printout(void)
{
	int    c, i, j, count, depth;
	long   ctab[2][260];

	printf("\n\n\n");
	for (i=0; i<=259; i++) {
		ctab[0][i] = 0;
		ctab[1][i] = 0;
		}
	j = 0;
	for (i=0; i<=259; i++)
		if (buffer[i] >= 1) {
			ctab[0][j] = i;
			ctab[1][j] = buffer[i];
			j++;
			}
	count = j;
	depth = ceil(count/5.0);
	printf("\t   Frequency of Occurence of Each ASCII Character\n\n");
	printf("Code Occurence   ");
	printf("Code Occurence   ");
	printf("Code Occurence   ");
	printf("Code Occurence   ");
	printf("Code Occuren\n");
	for (i=0; i<= depth-1; i++) {
       	    printf("%3ld%7ld       ", ctab[0][i], ctab[1][i]);
	    printf("%3ld%7ld       ", ctab[0][i+depth], ctab[1][i+depth]);
	    printf("%3ld%7ld       ", ctab[0][i+2*depth], ctab[1][i+2*depth]);
	    printf("%3ld%7ld       ", ctab[0][i+3*depth], ctab[1][i+3*depth]);
	    printf("%3ld%7ld\n",      ctab[0][i+4*depth], ctab[1][i+4*depth]);
	    }
}
/* --------------------------- THE END ----------------------------- */

From CCNET-L@uga.cc.uga.edu Thu Feb  7 22:45:37 1991
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.64/5.10) with SMTP id AA09028; Thu, 7 Feb 91 22:45:20 -0500
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 2221; Thu, 07 Feb 91 22:45:03 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 3114;
 Thu, 07 Feb 91 22:43:18 EST
Date:         Thu, 7 Feb 91 20:40:15 MST
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:      Tildes and mail
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
Status: RO

kuo@spot.colorado.edu (Andy Kuo) pointed out that the tilde
interpretation that /usr/ucb/mail uses is not present in
/usr/lib/sendmail.  So sending HZ text can be done directly through
sendmail or by using some other mail package that doesn't interpret
tildes.
-----------------------------------------------------------------------------
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 Thu Feb  7 23:58:20 1991
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.64/5.10) with SMTP id AA09327; Thu, 7 Feb 91 23:57:35 -0500
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 2356; Thu, 07 Feb 91 23:57:11 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 4448;
 Thu, 07 Feb 91 23:57:09 EST
Date:         Thu, 7 Feb 91 21:55:52 MST
Reply-To: kuo%SPOT.COLORADO.EDU@uga.cc.uga.edu
Sender: Chinese Computing Network <CCNET-L%UGA.BITNET@uga.cc.uga.edu>
From: kuo%SPOT.COLORADO.EDU@uga.cc.uga.edu
Subject:      tilde escape
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
Status: RO

  I would like to add one point to what I sent to Mark regarding the
tilde escape character which was reposted to the list.

  By default, ~ (tilde) is the escape character for the standard
bsd mailer (/usr/ucb/mail or /usr/bin/mailx on HP-UX) and is what
you will mostly likely be using on a Unix system.

  However, as Mark pointed out, the ASCII number for ~ is 126 and
is a valid character in the encoding method.  So if the file you
wish to send has one or more lines that starts with ~, there can be
some expected results.

  This restriction is only applicable when you send the file.  You
are "safe" if you just want to receive the file.

  The solutions to work around this are:

1. Use a different mailer.

2. Direct the message to a mail delivery daemon directly, such as
   sendmail.

3. Redefine your escape character.  For example, esc (ctrl-[)
   has the ASCII value of 27 (not a valud encoding character).  If
   you want to use esc in place of ~, put this in your .mailrc
   (note that ^[ is one single control character) :
           set escape=^[


Andy

From CCNET-L@uga.cc.uga.edu Fri Feb  8 01:59:20 1991
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.64/5.10) with SMTP id AA09716; Fri, 8 Feb 91 01:55:11 -0500
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 2528; Fri, 08 Feb 91 01:53:42 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 5964;
 Fri, 08 Feb 91 01:53:37 EST
Date:         Fri, 8 Feb 91 01:47:00 EST
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:      BITFTP Server Adopts UUENCODE
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
Status: RO

BITFTP is a public service provided at Princeton for BITNET users
to partly simulate FTP.  This BITFTP supports two ways to handle
binary files, one is a generic BITNET function.  The other is the
UUENCODE/UUDECODE.  The following is the document.

-- Rupert

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

               BITFTP -- Princeton BITNET FTP Server

BITFTP provides a mail interface to the FTP portion of the IBM
TCP/IP product ("FAL") running on the Princeton VM system, to allow
BITNET/NetNorth/EARN users to ftp files from sites on the Internet.

To use BITFTP, send mail containing your ftp commands to BITFTP@PUCC
(or to BITFTP@PUCC.Princeton.edu).

The first command to BITFTP must be "FTP", "FTPLIST", "HELP", or
"VMS".  If you send BITFTP mail or a message containing only the
command "FTPLIST", it will send you a list of some of the hosts that
allow anonymous ftp.  (Note that there is no guarantee that BITFTP
can access all the hosts in that list.)  Use "HELP" to request a
current copy of this help file.  Use "VMS" to request a collection
of tips provided by BITFTP users on how to handle binary files from
BITFTP on VMS systems.

The recommended syntax for FTP requests is:

   FTP hostname NETDATA    --or--    FTP hostname UUENCODE
   USER username password
   <other ftp subcommands>
   QUIT

Following the hostname on the FTP command, you may specify
"UUENCODE" or "NETDATA" to tell BITFTP the format in which you wish
to receive files.

If the username is "anonymous", no password is required; BITFTP will
use your userid and nodeid as the password.  Note that on many
systems passwords are case-sensitive; that is, the password may be
required to be in lower case or mixed case or upper case.  (The same
is true of directory and file names.)

The following is an example of an ftp request:

   FTP  f.ms.uky.edu  NETDATA
   USER  anonymous
   CD  /pub/msdos/Games
   DIR
   BINARY
   GET  robotron.arc  msdos.robotron
   QUIT

BITFTP implements a subset of the ftp subcommands provided in the
IBM TCP/IP and uses the same syntax.  Therefore, you may find it
useful to obtain the "IBM TCP/IP for VM Command Reference Manual",
IBM order number GC09-1204.

The currently supported subcommands are:

  ACCT        -- to send host-dependent account information.
    format:   ACCT account-information

  ASCII       -- to change the file transfer type to ASCII.
    format:   ASCII

  BINARY      -- to change the file transfer type to image.
    format:   BINARY <FIXED record-len> <VARIABLE>

  CD          -- to change the working directory.
    format:   CD directory

  CLOSE       -- to disconnect from the foreign host.
    format:   CLOSE

  DIR         -- to get a list of directory entries.
    format:   DIR

  EBCDIC      -- to change the file transfer type to EBCDIC
    format:   EBCDIC

  GET         -- to get a file from the foreign host.
    format:   GET foreignfile <localfile>

              If you specify "localfile", it must be in
              the forms "filename.filetype" or "filename",
              and the filename and filetype may each be no
              more than 8 characters long and may not contain
              periods.

  LOCSTAT     -- to display local status information.
    format:   LOCSTAT

  LS          -- to list the files in a directory.
    format:   LS <name>

  PWD         -- to print the working directory.
    format:   PWD

  QUIT        -- to disconnect from the foreign host.
    format:   QUIT

  STATUS      -- to retrieve status information from a foreign host.
    format:   STATUS <name>

  SYSTEM      -- to get the name of the foreign host's operating
                 system.
    format:   SYSTEM

  TYPE        -- to specify Image, ASCII, or EBCDIC file transfer.
    format:   TYPE <I|A|E>

BITFTP does not provide a PUT capability, and there is no intention
to make it do so in the future.

BITFTP currently accepts requests only via RFC822-format mail, IBM
NOTE-format mail, PROFS-format messages, or files with no headers at
all.  BITFTP currently returns the requested files as NETDATA-format
files or as mail files containing UUENCODED data.  If you specify
"UUENCODE" or "NETDATA" on your "FTP" command, BITFTP will attempt
to use that format.  If you do not specify the format, BITFTP will
attempt to select the appropriate format for your node.

UUENCODED files are broken up into mail files that contain no more
than 50,000 bytes of data.  NETDATA-format files that are larger
than 300,000 bytes are sent in 300,000-byte pieces using the BITSEND
function.  You should be able to receive such files using the BITRCV
function available from your nearest NETSERV.  (If you do not know
how to use NETSERV, ask your local BITNET/EARN/NetNorth Coordinator
for assistance.)  If BITRCV is not available for your system, use
the command you normally use to receive NETDATA-format files and
then concatenate the files in the order shown in the BITRCV control
file to recover the original file.

Users in the UK should note that BITFTP attempts to send
NETDATA-format files through the gateway from EARN into Janet via
the NIFTP facility at Rutherford Lab.  Note that receiving files via
NIFTP requires an overt action on your part.  If you are at a Janet
node and don't know how to use NIFTP, you should ask for assistance
locally.  Alternatively, you can ask BITFTP to send your files
UUENCODED inside mail by specifying the "UUENCODE" option.

If BITFTP sends you a file you cannot read, THE FIRST THING TO DO is
to make sure that you specified ASCII if the file should contain
textual material or that you specified BINARY if the file should
contain binary data, executable programs, tar files, or the like.
VMS users should specify BINARY F 512 and should use RECEIVE/BINARY
to receive the NETDATA-format binary files BITFTP sends them.

If BITFTP sends you a uuencoded file that you cannot uudecode, the
first thing to do is to translate all occurrences of 0x7E in the
file to 0x5E and then try uudecoding again.  (Some gateways are
changing 5Es to 7Es when the files pass through them.)

There are many different flavors of UUENCODE/UUDECODE.  The version
that BITFTP uses puts a "guard character" at the end of each encoded
line.  Most implementations of uudecode know to ignore this
character.  If yours does not, then you should remove the last
character of each line before attempting to uudecode the file.  Note
that the guard character is not always "M"; the short lines at the
end of the file may have some other guard character, rather than
"M".  Whatever that character is, it should be removed (or your
uudecode should be fixed).

When BITFTP is told to transfer a file in FIXED format, such as
"BINARY FIXED 128", it will create a file whose total byte count is
an integral multiple of the record length (128, in this case).  This
means that the last record may be padded to get it to the specified
record length.  In such a case, you may need to use an editor to
shorten the last record so that the total byte count in the file is
correct.  (If the file is uuencoded when you receive it, shorten it
AFTER you have uudecoded it.)

In addition to any files you request, you will also receive a mail
file containing a log of your ftp session.  In that mail file,
entries prefixed by ">" are your original commands; those prefixed
by ">>" are your commands as interpreted by BITFTP and passed to
TCPIP; those prefixed by ">>>" are your commands as interpreted by
TCPIP and passed to the remote host; those prefixed by "<<<" are
messages from the remote host; and those prefixed by ">>>>" are
completion messages from BITFTP.

If BITFTP is unable to connect to the host you specify, it will send
you mail after the first attempt, but will keep trying at intervals
over three days.  The only additional mail file you will receive
will be when the connection is made successfully or when BITFTP
gives up after three days.

The load on BITFTP is often very heavy, and network backlogs are
often so great that it may take several days for a file to get to
you once BITFTP sends it, so please be patient and don't send
multiple requests for the same file.  If your system allows you to
send interactive messages, you can inquire about BITFTP's backlog by
sending the query "How are you?", e.g., on a VM system:

   TELL BITFTP AT PUCC How are you?

Questions about BITFTP and suggestions for improvements should be
directed to Melinda Varian, MAINT@PUCC on BITNET or
maint@pucc.princeton.edu on the Internet.

The author gratefully acknowledges the use of the FTP SUBCOM
interface written by David Nessl, the SENDJANI EXEC written by Alan
Flavell, the uuencoding utility written by John Fisher, and the
RFC822 parsing routine written by Eric Thomas.  NOTE:  If you have
any complaints or suggestions about the way any of these routines
work in BITFTP, please send them to MAINT@PUCC (Melinda Varian), not
to the authors.

=============================== THE END ==========================

From CCNET-L@uga.cc.uga.edu Fri Feb  8 18:52:15 1991
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.64/5.10) with SMTP id AA15637; Fri, 8 Feb 91 18:50:21 -0500
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 9053; Fri, 08 Feb 91 18:49:39 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 9180;
 Fri, 08 Feb 91 18:49:37 EST
Date:         Fri, 8 Feb 91 15:48:14 -0800
Reply-To: Ed Lai <lai%APPLE.COM@uga.cc.uga.edu>
Sender: Chinese Computing Network <CCNET-L%UGA.BITNET@uga.cc.uga.edu>
From: Ed Lai <lai%APPLE.COM@uga.cc.uga.edu>
Subject:      Some consideration for design of Chinese encoding standard
Comments: To: CCNET-L@uga.cc.uga.edu
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
Status: RO

I like to point out some of the thing we have to consider when we are
designing an encoding standard.

1. It should be able to accomdate both batch processing and on-line display
. In on-line display, the Chinese character will be display automatically
as it comes without the user doing anything. This is not a dream, we now
have several program for different machines that can do this. For those
without Chinese capability in the terminal program, they are not locked out,
any protocol that allows on-line display can also allowed batch processing.
Although it can be agrued that if we design a protocol that is for batch
processing only, then it would be more compact than one that allows on-line
display, but the saving will be so minimal that this will be a very short
sighted design. (Interestingly, what is proposed as a batch protocol such as
uuencode is in fact less compact than most of the on-line protocol using
pure GB).

2. It should function well in the enviroment we have now where the bulk of
mail/news is in 7-bit ASCII roman text. This means that the default mode
should be English, with escape character staring the Chinese encoding.
Otherwise we would be mis-reading most of our mail/news, making non-sensical
Chinese out of what is really English mail/news.

3. Because we are far more likely to be modifying the system in the terminal
end rather than the mainframe end. We must have a protocol that works without
the cooperation of the mainframe software being aware of we have Chinese text
over here. As a consequence, we need to have our English-to-Chinese escape
sequence at the beginning of every line so that we would not lose the mode
information when we skip ahead and backward n lines. As far as I understand
that is what the Japanese are doing in their system too.

4. Assuming we accept point number 3, there are still two way to do it. In the
first way you always uses a start Chinese escape and then you use a end
Chinese escape. If all your text are in Chinese it would end up having each
line starting with a start Chinese escape sequence and each line ending with
a end Chinese escape. However this also means you are sending mail and you
are absolutely sure that the other party is going to do batch processing, then
you may violate what we have said so far and use a single begin Chinese
escape in the whole file and a end Chinese at the end of the file, resulting
in a more compact file. The other alternative is to assume that there is a
implied end Chinese escape at the end of every line so it is not necessary to
put one at the end, this will be more compact in general, but it will not let
you use the trick of a single begin Chinese escape for the whole file. BTW
this is the approach of 'zW'. Each approach has its own merit and drawback,
but I have no problem with using either approach.

5. Now to choose the escape character/sequence. I really have no strong
perference, but obviously we want one that works. I hear there is problem
with $1B, so we should try to avoid it. We need to avoid something that is
likely to occur in normal English text, and the ending sequence should avoid
using a valid GB Chinese character. The latter does not sound like a problem
since there are still many undefined GB character code position. However, we
should research more into the problem, I heard that there is a GB standard
defined in Mainland China that is very close to the one we normally see, but
have some extra code defined to alleviate the n-to-1 mapping problem between
traditional and simplified character. If possible we should try to be able to
accomdate this broader GB.

6. We are talking mostly about protocol for displaying Chinese character
gracefully in a terminal, and zW/HZ is probably a good approximation already.
But they would not fare so well if we are doing input. Pai Chou has a terminal
emulator for Big-5 that uses a escape for every Chinese character. Most of us
may not want to go that far, but it does a reasonable job of inputting when
we are using vi or mail, so this is something we may want to think about.

/* 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 Fri Feb  8 20:16:59 1991
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.64/5.10) with SMTP id AA17281; Fri, 8 Feb 91 20:15:42 -0500
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 9355; Fri, 08 Feb 91 20:14:25 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 1694;
 Fri, 08 Feb 91 20:14:18 EST
Date:         Fri, 8 Feb 91 20:13:00 EST
Reply-To: yawei%UCS.INDIANA.EDU@uga.cc.uga.edu
Sender: Chinese Computing Network <CCNET-L%UGA.BITNET@uga.cc.uga.edu>
From: yawei%UCS.INDIANA.EDU@uga.cc.uga.edu
Subject:      Some consideration for design of Chinese encoding standard
Comments: To: ccnet-l <ccnet-l@uga.cc.uga.edu>
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
Status: RO

This is follow-up to Ed's message about consideration for designs.
I'll just tell what I think based on my experience writting ZWWATCH.

A little background info about CCDOS: the PC video can work two different
ways: text mode and graphic mode. Most PC applications run in text mode,
in which ASCII codes of data are stored in the frame buffer. CCDOS turns
the video into graphic mode - in which data are stored in the frame
buffer as bit-maps. (I am using the term frame buffer loosely, should
have used "video memory".)  Most versions of CCDOS intercepts system
calls to write characters to the screen. If they see Chinese text data
coming in, they draw the characters on screen, otherwise they draw the
ASCII characters in graphic mode.

ZWWATCH acts as an extra layer between cCDOS and the application programs,
interrupting the keyboard, video and printer system calls just like
CCDOS does. It does all the neccessary encoding and decodings as the
data is passed between CCDOS and the application, so that CCDOS only
sees its own format and the application only sees 'zW'. The conversion
can be tricky at times.

The printer decoder part of ZWWATCH is simplest. Printer output is treated
as a sequential stream, and the 'zW' string is checked for at the beginning
of each line. This works reasonably well for pure text (GB or ASCII), but
could conceivably have problem with escape codes intended as printer commands.
A scheme which allows for intraline mixing of GB and ASCII may be better
in solving this problem.

The keyboard/screen part - if we simply treats every thing we type as
a sequential stream, this part is very simple too. You simply does
'zW-encode' at the keyboard end and 'zW-decode' at the video end. You
don't even normally have escape commands to worry about in most cases.

Complication comes when I was trying to make it work with full screen
editors. As ED pointed out, this requires that Chinese text data be
indicated locally - which 'zW' does quite well. Everytime the cursor
position changes, ZWWATCH checks to determine whether the current line
is Chinese or ASCII. It does by reading the first two characters from
the beginning of the line to see if they are 'zW'.

Reading characters from a graphic screen is a very slow process. It
involves comparing the bit patterns on screen with the 256 font patterns.
The delay is not noticeable when only the first two characters need
to be read. But for schemes that allows intraline mixing of text, the
entire line would need to be read, which could be an expensive process.

In the end, I sort of got it working with full screen editors like
VMS EDT or vi on unix. It's not completely glitch-free, however.

JD's suggestion of writing something similar but not depending on
CCDOS is a reasonable suggestion. But if we have a very good implementation
of CCDOS, perhaps fewer would ask for that. The idea of using CCDOS
is that things can be more modular; different input schemes of different
versions of CCDOS can be used - otherwise our program has to take care
of converting input codes to internal codes and converting characters
etc. But it sure would be nice if a version of CCDOS can be written
with the our need in mind, so as to make some of our works -- like
determining if the current context is Chinese or ASCII -- easier.

If someone already has a set of good routines for inputing and outputing
Chinese characters, it definitely is a good idea to write a standalone
Chinese terminal. The problem with me was that I didn't have any input
routines, I have a set of output routines but no fonts.

yawei

From CCNET-L@uga.cc.uga.edu Fri Feb  8 22:11:02 1991
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.64/5.10) with SMTP id AA17699; Fri, 8 Feb 91 22:10:51 -0500
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 9594; Fri, 08 Feb 91 22:10:16 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 4340;
 Fri, 08 Feb 91 22:10:11 EST
Date:         Fri, 8 Feb 91 20:07:11 MST
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:      Email to PRC (CANET)
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
In-Reply-To:  <9102082320.AA05794@kythera>
Status: RO

On way to get email to the Chinese Academic Network (CANET) is through
Germany. The information below is taken from a book called "!%@:: A
Directory of Electronic Mail Addressing and Networks" from O'Reilly &
Associates.  It's part of the Nutshell Handbook line.

ADDRESS:
Werner Zorn or Michael Rotert
University of Karlsruhe
Computer Science Department
D-7500
Germany

TELEPHONE:
+49 721 608 3981

EMAIL:
zorn@ira.uka.de
rotert@ira.uka.de
postmaster%beijing@ira.uka.de

Here's a message from Professor Zorn from last year:

 >From: zorn@ira.uka.de (Prof. Dr. Werner Zorn)
 >Newsgroups: soc.culture.china
 >Subject: Help funding of E-Mail with China
 >Date: 5 Nov 90 17:14:24 GMT
 >Reply-To: zorn@ira.uka.de (Prof. Dr. Werner Zorn)
 >Organization: University of Karlsuhe, West-Germany
 >
 >
 >Dear friends,
 >the E-mail connection to Beijing via Karlsruhe/Germany is, as most of you
 >probably know, still active and the external link to CANET- the Chinese
 >Academic Network initiative.
 >In China there is great interest in connecting to the mail relay at the
 >ICA (Institute for Computer Applications) in Beijing and everybody is
 >also willing to help in propagating the network services to more univer-
 >sities and research institutes (6 are actually polling). But the main
 >problem is:
 >   - nearly all universitites are out of funds and cannot afford the
 >     communication costs even within China ( Beijing- Karlsruhe is
 >     payed by ICA, Karlsruhe- rest of the world by Karlsruhe).
 >One idea to help from outside is trying to find people or institutions,
 >who are interested in communicating with colleagues or partners in China
 >and are able as well as willing to put money- dedicated or not- into a
 >      China communication costs fund
 >out of which those PTT- costs within China may be payed.
 >Our chinese friends estimate for the average costs
 >         1.500 Yuan/month and university
 >corresponding to about
 >           300 US$/month and university.
 >If anybody is willing to join this activity or has some other ideas, please
 >contact me under "zorn@ira.uka.de"
 >Regards
 >Werner Zorn
 >
 >Prof. W. Zorn Uni Karlsruhe
-----------------------------------------------------------------------------
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 Sat Feb  9 09:58:59 1991
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.64/5.10) with SMTP id AA22250; Sat, 9 Feb 91 09:57:56 -0500
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 0545; Sat, 09 Feb 91 09:57:10 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 1876;
 Sat, 09 Feb 91 09:57:05 EST
Date:         Sat, 9 Feb 91 07:50:57 MST
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: Some consideration for design of Chinese encoding standard
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
Status: RO

I've condensed Ed Lai's considerations and added a few things.  Its a
little fuzzy, so please tell me if I missed anything or have
something wrong.

1. Encoding must be 7-bit ASCII printable characters.

   This is for those nodes/backbones that still can't transmit 8-bit
   characters.  Also avoids control characters that might be
   interpreted as commands by modem or other software.

2. Encoding must be transparent to any system or software it passes
   through with the exception of software designed to interpret it.

   No matter what system the text passes through, there must be no
   special interpretation of the contents of the text except by
   programs specifically designed to deal with the encoding method.
   There must also be no loss of text due to any special
   interpretations.

3. Encoding must accommodate on-line/batch processing transparently.

   With respect to on-line display, the user should not have to know
   that any conversion is occuring while displaying, editing, entering
   text.

   With respect to batch processing, the user should never need to
   explicitly interact with any conversion occuring in a batch
   process (i.e. batch printing, batch conversion and archiving,
   etc.).

4. Encoding must be interpreted in the same way in any environment.

   The hardware and software being used should in no way require
   special handling of the text other than what is needed to
   differentiate the encoded text from other text.  This must be
   consistent for any machine/program being used.


Other thoughts on encodings, editing and input method interactions
with editors:

   A. Editing text

      Use of HZ and zW with terminals seems to work quite well.  But they
      seem to bog down in an editing environment.  Here's another
      view (of course I may be misunderstanding why the encodings are
      a problem in editing).

      An example:

      Assume we have a file that has been encoded using the HZ system
      (no special preference for HZ, just for example).

      An editor would convert the text to 8-bit GB when reading it in.
      This is easy because HZ encoding is easily recognized in a text
      file.  Even mixed 8-bit GB and HZ is easy to detect in a text file.

      While the user is in an editing session, the text is 8-bit GB
      internally.  When the time comes to write the text out, the user
      can specify whether 8-bit GB or HZ output is desired or use a
      default output encoding.  This collides somewhat with
      consideration number 3 above.  But if the user works in one
      encoding most of the time, its not much of a problem.

      Actual input methods for Chinese could produce either 8-bit GB or
      HZ format text, and any conversions needed could easily be hidden
      from the user.

      The output encoding can be determined automatically, with the
      editor assuming HZ output because the input file was in HZ format
      or 8-bit GB because the input file was 8-bit GB.  If a mixed 8-bit
      GB and HZ file was read in, the last encoding detected would
      determine the output encoding.  If the user desires a different
      output format, they can choose it from a menu, set it with a
      keystroke, or in the case of programmable editors, set it with a
      function.

      The costly process here is the conversion.  If the conversion is
      limited to the beginning and ending of an editing session, it
      should work reasonably well with PC and Mac systems.  Input of
      Chinese is another matter.

   B. Input method interactions with programs

      One idea that seems to be taking hold in the X11 environment, is
      the idea of an input method process that is separate from the
      application.  The idea is that no matter which application you are
      using, a special key press or menu choice pops up the input
      method process for use, grabbing the keyboard away from the
      application.  All of the input is done with this special
      process, and certain keystrokes or menu selections send the
      results to the application.  If the application is designed
      right, it almost feels like you are doing the input in the
      application directly.  Of course, some keystrokes are special to
      the application, so an easy method of switching keyboard control
      is needed, or if both the input method and application are
      designed right, the application specific keystrokes pass through
      the input method to the application.

      Once again, any conversion of encodings during the input stage
      can be hidden in either or both the input method and the
      application.  If the application is designed right, it can tell
      the input method what encoding to use and no conversion needs to
      take place.

Well, enough of my long-winded, early morning thoughts.  I hope people
will comment on or correct these ideas as they wish.
-----------------------------------------------------------------------------
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 Sat Feb  9 11:53:05 1991
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.64/5.10) with SMTP id AA22739; Sat, 9 Feb 91 11:52:32 -0500
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 0586; Sat, 09 Feb 91 11:51:37 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 2498;
 Sat, 09 Feb 91 11:51:34 EST
Date:         Sat, 9 Feb 91 11:50:34 EST
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:      Re: Some consideration for design of Chinese encoding standard
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
Status: RO

Mark's summary provides a framework for future Chinese software
design and network design.  It is general enough to accommodate
various approaches.  After some revision, it can serve as a Guideline
for future development, I guess.

I TOTALLY agree on most of the points which Mark summarized.
Some very slightly different idea is presented in the following.
My comments are preceded with  "****".

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

> 3. Encoding must accommodate on-line/batch processing transparently.

****  Mostly agree.  (But Mark's point A makes equally good sense
      to me.)

> 4. Encoding must be interpreted in the same way in any environment.

>    The hardware and software being used should in no way require
>    special handling of the text other than what is needed to
>    differentiate the encoded text from other text.  This must be
>    consistent for any machine/program being used.

****  I did not quite understand this.  Maybe Mark is emphasizing
      consistency of the application softwares, or maybe this point
      already resides in some other points in this "guideline" of Mark.

> Other thoughts on encodings, editing and input method interactions
> with editors:
>
>    A. Editing text
>
>       The output encoding can be determined automatically, with the
>       editor assuming HZ output because the input file was in HZ format
>       or 8-bit GB because the input file was 8-bit GB.

**** This part is quite nice.

>       If a mixed 8-bit
>       GB and HZ file was read in, the last encoding detected would
>       determine the output encoding.  If the user desires a different
>       output format, they can choose it from a menu, set it with a
>       keystroke, or in the case of programmable editors, set it with a
>       function.

**** It seems to me that this part is unnecessarily too complicated.
     How can such a messy mixture occur at first place?  As an
     alternative, we may change our policy to prohibit such mixtures.

>    B. Input method interactions with programs

**** This is the idea of modular design, (or object-oriented programming),
     Am I right?

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

I am learning a lot these days from pioneer experts like Mark, Yagui, Ed,
Stephen, Dorothy and others.  I haven't made my mind straight yet.
But I found the major considerations in my mind are compatible with
this Guideline summarized by Mark.

Thank you very much.

-- Rupert Zhu
   University of Waterloo

From CCNET-L@uga.cc.uga.edu Sat Feb  9 12:22:19 1991
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.64/5.10) with SMTP id AA22855; Sat, 9 Feb 91 12:21:56 -0500
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 0608; Sat, 09 Feb 91 12:21:26 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 2702;
 Sat, 09 Feb 91 12:21:20 EST
Date:         Sat, 9 Feb 91 10:18:28 MST
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: Some consideration for design of Chinese encoding standard
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
In-Reply-To:  <9102091649.AA08351@kythera>
Status: RO

Rupert Zhu writes:
 >
 > > 4. Encoding must be interpreted in the same way in any environment.
 >
 > >    The hardware and software being used should in no way require
 > >    special handling of the text other than what is needed to
 > >    differentiate the encoded text from other text.  This must be
 > >    consistent for any machine/program being used.
 >
 > ****  I did not quite understand this.  Maybe Mark is emphasizing
 >       consistency of the application softwares, or maybe this point
 >       already resides in some other points in this "guideline" of Mark.
 >

You're right.  The point is made in other places.  Sometimes I get a
little out of hand :-)

 >
 > >       If a mixed 8-bit
 > >       GB and HZ file was read in, the last encoding detected would
 > >       determine the output encoding.  If the user desires a different
 > >       output format, they can choose it from a menu, set it with a
 > >       keystroke, or in the case of programmable editors, set it with a
 > >       function.
 >
 > **** It seems to me that this part is unnecessarily too complicated.
 >      How can such a messy mixture occur at first place?  As an
 >      alternative, we may change our policy to prohibit such mixtures.
 >

I would vote to assume/require that the text should be in one encoding
only.

 > >    B. Input method interactions with programs
 >
 > **** This is the idea of modular design, (or object-oriented programming),
 >      Am I right?
 >

Yes.  Depending on how it is implemented it could be looked at in
either way.  In the X11 environment, this idea tends to look like an
object-oriented approach when the input method is made part of an
application and modular design if the input method is made into a
separate program that "talks" with the application.

I would like to say thanks to Rupert for not giving up on the encoding
idea easily.  I think that in the past, jobs, school work and other
considerations :-) have stopped a serious effort towards working on an
acceptable 7-bit standard.  Thanks to Rupert, I am becoming really
interested in this effort again!  The trick now is to keep it going.
-----------------------------------------------------------------------------
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 Sat Feb  9 12:35:14 1991
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.64/5.10) with SMTP id AA22891; Sat, 9 Feb 91 12:35:01 -0500
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 0620; Sat, 09 Feb 91 12:34:32 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 2818;
 Sat, 09 Feb 91 12:34:30 EST
Date:         Sat, 9 Feb 91 10:32:15 MST
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:      ISO/IEC DIS 10646 info relating to Chinese
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
Status: RO

Here's the section from the ISO/IEC DIS 10646 draft that talks about
the Chinese standard being worked on:

        9. Basic Chinese Plane

        ...

        NOTE: The Chinese national body is in the process of revising
        and consolidating it's national standards.  It is expected
        that the new Chinese standard will be completed by the time of
        IS [International Standard] publication.  It will be
        identified in this clause [9].  This standard will include all
        the characters from GB 2312, GB 12345, GB 7589, GB 7590 and
        CNS 11643.


** I added the items in square brackets for clarification.

I will be gone from Feb. 15 to Feb. 24, but when I return, I will
check with ISO/IEC to see if I can get my hands on a draft of the new
Chinese standard when it is released for public comment.
-----------------------------------------------------------------------------
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 Sat Feb  9 13:50:16 1991
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.64/5.10) with SMTP id AA23095; Sat, 9 Feb 91 13:48:48 -0500
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 0832; Sat, 09 Feb 91 13:47:45 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 4729;
 Sat, 09 Feb 91 13:47:42 EST
Date:         Sat, 9 Feb 91 13:43:00 EST
Reply-To: yawei%UCS.INDIANA.EDU@uga.cc.uga.edu
Sender: Chinese Computing Network <CCNET-L%UGA.BITNET@uga.cc.uga.edu>
From: yawei%UCS.INDIANA.EDU@uga.cc.uga.edu
Subject:      Re: Some consideration for design of Chinese encoding standard
Comments: To: ccnet-l <ccnet-l@uga.cc.uga.edu>
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
Status: RO

I do not quite understand the part of Mark's summary about
editors.

If the editor is running on my mainframe account, and I am
connected to it using a terminal which does the conversion,
then anything that ever reaches the mainframe account is
in our 7-bit codes (zW or HZ or whatever). The editor only
sees this 7-bit code, so of course it will save its files
in this format as well.

If the editor is running on my local CCDOS environment, then
it will be using whatever internal code your local environment
uses. It can be CCDOS's internal code, or it can be something
more compatible with our 7-bit code. (It's perfectly ok if
a version of CCDOS is written that only uses our 7-bit codes.)

If the local editor uses internal codes that are different
from our 7-bit codes, then the conversion occurs when we
upload it to the mainframe account. The conversion process
can be transparently incorporated into the upload/download
protocols.

yawei
aka Ya-Gui Wei

From CCNET-L@uga.cc.uga.edu Sat Feb  9 14:02:04 1991
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.64/5.10) with SMTP id AA23149; Sat, 9 Feb 91 14:01:55 -0500
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 0847; Sat, 09 Feb 91 14:01:19 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 4850;
 Sat, 09 Feb 91 14:01:16 EST
Date:         Sat, 9 Feb 91 13:58:38 -0500
Reply-To: 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:      GB standard for traditional characters?
Comments: To: ccnet-l@uga.cc.uga.edu
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
Status: RO

Ed Lai writes:

> I heard that there is a GB standard defined in Mainland
> China that is very close to the one we normally see, but
> have some extra code defined to alleviate the n-to-1 mapping
> problem between traditional and simplified character. If
> possible we should try to be able to accomdate this broader
> GB.

This sounds great.  Does anybody know anything more about
this, or where to get detailed information?  The normal GB is
fine except for one big problem, lack of support for
traditional characters.  I think any Chinese character coding
standard that can't handle traditional characters is doomed
for international use, because the majority of Chinese outside
the PRC prefer traditional characters.

From CCNET-L@uga.cc.uga.edu Sat Feb  9 16:38:27 1991
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.64/5.10) with SMTP id AA23885; Sat, 9 Feb 91 16:38:08 -0500
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 1046; Sat, 09 Feb 91 16:37:46 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 6190;
 Sat, 09 Feb 91 16:37:40 EST
Date:         Sat, 9 Feb 91 16:35:59 EST
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:      Re: Some consideration for design of Chinese encoding standard
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
Status: RO

Thank you too, Mark.

I am thinking to start from a small scale.  We have less than 30
universities in Canada.  I am at a position to recommend to
Federation of Chinese Students in Canada for a practical plan of
establishing Chinese text network connecting every university.
The text flow in this network will be very low. (One Chinese
text file in every two weeks.)

Beside the pure scientific aspect, there are also practical concerns
in my mind.  At the user end, the number one concern is a good editor
(and screen and printer drivers built around the editor).  And also
what kind of machine is most popular, (if I am unable to provide
support to all kinds of machines).  And finally, how easy and how
trouble-free the method is to non-expert users.

It seems what in my mind may not be the best from pure scientific
point of view, but may be a fairly practical one at current stage.
On the other hand, I wish the network I am trying to build can be
easily upgraded at later time, when better softwares are ready.
That is why I try to learn all these things before I finally launch
the project in Canada.

Thank you very much.

-- Rupert

From CCNET-L@uga.cc.uga.edu Sat Feb  9 16:48:26 1991
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.64/5.10) with SMTP id AA23924; Sat, 9 Feb 91 16:47:40 -0500
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 1054; Sat, 09 Feb 91 16:46:07 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 6278;
 Sat, 09 Feb 91 16:45:47 EST
Date:         Sat, 9 Feb 91 16:41:41 EST
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:      Test Report
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
Status: RO

I know a trouble node for a long time, that is, the MTS machine at UBC.
(An IBM mainframe.)  I sent out a test and asked a friend at UBC to
forward it back to me.  The result is:

Three characters were changed:
  [  --->  CR  (ASCII 13)
  ]  --->  Y
  ^  --->  5

All other printable ASCII characters were transmitted correctly.
(Back quota and back slash did not cause trouble.)

-- Rupert

--------------------------------------------------
TEXT I SENT OUT:

  !  "  #  $  %  &  '  (  )  *  +  ,  -  .  /  0  1  2  3  4  5  6  7  8  9
  :  ;  <  =  >  ?  @  A  B  C  D  E  F  G  H  I  J  K  L  M  N  O  P  Q  R
  S  T  U  V  W  X  Y  Z  [  \  ]  ^  _  `  a  b  c  d  e  f  g  h  i  j  k
  l  m  n  o  p  q  r  s  t  u  v  w  x  y  z  {  |  }  ~

TEXT I RECEIVED BACK:

  !  "  #  $  %  &  '  (  )  *  +  ,  -  .  /  0  1  2  3  4  5  6  7  8  9
  :  ;  <  =  >  ?  @  A  B  C  D  E  F  G  H  I  J  K  L  M  N  O  P  Q  R
  S  T  U  V  W  X  Y  Z    \  Y  5  _  `  a  b  c  d  e  f  g  h  i  j  k
  l  m  n  o  p  q  r  s  t  u  v  w  x  y  z  {  |  }  ~

From CCNET-L@uga.cc.uga.edu Sun Feb 10 02:14:43 1991
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.64/5.10) with SMTP id AA25751; Sun, 10 Feb 91 02:13:14 -0500
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 1570; Sun, 10 Feb 91 01:47:45 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 0882;
 Sun, 10 Feb 91 01:47:41 EST
Date:         Sat, 9 Feb 91 22:10:37 CST
Reply-To: "J. Ding" <B366JDX%UTARLVM1.BITNET@uga.cc.uga.edu>
Sender: Chinese Computing Network <CCNET-L%UGA.BITNET@uga.cc.uga.edu>
From: "J. Ding" <B366JDX%UTARLVM1.BITNET@uga.cc.uga.edu>
Subject:      How to make it rolling?
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
Status: RO

Like Rupert said, I also learnt a lot from the previous discussion about an
ideal Chinese input/edit/encode/transfer/print system. Yes, if all the ideas
get realized, it's a powerful software package to be used in network environ-
ment. Coming with the nice picture is the tough question: how to make the baby
growing?

Apparantly we are not talking about normal word processing stuff which already
has its own market and brokers. With market support, the pure input/edit/print
functions are getting well developed with many people's tremondous work. That
means we should focus on the network flowing of Guo Biao Chinese(I emphasize
Guo Biao because the Big5 seems quite well ahead in this area with effort of
Hong Kong and Taiwan hackers).

It will be ideal if the current big Gou Biao makers(like CCDOS) come with a
comprehensive package to satisfy network/e-mail enthusiatists. But I don't
think they are convinced to do it now while there are few voices ask for it.

Although we have enough knowledgable people to make excellent programs, a good
software package like we have discussed still need market support. If we really
want to push the project, we have two blocks to go: 1) develop some simple
package without market support; 2). generate user needs for future market.

Developing network package has two options at current stage. 1) Building on one
of the commercial packages, like Yagui's zW program on GuoBiao CCDOS and Pai
Chou's Taipei-100 on Taiwan Chinese DOS. This approach will be the easiest if
the package we select already dominates the market. Unfortunately, it is not
the case among current GuoBiao world. We will find it tremondously difficult
if we ask the users(in our case, most are Chinese students) to pay money for
something they haven't found out much use. In the worse cases, you are talking
about asking someone to throw away his nice BYX package to pay for a CCDOS.

Another option is what I said develop an "independent" freeware. It will be
nice if it has all the functions that we need. But I don't think it is practica
l. I suggested to first develop a real time terminal emulator for reading only.
And create convertion batch for CCDOS/BYX to complement the input/print work.
The case becomes: if you just want to read, get it for free, you can still have
some fun. If you want to write something yourself or want to print it out, well
, you have to pay the buxs. It will both satisfy the current CCDOS & BYX users.
Even within a small scale and low information flow like Rupert's environment,
it is still a better way(my oppinion) to get started. I assume that you want
it get larger and larger.

Through this way I'm expecting to get more people start to involve into the
Chinese software market if we can give them enough fun through reading: for
example, through Chinese Version CND, Chinese BBS, Chinese visa/tax database,
etc. Until its usefulness get recognized will not the big progress be achieved.

The domestic software market failed to be set up due to the copyright tragedy.
Its serious damage on the domestic software development will prevent China from
hiTech for a long time. If we can take advantage of US market incentive to get
something done, we will save people in China tremendous time and money to work
on this. And equally important, we can make much use of it here too.

While we have many good experts give technical details, I just try to find out
an operational plan to proceed.

Jian Ding
Computer Support Specialist                   B366JDX@UTARLVM1
Library -- U. Texas at Arlington              B366JDX@UTARLVM1.UTA.EDU

From CCNET-L@uga.cc.uga.edu Sun Feb 10 02:15:56 1991
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.64/5.10) with SMTP id AA25764; Sun, 10 Feb 91 02:14:28 -0500
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 1737; Sun, 10 Feb 91 02:12:07 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 1395;
 Sun, 10 Feb 91 02:12:04 EST
Date:         Sun, 10 Feb 91 02:07:00 EST
Reply-To: yawei%UCS.INDIANA.EDU@uga.cc.uga.edu
Sender: Chinese Computing Network <CCNET-L%UGA.BITNET@uga.cc.uga.edu>
From: yawei%UCS.INDIANA.EDU@uga.cc.uga.edu
Subject:      RE: How to make it rolling?
Comments: To: b366jdx <b366jdx%utarlvm1.bitnet@uga.cc.uga.edu>
Comments: cc: ccnet-l <ccnet-l@uga.cc.uga.edu>
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
Status: RO

I like JD's idea from a very different perspective.

As I said, I have a set of routines for displaying CC on
several PC video systems. (I discontinue the project because
I dwasn't sure how to proceed with the input part.) If
someone can tell me if there's a complete set of public
domain fonts available, I may be able to work it into
a dumb-terminal viewer.  (I remembered Ricky Yeung has
something archived somewhere, but I have not been keeping
up with this.)

The viewer can support 'zW' or 'HZ' or both.

The fonts would need to be in GB order.

Ya-Gui

From CCNET-L@uga.cc.uga.edu Sun Feb 10 03:20:57 1991
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.64/5.10) with SMTP id AA25906; Sun, 10 Feb 91 03:19:21 -0500
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 1819; Sun, 10 Feb 91 03:17:26 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 1982;
 Sun, 10 Feb 91 03:17:12 EST
Date:         Sun, 10 Feb 91 01:09:18 MST
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: How to get it rolling?
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
Status: RO

yawei%UCS.INDIANA.EDU writes:
 >
 > As I said, I have a set of routines for displaying CC on
 > several PC video systems. (I discontinue the project because
 > I dwasn't sure how to proceed with the input part.) If
 > someone can tell me if there's a complete set of public
 > domain fonts available, I may be able to work it into
 > a dumb-terminal viewer.  (I remembered Ricky Yeung has
 > something archived somewhere, but I have not been keeping
 > up with this.)
 >
 > The viewer can support 'zW' or 'HZ' or both.
 >
 > The fonts would need to be in GB order.
 >

I have made all of the X11 Chinese fonts freely available by anonymous
ftp from crl.nmsu.edu [128.123.1.14] in pub/chinese/.  Its very simple
to convert the X11 fonts into CCDOS format.

The X11 fonts are in BDF format, which is an ASCII format describing
the bitmaps using hex digits.

I have written a program to convert arbitrary raw bitmap fonts (i.e.
CCDOS) into X11 BDF fonts, so I could write one to convert the BDF
font into a raw bitmap font.  I believe there are a number of good
fonts available for the Mac already, but if people want the X11 fonts
in Mac format, I could write a program to do that if someone could
give me information on the structure of the Mac 2-byte bitmap fonts.


There is some information I need about the CCDOS format first: does
anyone know if CCDOS fonts have width and height information at the
beginning of the font?
-----------------------------------------------------------------------------
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 Sun Feb 10 04:22:23 1991
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.64/5.10) with SMTP id AA26057; Sun, 10 Feb 91 04:21:21 -0500
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 1874; Sun, 10 Feb 91 04:20:51 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 2377;
 Sun, 10 Feb 91 04:20:48 EST
Date:         Sun, 10 Feb 91 02:15:08 MST
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: How to get it rolling?
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
Status: RO

 "J. Ding" writes:

 >
 > Although we have enough knowledgable people to make excellent
 > programs, a good software package like we have discussed still need
 > market support. If we really want to push the project, we have two
 > blocks to go: 1) develop some simple package without market support;
 > 2). generate user needs for future market.
 >

This may evolve into something that is marketable, but I would like to
state that my personal belief is that it needs to be freely available
or Public Domain.

Reasons:
  1. This gives a larger number of people a chance to improve and
     upgrade the software.

  2. Larger numbers of people would be using the software, so bug
     fixes and enhancements would be available much faster.  With more
     people using it, the chances are better that someone can answer
     questions about the software faster.

  3. Even if the software is copyrighted by the authors, the copyright
     can be chosen to allow the software to be used for commercial
     programs.  Everyone wins.  We poor students :-) would get a
     useful set of software to use, *FREE*, and people who want
     make *BUX* can make arrangements with the authors to use the
     software in commercial products.

Going the route of freely available software is slower than designing
software for commercial purposes, but I personally find the rate of
development acceptable, especially if its free.

 >
 > Developing network package has two options at current stage. 1)
 > Building on one of the commercial packages, like Yagui's zW program on
 > GuoBiao CCDOS and Pai Chou's Taipei-100 on Taiwan Chinese DOS. This
 > approach will be the easiest if the package we select already
 > dominates the market. Unfortunately, it is not the case among current
 > GuoBiao world. We will find it tremondously difficult if we ask the
 > users(in our case, most are Chinese students) to pay money for
 > something they haven't found out much use. In the worse cases, you are
 > talking about asking someone to throw away his nice BYX package to pay
 > for a CCDOS.
 >

I think this a very reasonable approach.  Because the effort has
already been made and the authors know about the problems involved.
They are now "expert systems" :-)  Plus, being a poor student, I
don't like spending money for something I won't fully use :-)

(I'm pretty sure Taipei-100 is freely available.  I'm not sure about
 Ya-gui's zW system.  Ya-gui, can you set me straight on this?)
-----------------------------------------------------------------------------
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 Sun Feb 10 11:15:02 1991
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.64/5.10) with SMTP id AA27375; Sun, 10 Feb 91 11:14:21 -0500
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 2314; Sun, 10 Feb 91 11:12:42 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 5499;
 Sun, 10 Feb 91 11:12:40 EST
Date:         Sun, 10 Feb 91 11:12:04 -0500
Reply-To: 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:      RE: How to make it rolling?
Comments: To: ccnet-l@uga.cc.uga.edu
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
Status: RO

Ya-Gui <yawei@ucs.indiana.edu> writes:

> I have a set of routines for displaying CC on
> several PC video systems. (I discontinue the project because
> I dwasn't sure how to proceed with the input part.) If
> someone can tell me if there's a complete set of public
> domain fonts available, I may be able to work it into
> a dumb-terminal viewer.
>
> The viewer can support 'zW' or 'HZ' or both.
>
> The fonts would need to be in GB order.

I hope Ya-Gui goes ahead with this project.  It is exactly what is
needed for a convenient, inexpensive news/e-mail system using
simplified Chinese characters.  Ya-Gui's viewer would allow people to
read news/e-mail on any PC without a process of downloading,
converting, etc.

Those who want to post news or send e-mail would still have to edit or
create their files using an ASCII/GuoBiao editor, then run a very
simple program to convert to HZ or ZW.  These conversion programs are
freely available now (BASIC and C programs for the PC or Mac, a C
program for Unix).  The editors are also readily available -- Byx 1.1
(inexpensive shareware) for the PC, CXterm/Celvis (free) for
Unix/X-Window/OpenWindow.

By the way, here are some basic facts about HZ, ZW, and CCDOS that may
not have been mentioned here recently.  If you already know this
stuff, skip the rest of this message.

1. HZ and ZW are 7-bit file formats.  Both use only printable ASCII
characters and therefore can be transmitted by e-mail (except they
will be slightly damaged if transmitted through non-ASCII machines,
such as IBM mainframes using EBCDIC).  Both allow a mixture of Chinese
and English text.  Chinese is in 7-bit GuoBiao, English is in plain
ASCII, and the files contain simple codes to distinguish and switch
between the two kinds of text.

2.  The CCDOS file format is an 8-bit format, also allowing a mixture
of Chinese and English.  Chinese is in 8-bit GuoBiao, English is in
plain ASCII (7-bit), so there is no need for special codes to
distinguish the two.  (If you try to transmit one of these files over
e-mail, the high bits will be stripped, so you will be left with
something like an HZ file but with no codes to distinguish between
Chinese and English.  The codes could be inserted by hand in most
cases, thus producing an HZ file.  But it would be more convenient to
transmit the file in HZ form to begin with.)

3.  Please keep in mind the distinction between the CCDOS file format
and the CCDOS operating system extensions for the PC.  The CCDOS
operating system costs money and is tied to particular hardware.  The
CCDOS file format is free and hardware-independent and is the standard
used by most GB-based software (Byx, Chinese Wordstar, Celvis, CXterm,
Chtex, Poor Man's Chinese TeX, etc.)

4. The HZ and ZW file formats are free, as is the software for
converting between HZ, ZW, and CCDOS format.  The conversion software
is extremely simple, since all it has to do is add or remove high bits
and remove or add control codes.

5.  HZ and ZW are currently *not* widely used, but they are close
cousins of the CCDOS format, which *is* very widely used.

6.  In the ZW format, each line of text must be either all Chinese or
all English.  In HZ, you can mix Chinese and English on the same line.
In this respect, HZ is a little better than ZW.

7.  HZ files often have a tilde character (~) at the beginning of a
line, and so cannot be redirected to the Berkeley Unix /usr/ucb/mail
program in "standard input" mode.  This is a minor disadvantage of HZ.

From CCNET-L@uga.cc.uga.edu Sun Feb 10 11:45:43 1991
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.64/5.10) with SMTP id AA27455; Sun, 10 Feb 91 11:44:03 -0500
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 2331; Sun, 10 Feb 91 11:43:39 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 5897;
 Sun, 10 Feb 91 11:43:36 EST
Date:         Sun, 10 Feb 91 09:45:08 CST
Reply-To: "J. Ding" <B366JDX%UTARLVM1.BITNET@uga.cc.uga.edu>
Sender: Chinese Computing Network <CCNET-L%UGA.BITNET@uga.cc.uga.edu>
From: "J. Ding" <B366JDX%UTARLVM1.BITNET@uga.cc.uga.edu>
Subject:      Re: How to get it rolling?
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
In-Reply-To:  Your message of Sun, 10 Feb 91 02:15:08 MST
Status: RO

      Mark said:
> >
> > Although we have enough knowledgable people to make excellent
> > programs, a good software package like we have discussed still need
> > market support. If we really want to push the project, we have two
> > blocks to go: 1) develop some simple package without market support;
> > 2). generate user needs for future market.
> >
>
>This may evolve into something that is marketable, but I would like to
>state that my personal belief is that it needs to be freely available
>or Public Domain.
>
       I agree. But the "future market" I used include all GuoBiao based
software. Such a market is badly needed for promoting the CHinese software
development. If we Chinese want to catch up the HiTech in short time, we
should have a mechanics to utilize all resources(include a few bux from
poor students) to support all Chinese software development.
      However for the network packages, I hope they could be made free to
initiate the market. If there are enough useful information flowing on the
network, people will start to realize the importance of Chinese software.
And it is beginning of "Chinese Computing/Information Era".
      It will be a great contribution if we have enough people on this list
have the same belief as Mark's to work together to produce a good network
freeware. I personally like to share part of the work, and also be available
to generate/collect Chinese Information Source to flow on the network.


> > Developing network package has two options at current stage. 1)
> > Building on one of the commercial packages, like Yagui's zW program on
> > GuoBiao CCDOS and Pai Chou's Taipei-100 on Taiwan Chinese DOS. This
> > approach will be the easiest if the package we select already
> > dominates the market. Unfortunately, it is not the case among current
> > GuoBiao world. We will find it tremondously difficult if we ask the
> > users(in our case, most are Chinese students) to pay money for
> > something they haven't found out much use. In the worse cases, you are
> > talking about asking someone to throw away his nice BYX package to pay
> > for a CCDOS.
> >
>
>I think this a very reasonable approach.  Because the effort has
>already been made and the authors know about the problems involved.
>They are now "expert systems" :-)  Plus, being a poor student, I
>don't like spending money for something I won't fully use :-)
>
     I think I may not have made my point clear. If we build the freeware on
a commercial software basis, it is not REALLY FREE. People have to buy that
software first. Say, if you want to use Taipei-100 which is free, you have to
buy the Chinese DOS first. Exactly like Mark said, many poor students won't
buy ANY Chinese software unless they find it useful. That's why I suggested to
develop a "COMPLETELY FREE" package to satisfy the users. If we have enough
human source to make this independent package cover everything(input/edit/
print/transfer), it will certainly create a happy world. If not, we can
start from a small package.
     Such a package is very promising since Yagui and Mark and others already
had much execellent basic work laid down. Once we decide a encoding method,
we are ready to generate the codes. I hope Yagui and Mark could coordinate
the job and let others know what work needs to be shared. It will be ideal
if major codes come out from one or two people to eliminate the compatibility
problem and possible copyright dispute. There are some other work could be
shared by the others. I am looking forward to joining the team work and doing
whatever I could.

Jian Ding
Computer Support Specialist                   B366JDX@UTARLVM1
Library -- U. Texas at Arlington              B366JDX@UTARLVM1.UTA.EDU

From CCNET-L@uga.cc.uga.edu Sun Feb 10 17:05:18 1991
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.64/5.10) with SMTP id AA28751; Sun, 10 Feb 91 17:04:56 -0500
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 2698; Sun, 10 Feb 91 17:04:18 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 9087;
 Sun, 10 Feb 91 17:04:12 EST
Date:         Sun, 10 Feb 91 17:01:00 EST
Reply-To: yawei%UCS.INDIANA.EDU@uga.cc.uga.edu
Sender: Chinese Computing Network <CCNET-L%UGA.BITNET@uga.cc.uga.edu>
From: yawei%UCS.INDIANA.EDU@uga.cc.uga.edu
Subject:      RE: How to make it rolling?
Comments: To: ccnet-l <ccnet-l@uga.cc.uga.edu>
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
Status: RO

No, the CCDOS fonts don't have anything indicating the sizes.
The first 32 bytes specifies the font for the first GB character,
which is a space. Other characters follow in GB order.

Frequently a few zones following zone 5 or zone 8 are missing.
It seems to be those zones were not defined.

The CCLIB display fonts are 16x16. (I think 16x14 would have
been sufficient.)  The printer fonts are 24x24, with x and y
axes interchanged.

I am going to check around to see what public domain ffonts are
available at varous sites. It's going to be slow.

Ya-Gui Wei

From CCNET-L@uga.cc.uga.edu Mon Feb 11 18:36:00 1991
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.64/5.10) with SMTP id AA06130; Mon, 11 Feb 91 18:35:43 -0500
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 6472; Mon, 11 Feb 91 18:32:11 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 9839;
 Mon, 11 Feb 91 18:32:09 EST
Date:         Mon, 11 Feb 91 17:29:06 CST
Reply-To: "J. Ding" <B366JDX%UTARLVM1.BITNET@uga.cc.uga.edu>
Sender: Chinese Computing Network <CCNET-L%UGA.BITNET@uga.cc.uga.edu>
Comments:     Resent-From: "J. Ding" <B366JDX@UTARLVM1>
Comments:     Originally-From: "J. Ding" <B366JDX@UTARLVM1>
From: "J. Ding" <B366JDX%UTARLVM1.BITNET@uga.cc.uga.edu>
Subject:      Re: Traditional Chinese font in GB format exists
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
In-Reply-To:  Message of Mon,
              11 Feb 91 18:05:58 -0500 from <simpson@MATH.PSU.EDU>
Status: RO

On Mon, 11 Feb 91 18:05:58 -0500 Stephen G. Simpson said:
>A very good question.  It may not be entirely our fault.  Being in the
>PRC, Academia Sinica is quite isolated and hard to communicate with.
>If you know how to reach the Software Institute by e-mail, please ask
>them to join CCNET and start telling us what they are doing.  Or would
>this get them into trouble?

       Good suggestion. But I'm afraid they won't be able to do it. As I
understand they are even charged for receiving mail. So I don't think they
can afford the traffic on this list.

     But if Mr. Xu could contact them, at least let them know there're a
group of people here are good for them to work with. If they want, we may
have a volunteer to regularly contact them, by mail/e-mail or phone. I hope
they could assign someone to be a regular contact person. It's a good
direction for us to go.

Jian Ding
Computer Support Specialist                   B366JDX@UTARLVM1
Library -- U. Texas at Arlington              B366JDX@UTARLVM1.UTA.EDU

From CCNET-L@uga.cc.uga.edu Mon Feb 11 19:40:48 1991
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.64/5.10) with SMTP id AA06423; Mon, 11 Feb 91 19:39:25 -0500
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 6620; Mon, 11 Feb 91 19:38:09 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 1273;
 Mon, 11 Feb 91 19:37:18 EST
Date:         Mon, 11 Feb 91 19:34:34 EST
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:      Reply from Postmaster at UBC
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
Status: RO

After I posted my "Test Report" on transmitting printable ASCII
characters, I repeated the same test with different users at University
of British Columbia, Vancouver.  They all give out the same result,
i.e., three characters are always changed at the MTS machine in UBC.
A friend of mine in UBC reported the problem to the Postmaster there.

In a reply, the Postmaster said that there is nothing he can do.
(Not surprised at all.)

There are a number of UNIX machines as well at UBC.  I also tested
two of them.  The mail is alright when going through a UNIX machine
at UBC.

-- Rupert

--------------------------------------------------------
>From USERJON@UBCMTSG.BITNET Mon Feb 11 22:43 GMT 1991
From: Jon Nightingale <USERJON@UBCMTSG.BITNET>
Subject:  Character translation problems
To: liang@cs.ubc.ca
Cc: rzhu@water

Unfortunately there is no one standard for character translations and
since MTS uses EBCDIC characters there can be problems in converting from
ASCII to EBCDIC.

From CCNET-L@uga.cc.uga.edu Mon Feb 11 19:50:02 1991
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.64/5.10) with SMTP id AA06477; Mon, 11 Feb 91 19:48:56 -0500
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 6676; Mon, 11 Feb 91 19:48:07 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 1596;
 Mon, 11 Feb 91 19:48:01 EST
Date:         Mon, 11 Feb 91 19:46:24 EST
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:      give up CC-DOS
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
Status: RO

CC-DOS softwares are too primitive, not user friendly at all.  No document
or README file is included in the disk.  There are too many versions
produced by too many different vendors.  This often causes big confusion.
I failed to get my CCDOS version work.

BYX seems a better software working on CCDOS file format.

Since Yagui's ZWWATCH.COM is build over CCDOS operating system,
I won't be able to try it on my machine.  Anyway.

-- Rupert

PS: Ya-Gui's comments on CCDOS.
------------------------------------------------
>From yawei@ucs.indiana.edu Mon Feb 11 21:30 GMT 1991
Subject: RE: CC-DOS
To: "rzhu" <rzhu@watmath>
Cc: "b366jdx" <b366jdx%utarlvm1.bitnet@ricevm1.rice.edu>

I collected 3 versions of CCDOS and stop collecting them afterward
(I saw or heard of at least 3 other versions). Ruopeng's version
is somewhat similar to one of my versions which runs on CGA computers,
but it doesn't seem to be the same.

Ruopeng - I thought you have a Monochrome system. If that's the
case CGA softwares won't run on it -- better check those things.

In the version I was referring to, I needed to run a program
called "FILE1" before running "CCCC".  But Ruopeng's disk doesn't
seem to have "FILE1" on it.  Why don't you try some of the other
execultables?

Also, if it goes to drive A:, there are two possiblities: (1)
the program is copy protected and requires a key disk in drive
A, (2) the program probably only runs from drive A: and can't
be loaded into hard disks.

If it is case (1) and you do have a working hard disk, I can help
you to get rid of the key disk requirement.  (Working hard disk
should be "working key disk")

yagui

From CCNET-L@uga.cc.uga.edu Tue Feb 12 23:11:26 1991
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.64/5.10) with SMTP id AA14055; Tue, 12 Feb 91 23:09:59 -0500
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 0452; Tue, 12 Feb 91 23:09:13 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 5146;
 Tue, 12 Feb 91 23:09:10 EST
Date:         Tue, 12 Feb 91 23:07:15 EST
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:      Analysis on Pure GuoBiao Based Schemes
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
Status: RO

                Analysis on Pure GuoBiao Based Schemes
                ======================================

This is a short introductory article.  The experts please skip it.  :-)

Pure GuoBiao is designed to record any Chinese character using a pair
of bytes, each byte being a printable ASCII character (namely, ASCII
characters 33--126).  In theory, this enables the direct transmission
of Chinese text through E-mail (without any encoding).

In pure GuoBiao case, both Chinese text and English text share
the ordinary (7-bit) ASCII characters.  There is a need to distinguish
the English text from Chinese text.  Two solutions have been proposed,
namely, the zW scheme and the HZ scheme.  They both use some special
"escape" symbols to separate the two types of texts.  To ensure safe
transmission, these escape symbols should be printable characters
as well.

zW scheme uses the pair "zW" to be the separator, while the HZ scheme
uses "~{" and "~}" to indicate the start and end of Chinese text.
The symbols adopted by HZ scheme look more meaningful since the
character '~' is a conventional escape character in some well
established systems (like UNIX mail system).  But it risks higher
chance of being misunderstood by some computer systems.  In this
regards, the symbol "zW" is much safer.

Is there any room that one can improve the existing schemes?  The
answer is: YES.  Let's partion the set of all possible combinations
of printable ASCII characters into 94 subclasses, according to the
first byte of each pair.  The pure GuoBiao coding used 79 out of these
94 subclasses (or zones), leaving 15 subclasses unused.  In other words,
94 * 79 == 7426  printable pairs were used by GuoBiao coding.  There
are still 94 * 15 == 1410  printable pairs free for other usage.
(I am posting these 1410 free pairs in a separate message.)

The separators used by zW scheme and HZ scheme were chosen from these
1410 free 2-byte pairs.  In theory, any of these free pairs can serve
as a separator, not only "zW", "~{" and "~}".  But in practice, we
have two criteria:
  (1) The separators should be as meaningful as possible.
  (2) The chance of collision with conventional usages should be
      minimized.

The zW scheme is not perfect in criterion (1), while the HZ
scheme is not perfect with respect to criterion (2).

I am not proposing a new scheme or new approach.  I just try to write
down what I have learned, and make it easier for new comers.  Actually,
I very much appreciate the pioneer work by the developers of zW and HZ
schemes.

-- Rupert Zhu
   Dept of C. & O
   University of Waterloo
================================================================

From CCNET-L@uga.cc.uga.edu Tue Feb 12 23:29:50 1991
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.64/5.10) with SMTP id AA14097; Tue, 12 Feb 91 23:27:33 -0500
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 0533; Tue, 12 Feb 91 23:26:42 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 5479;
 Tue, 12 Feb 91 23:26:37 EST
Date:         Tue, 12 Feb 91 23:23:50 EST
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:      Table of Printable Pairs NOT Used by Pure GuoBiao
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
Status: RO

               Table of Printable Pairs Not Used by Pure GuoBiao
               =================================================

Number of Subclasses:              15
Number of Pairs in Each Subclass:  94
Total Number of Free Pairs:        94 * 15 == 1410

 (!  ("  (#  ($  (%  (&  ('  ((  ()  (*  (+  (,  (-  (.  (/  (0  (1  (2  (3  (4
 (5  (6  (7  (8  (9  (:  (;  (<  (=  (>  (?  (@  (A  (B  (C  (D  (E  (F  (G  (H
 (I  (J  (K  (L  (M  (N  (O  (P  (Q  (R  (S  (T  (U  (V  (W  (X  (Y  (Z  ([  (\
 (]  (^  (_  (`  (a  (b  (c  (d  (e  (f  (g  (h  (i  (j  (k  (l  (m  (n  (o  (p
 (q  (r  (s  (t  (u  (v  (w  (x  (y  (z  ({  (|  (}  (~

 )!  )"  )#  )$  )%  )&  )'  )(  ))  )*  )+  ),  )-  ).  )/  )0  )1  )2  )3  )4
 )5  )6  )7  )8  )9  ):  );  )<  )=  )>  )?  )@  )A  )B  )C  )D  )E  )F  )G  )H
 )I  )J  )K  )L  )M  )N  )O  )P  )Q  )R  )S  )T  )U  )V  )W  )X  )Y  )Z  )[  )\
 )]  )^  )_  )`  )a  )b  )c  )d  )e  )f  )g  )h  )i  )j  )k  )l  )m  )n  )o  )p
 )q  )r  )s  )t  )u  )v  )w  )x  )y  )z  ){  )|  )}  )~

 *!  *"  *#  *$  *%  *&  *'  *(  *)  **  *+  *,  *-  *.  */  *0  *1  *2  *3  *4
 *5  *6  *7  *8  *9  *:  *;  *<  *=  *>  *?  *@  *A  *B  *C  *D  *E  *F  *G  *H
 *I  *J  *K  *L  *M  *N  *O  *P  *Q  *R  *S  *T  *U  *V  *W  *X  *Y  *Z  *[  *\
 *]  *^  *_  *`  *a  *b  *c  *d  *e  *f  *g  *h  *i  *j  *k  *l  *m  *n  *o  *p
 *q  *r  *s  *t  *u  *v  *w  *x  *y  *z  *{  *|  *}  *~

 +!  +"  +#  +$  +%  +&  +'  +(  +)  +*  ++  +,  +-  +.  +/  +0  +1  +2  +3  +4
 +5  +6  +7  +8  +9  +:  +;  +<  +=  +>  +?  +@  +A  +B  +C  +D  +E  +F  +G  +H
 +I  +J  +K  +L  +M  +N  +O  +P  +Q  +R  +S  +T  +U  +V  +W  +X  +Y  +Z  +[  +\
 +]  +^  +_  +`  +a  +b  +c  +d  +e  +f  +g  +h  +i  +j  +k  +l  +m  +n  +o  +p
 +q  +r  +s  +t  +u  +v  +w  +x  +y  +z  +{  +|  +}  +~

 ,!  ,"  ,#  ,$  ,%  ,&  ,'  ,(  ,)  ,*  ,+  ,,  ,-  ,.  ,/  ,0  ,1  ,2  ,3  ,4
 ,5  ,6  ,7  ,8  ,9  ,:  ,;  ,<  ,=  ,>  ,?  ,@  ,A  ,B  ,C  ,D  ,E  ,F  ,G  ,H
 ,I  ,J  ,K  ,L  ,M  ,N  ,O  ,P  ,Q  ,R  ,S  ,T  ,U  ,V  ,W  ,X  ,Y  ,Z  ,[  ,\
 ,]  ,^  ,_  ,`  ,a  ,b  ,c  ,d  ,e  ,f  ,g  ,h  ,i  ,j  ,k  ,l  ,m  ,n  ,o  ,p
 ,q  ,r  ,s  ,t  ,u  ,v  ,w  ,x  ,y  ,z  ,{  ,|  ,}  ,~

 -!  -"  -#  -$  -%  -&  -'  -(  -)  -*  -+  -,  --  -.  -/  -0  -1  -2  -3  -4
 -5  -6  -7  -8  -9  -:  -;  -<  -=  ->  -?  -@  -A  -B  -C  -D  -E  -F  -G  -H
 -I  -J  -K  -L  -M  -N  -O  -P  -Q  -R  -S  -T  -U  -V  -W  -X  -Y  -Z  -[  -\
 -]  -^  -_  -`  -a  -b  -c  -d  -e  -f  -g  -h  -i  -j  -k  -l  -m  -n  -o  -p
 -q  -r  -s  -t  -u  -v  -w  -x  -y  -z  -{  -|  -}  -~

 .!  ."  .#  .$  .%  .&  .'  .(  .)  .*  .+  .,  .-  ..  ./  .0  .1  .2  .3  .4
 .5  .6  .7  .8  .9  .:  .;  .<  .=  .>  .?  .@  .A  .B  .C  .D  .E  .F  .G  .H
 .I  .J  .K  .L  .M  .N  .O  .P  .Q  .R  .S  .T  .U  .V  .W  .X  .Y  .Z  .[  .\
 .]  .^  ._  .`  .a  .b  .c  .d  .e  .f  .g  .h  .i  .j  .k  .l  .m  .n  .o  .p
 .q  .r  .s  .t  .u  .v  .w  .x  .y  .z  .{  .|  .}  .~

 /!  /"  /#  /$  /%  /&  /'  /(  /)  /*  /+  /,  /-  /.  //  /0  /1  /2  /3  /4
 /5  /6  /7  /8  /9  /:  /;  /<  /=  />  /?  /@  /A  /B  /C  /D  /E  /F  /G  /H
 /I  /J  /K  /L  /M  /N  /O  /P  /Q  /R  /S  /T  /U  /V  /W  /X  /Y  /Z  /[  /\
 /]  /^  /_  /`  /a  /b  /c  /d  /e  /f  /g  /h  /i  /j  /k  /l  /m  /n  /o  /p
 /q  /r  /s  /t  /u  /v  /w  /x  /y  /z  /{  /|  /}  /~

 x!  x"  x#  x$  x%  x&  x'  x(  x)  x*  x+  x,  x-  x.  x/  x0  x1  x2  x3  x4
 x5  x6  x7  x8  x9  x:  x;  x<  x=  x>  x?  x@  xA  xB  xC  xD  xE  xF  xG  xH
 xI  xJ  xK  xL  xM  xN  xO  xP  xQ  xR  xS  xT  xU  xV  xW  xX  xY  xZ  x[  x\
 x]  x^  x_  x`  xa  xb  xc  xd  xe  xf  xg  xh  xi  xj  xk  xl  xm  xn  xo  xp
 xq  xr  xs  xt  xu  xv  xw  xx  xy  xz  x{  x|  x}  x~

 y!  y"  y#  y$  y%  y&  y'  y(  y)  y*  y+  y,  y-  y.  y/  y0  y1  y2  y3  y4
 y5  y6  y7  y8  y9  y:  y;  y<  y=  y>  y?  y@  yA  yB  yC  yD  yE  yF  yG  yH
 yI  yJ  yK  yL  yM  yN  yO  yP  yQ  yR  yS  yT  yU  yV  yW  yX  yY  yZ  y[  y\
 y]  y^  y_  y`  ya  yb  yc  yd  ye  yf  yg  yh  yi  yj  yk  yl  ym  yn  yo  yp
 yq  yr  ys  yt  yu  yv  yw  yx  yy  yz  y{  y|  y}  y~

 z!  z"  z#  z$  z%  z&  z'  z(  z)  z*  z+  z,  z-  z.  z/  z0  z1  z2  z3  z4
 z5  z6  z7  z8  z9  z:  z;  z<  z=  z>  z?  z@  zA  zB  zC  zD  zE  zF  zG  zH
 zI  zJ  zK  zL  zM  zN  zO  zP  zQ  zR  zS  zT  zU  zV  zW  zX  zY  zZ  z[  z\
 z]  z^  z_  z`  za  zb  zc  zd  ze  zf  zg  zh  zi  zj  zk  zl  zm  zn  zo  zp
 zq  zr  zs  zt  zu  zv  zw  zx  zy  zz  z{  z|  z}  z~

 {!  {"  {#  {$  {%  {&  {'  {(  {)  {*  {+  {,  {-  {.  {/  {0  {1  {2  {3  {4
 {5  {6  {7  {8  {9  {:  {;  {<  {=  {>  {?  {@  {A  {B  {C  {D  {E  {F  {G  {H
 {I  {J  {K  {L  {M  {N  {O  {P  {Q  {R  {S  {T  {U  {V  {W  {X  {Y  {Z  {[  {\
 {]  {^  {_  {`  {a  {b  {c  {d  {e  {f  {g  {h  {i  {j  {k  {l  {m  {n  {o  {p
 {q  {r  {s  {t  {u  {v  {w  {x  {y  {z  {{  {|  {}  {~

 |!  |"  |#  |$  |%  |&  |'  |(  |)  |*  |+  |,  |-  |.  |/  |0  |1  |2  |3  |4
 |5  |6  |7  |8  |9  |:  |;  |<  |=  |>  |?  |@  |A  |B  |C  |D  |E  |F  |G  |H
 |I  |J  |K  |L  |M  |N  |O  |P  |Q  |R  |S  |T  |U  |V  |W  |X  |Y  |Z  |[  |\
 |]  |^  |_  |`  |a  |b  |c  |d  |e  |f  |g  |h  |i  |j  |k  |l  |m  |n  |o  |p
 |q  |r  |s  |t  |u  |v  |w  |x  |y  |z  |{  ||  |}  |~

 }!  }"  }#  }$  }%  }&  }'  }(  })  }*  }+  },  }-  }.  }/  }0  }1  }2  }3  }4
 }5  }6  }7  }8  }9  }:  };  }<  }=  }>  }?  }@  }A  }B  }C  }D  }E  }F  }G  }H
 }I  }J  }K  }L  }M  }N  }O  }P  }Q  }R  }S  }T  }U  }V  }W  }X  }Y  }Z  }[  }\
 }]  }^  }_  }`  }a  }b  }c  }d  }e  }f  }g  }h  }i  }j  }k  }l  }m  }n  }o  }p
 }q  }r  }s  }t  }u  }v  }w  }x  }y  }z  }{  }|  }}  }~

 ~!  ~"  ~#  ~$  ~%  ~&  ~'  ~(  ~)  ~*  ~+  ~,  ~-  ~.  ~/  ~0  ~1  ~2  ~3  ~4
 ~5  ~6  ~7  ~8  ~9  ~:  ~;  ~<  ~=  ~>  ~?  ~@  ~A  ~B  ~C  ~D  ~E  ~F  ~G  ~H
 ~I  ~J  ~K  ~L  ~M  ~N  ~O  ~P  ~Q  ~R  ~S  ~T  ~U  ~V  ~W  ~X  ~Y  ~Z  ~[  ~\
 ~]  ~^  ~_  ~`  ~a  ~b  ~c  ~d  ~e  ~f  ~g  ~h  ~i  ~j  ~k  ~l  ~m  ~n  ~o  ~p
 ~q  ~r  ~s  ~t  ~u  ~v  ~w  ~x  ~y  ~z  ~{  ~|  ~}  ~~

=============================== END OF TABLE ==================================

From CCNET-L@uga.cc.uga.edu Thu Feb 14 19:13:45 1991
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.64/5.10) with SMTP id AA27406; Thu, 14 Feb 91 19:12:35 -0500
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 8643; Thu, 14 Feb 91 19:11:24 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 9973;
 Thu, 14 Feb 91 19:11:19 EST
Date:         Thu, 14 Feb 91 18:09:15 CST
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:      Pure GB, etc
Comments: To: CCNET-L@uga.cc.uga.edu
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
Status: RO

There have been some misunderstandings in the `pure GB' and the `popular GB'
discussions.  In fact,  GB 2312 just defines the coding of the 14 bits.
Together with the two "first" bits,  it can be used as G0, G1, G2,
and G3 sets with four unique ESC sequences.  So using 01, 10 or 11 in the
two "first" bits does not mean violating the GB coding.  The CCDOS method
is actually using the G3 set without the standard ESC sequence.

Owing to the practical computer market situation and the low efficiency of
using standard ESC sequences,  people tend to forget every code set has
a unique ESC sequence.  If all the machines and applications had used
some mechanisms to recognize different ESC sequences, we would not have had
all these problems.  However,  their speed would be much lower if they use
various code sets frequently.

As a special case,  for the computer networking,  we have to compromise
with the market situation.  If all the network protocols strictly conform to
ISO/IEC OSI standards,  then all the transmitting messages will go through
the ASN.1 coding at the sender's side and the ASN.1 decoding at the receiver's
side.  All the current problem will be disappeared.  Of course, that will be
a long story.  Thus it is highly worthwhile to target the current problems of
the Chinese character transmission.


Jian-Xun Ding
Department of Computer Science
Texas A&M University

BTW,  Happy New Year!

From CCNET-L@uga.cc.uga.edu Sun Jan  6 00:18:49 1991
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.64/5.10) with SMTP id AA21565; Sun, 6 Jan 91 00:18:26 -0500
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 4578; Sun, 06 Jan 91 00:15:49 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 6381;
 Sun, 06 Jan 91 00:15:48 EST
Date:         Sun, 6 Jan 91 00:19: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:      RE: net transfer encoding
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
Status: RO

Besides UUencoding, a more recent and less widely known scheme is
XXencoding. Unlike UUE, XXE permits use of lower-case alpha
characters; however, it does not use many non-alphanumeric characters,
and its files thus survive network transfer better. (No "^" for
example.)

The reason even some Ascii files become corrupted is the default
tranlation protocols some of the mainframes use. (EBCDIC for example is
implemented in several different ways and performs some unrequested
translation.) If you're certain that the net path you use travels only
VMS Vaxes, you might expect safe transfer; however, your file may well
pass through IBM VM systems and Unix machines, with unreliable
results. XXencoding is probably the safest scheme to date.

Simtel has Richard E. Mark's latest UUE program, UUREM413.ZIP. With
the -x switch it will XXencode your files; even without the switch it
will detect and decode XXencoded files. An earlier version, UUREM316
also had this capability.

Be sure to set your download filetype (in Kermit, Procomm) to Ascii
for downloading UU- or XXencoded files.

From day@ucs.indiana.edu Sat Jan 26 00:50:10 1991
Received: from rose.ucs.indiana.edu by sirius.ctr.columbia.edu (5.64/5.10) with SMTP id AA18004; Sat, 26 Jan 91 00:50:04 -0500
Date: 26 Jan 91 00:50:00 EST
From: day@ucs.indiana.edu
Subject: RE: net transfer encoding
To: "yjj" <yjj@sirius.ctr.columbia.edu>
Status: RO

If you can get a copy of Richard E. Mark's UUE programs, they also 
allow XXencoding/decoding. The name on BBS lists is UUREM413.ZIP 
(latest version); UUREM316.ZIP also has the -x switch to XXencode. You 
don't have to use the -x switch to XXdecode; it autodetects XXencoded 
files and uses the right algorithm. It's Public Domain. Simtel ought 
to have it if you can't find it elsewhere. 
	(ftp WSMR-SIMTEL20.ARMY.MIL) 
There was a UUEXE402.ZIP dated 900525 in the PD1:<MSDOS.FILUTL> 
directory in December; they may hav a more recent version by now.
	Dorothy Day


From CCNET-L@uga.cc.uga.edu Sat Mar  9 19:38:19 1991
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.64/5.10) with SMTP id AA23644; Sat, 9 Mar 91 19:37:46 -0500
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 3251; Sat, 09 Mar 91 19:34:42 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 5629;
 Sat, 09 Mar 91 19:33:43 EST
Date:         Sat, 9 Mar 91 19:32:22 EST
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:      Encoding Schemes
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
Status: RO

Yan Yongxin proposed a simple and very natural encoding scheme for
converting Binary into ASCII, with a expansion ratio of 1:2.  His
scheme is to use a pair of HEX numbers to record an 8-bit byte.
After every 39 bytes being recorded, he puts in a '\n'.
This scheme is not bad, provided that ratio is not our major
concern.  (Chinese files are usually small.)

                 COMPARISON CHART

                            Characters Used       Ratio        Safety

ATOB/BTOA                    85  (33--117)        4:5          fair
UUENCODE/UUDECODE            64  (33--96)         3:4          fair
XXENCODE/XXDECODE            64  (+-0-9A-Za-z)    3:4          very good
Natural Scheme (Yan)         16  (0-9A-F)         1:2          very good

Besides these four schemes, the utility disk will also contain
zW <---> CC-DOS
HZ <---> CC-DOS
etc.

-- Rupert

From CCNET-L@uga.cc.uga.edu Mon Mar 11 10:51:43 1991
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.64/5.10) with SMTP id AA03093; Mon, 11 Mar 91 10:51:24 -0500
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 9700; Mon, 11 Mar 91 10:49:52 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 0906;
 Mon, 11 Mar 91 10:49:37 EST
Date:         Mon, 11 Mar 91 10:48:31 EST
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:      limit on global data
Comments: To: PC_Group@watmath.waterloo.edu
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
Status: RO

I have a small C program (15 lines) which have to use two arrays as
extern variables, each of size 50 KB.  The Turbo C compiler allows
a maximum of 64K extern data (though the limit for automatic variables
can be as large as 1 MB).  Now I have to split this 15 lines
into two files and put one array declaration in each file to get
two 64 KB capacity.

This looks ridiculous.  Does anyone know a way to get around this
without spliting the tiny file into two?   Also, does anyone know
how Microsoft C handle such kind of situation?

Thank you very much.

-- Ruopeng

PS: This is for  GuoBiao <---> BIG5  conversion program.
    I am trying to port Lee and Yeung's UNIX program to PC and
    encountered this trouble.

From CCNET-L@uga.cc.uga.edu Mon Mar 18 00:55:39 1991
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.64/5.10) with SMTP id AA19574; Mon, 18 Mar 91 00:55:27 -0500
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 2066; Mon, 18 Mar 91 00:54:22 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 4441;
 Mon, 18 Mar 91 00:54:20 EST
Date:         Mon, 18 Mar 91 00:53:50 EST
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:      BIG5 Information Needed
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
Status: RO

In the BYX Editor version 1.1, there is a file named GUOBIAO,
which is a complete table of GUOBIAO coding.  Somebody called
it "shifted GuoBiao".  Now I am trying to find similar information
about BIG5 coding.

>From the conversion program of Lee and Yeung, it seems that BIG5
coding also have its high bit set to 1, or at least one byte of
the two has high bit 1.  But a moment ago I checked files in
ahkcus.org site.  They have suffix  .big5, but the contents are
all ASCII characters (in random order).  In other words, the
contents do not have high bit set.  The contents are not in
BTOA format either.  I am confused.   Are there also
"pure BIG5" and "shifted BIG5"  ?

-- Rupert

From CCNET-L@uga.cc.uga.edu Mon Mar 18 02:04:35 1991
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.64/5.10) with SMTP id AA19739; Mon, 18 Mar 91 02:04:20 -0500
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 2116; Mon, 18 Mar 91 02:02:58 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 4798;
 Mon, 18 Mar 91 02:02:52 EST
Date:         Sun, 17 Mar 91 23:52:21 MST
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: BIG5 Information Needed
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
In-Reply-To:  <9103180555.AA04143@kythera>
Status: RO

Here is some info on the three coding methods in popular use:

A. GB2312-1980 (GuoBiao) PRC standard
   GB is a seven bit standard that requires two bytes per
   character.  It is most often used with the high (most
   significant) bit set on each byte of the character to
   distinguish the Chinese text from other seven bit text.
   The 8-bit usage is used in CCDOS implementations and newer
   versions of the Chinese Macintosh OS.
   CODE RANGE: 0xA1A1-0xFEFE

B. Shift-GB
   Shift-GB is a mixed seven and eight bit coding, with the
   first byte always having the high (most significant) bit set
   to distinguish it from other seven bit text.  Shift-GB was
   used by the Chinese Macintosh OS until recently.
   NOTE: I'm not sure if it is an official standard.
   CODE RANGE: 0x8140-0xAFFC (excluding 0x7F as a second byte)

C. Big5
   Big5 is a mixed seven and eight bit coding, with the first
   byte always having the high (most significant) bit set to
   distinguish it from the other seven bit text.  Big5 is at
   least a de facto standard in places like Hong Kong and
   Taiwan where Traditional Chinese is used.
   NOTE: Rumor has it that Big5 is, or will be a standard in
         Taiwan.  I don't have any facts on this yet.
   CODE RANGE: 0xA140-0xF9FE

Please feel free to send me any corrections to this info.
-----------------------------------------------------------------------------
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 Mon Mar 18 10:38:50 1991
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.64/5.10) with SMTP id AA21727; Mon, 18 Mar 91 10:38:38 -0500
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 2717; Mon, 18 Mar 91 09:52:01 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 9254;
 Mon, 18 Mar 91 09:51:59 EST
Date:         Mon, 18 Mar 91 09:51:06 EST
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:      it is in big5 format
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
Status: RO

Thanks to Mark for pointing out that the files  xxxx.big5  at ahkcus.org
are actually in  BIG5  format.  I used the command  MORE  yesterday
to view those files and only see ASCII bytes.  Today I used VI to
check the file, and found those strange high bytes.

Sorry for this confusion.  :-)

-- Rupert

From CCNET-L@uga.cc.uga.edu Tue Mar 19 09:04:37 1991
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.64/5.10) with SMTP id AA29089; Tue, 19 Mar 91 09:04:23 -0500
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 6686; Tue, 19 Mar 91 09:02:18 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 2798;
 Tue, 19 Mar 91 09:02:16 EST
Date:         Tue, 19 Mar 91 09:03:43 EST
Reply-To: Hongde Luo <hongde%MS.UKY.EDU@uga.cc.uga.edu>
Sender: Chinese Computing Network <CCNET-L%UGA.BITNET@uga.cc.uga.edu>
From: Hongde Luo <hongde%MS.UKY.EDU@uga.cc.uga.edu>
Subject:      bgi5 table?
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
Status: RO

OK, we have guobiao table from the disks in byx, can any body tell me how
can we get the similar table for big5? Thanks.

--
************************>>>>    Hongde Luo     <<<<*************************
*  Center for Computational Science | 1320 Nancy Hanks Rd. #5              *
*  University of Kentucky           | Lexington, KY 40504-1243             *
*  Lexington, KY 40506              | (606)-254-2331 (h) | 257-8741 (work) *
************************>>>> hongde@ms.uky.edu <<<<*************************

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 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 sol.ctr.columbia.edu!usc!sdd.hp.com!think.com!ames!agate!stanford.edu!leland.Stanford.EDU!umunhum!lee Wed Jul  8 23:17:50 EDT 1992
Article: 122 of alt.chinese.text
Xref: sol.ctr.columbia.edu alt.chinese.text:122 soc.culture.china:61602
Newsgroups: alt.chinese.text,soc.culture.china
Path: sol.ctr.columbia.edu!usc!sdd.hp.com!think.com!ames!agate!stanford.edu!leland.Stanford.EDU!umunhum!lee
From: lee@umunhum.stanford.edu (Fung Fung Lee)
Subject: New software release - HZ 2.0
Message-ID: <1992Jul8.051147.18619@leland.Stanford.EDU>
Keywords: chinese, hanzi, HZ, zW, GB
Sender: Fung Fung Lee ~{@n7c7e~}
Organization: Stanford University
Date: Wed, 8 Jul 92 05:11:47 GMT
Lines: 63
Status: RO


This is a software release announcement - HZ 2.0

  The HZ package 2.0 contains the following major changes:

  hz2gb 2.0, zw2hz 2.0

  It also includes the HZ standard document itself as a .hz file.
  This file also demonstrates how the escape sequences are encoded.

  The new utilities are now available on the ftp site "ahkcus.org" as
  (ftp as user anonymous with no need of a password)
  ahkcus.org: src/unix/HZ-2.0.tar.Z

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

  hz2gb 2.0: convert a HZ file to a GB (HGB/SGB) file

  The HZ specification does not dictate how to convert invalid HZ files,
  just as the definition of a programming language usually does not specify
  how a compiler should handle illegal programming constructs.
  The error recovery procedure of this HZ decoder was designed after
  examination of the conversion errors reported by hz2gb 1.1 of some of the
  "HZ" files posted on the news group alt.chinese.text.  I suspected that 
  most of the errors occured due to improper manual insertion of escape
  sequences, and/or using invalid GB codes, such as those for "space" ($2121).
  Such errors should not have occured if the files were first properly edited
  as GB codes, and then converted by an HZ encoder, such as gb2hz (preferably
  with the -t option.)

  To prevent some hanzi displayers from ill behaviour, the output stream
  should be or should be corrected to be valid mixed ASCII and GB sequences.

  The error recovery procedure is by no means unique, and may change in the
  future. Users should NOT regard the error recovery features as part of the
  HZ specification. 


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

  zw2hz 2.0: do a straightforward conversion from a zW file into a HZ file

  This version was an update of version 1.1, because the specification of
  zW had been changed by the original authors.

  Since the set of all zW files is a proper subset of the set of all
  HZ (HGB) files, it is always possible to do perfect translation from
  zW to HZ (HGB); but not vice versa. 
  * HGB - High-bit-set GB, as used in CCDOS, Macintosh System 6.0.x and later.

  As for error handling, I took the lazy approach. For example, if the
  original zW file contains invalid GB codes, they will also show up in
  the output HZ file, and can be detected by "hz2gb -v".

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

Fung Fung Lee ~{@n7c7e~}








From @cuvmb.cc.columbia.edu:CCNET-L@UGA.BITNET Thu May 24 17:19:16 1990
Received: from CUVMB.COLUMBIA.EDU (cuvmb.cc.columbia.edu) by sirius.ctr.columbia.edu (4.1/5.10) id AA14579; Thu, 24 May 90 17:19:12 EDT
Received: from CUVMB.COLUMBIA.EDU by CUVMB.COLUMBIA.EDU (IBM VM SMTP R1.2.1) with BSMTP id 0990; Thu, 24 May 90 17:16:12 EDT
Received: from PUCC.PRINCETON.EDU by CUVMB.COLUMBIA.EDU (Mailer R2.05) with
 BSMTP id 6160; Thu, 24 May 90 17:16:11 EDT
Received: from PUCC.BITNET by PUCC.PRINCETON.EDU (Mailer R2.07) with BSMTP id
 7724; Thu, 24 May 90 17:18:38 EDT
Date:         Thu, 24 May 90 14:01:02 EDT
Reply-To: Ricky Yeung <yeung%CS.WASHINGTON.EDU@cuvmb.cc.columbia.edu>
Sender: Chinese Computing Network <CCNET-L%UGA@cuvmb.cc.columbia.edu>
From: Ricky Yeung <yeung%CS.WASHINGTON.EDU@cuvmb.cc.columbia.edu>
Subject:      BIG5<->GB file conversion program
Comments: To: ccnet-l@uga.uga.edu
To: Multiple recipients of list CCNET-L <CCNET-L@uga>
Status: RO

A file utility to convert between BIG-5 and GB codes is now available for ftp
on june.cs.washington.edu:pub/yeung/HCu.tar.Z

It is the Unix version of the Mac program HC 1.2 (Hanzi Converter).

`HC' converts BIG-5 codes into GB codes (with high bit set),
and vice versa. BIG-5 is a popular hanzi code used in Taiwan,
whereas GB (GuoBiao) is Mainland China's national standard.
GB code (with high bit set) is adopted widely in many systems,
such as CCDOS and Macintosh Chinese Operating System 6.0.3.


-Ricky

From @cuvmb.cc.columbia.edu:CCNET-L@UGA.BITNET Tue May 29 15:26:11 1990
Received: from CUVMB.COLUMBIA.EDU (cuvmb.cc.columbia.edu) by sirius.ctr.columbia.edu (4.1/5.10) id AA24601; Tue, 29 May 90 15:26:07 EDT
Received: from CUVMB.COLUMBIA.EDU by CUVMB.COLUMBIA.EDU (IBM VM SMTP R1.2.1) with BSMTP id 3207; Tue, 29 May 90 15:26:02 EDT
Received: from PUCC.PRINCETON.EDU by CUVMB.COLUMBIA.EDU (Mailer R2.05) with
 BSMTP id 4897; Tue, 29 May 90 15:26:01 EDT
Received: from PUCC.BITNET by PUCC.PRINCETON.EDU (Mailer R2.07) with BSMTP id
 2124; Tue, 29 May 90 15:25:28 EDT
Date:         Tue, 29 May 90 15:20:56 EDT
Reply-To: Ricky Yeung <yeung%CS.WASHINGTON.EDU@cuvmb.cc.columbia.edu>
Sender: Chinese Computing Network <CCNET-L%UGA@cuvmb.cc.columbia.edu>
From: Ricky Yeung <yeung%CS.WASHINGTON.EDU@cuvmb.cc.columbia.edu>
Subject:      BIG5<->GB patch
Comments: To: ccnet-l@uga.uga.edu
To: Multiple recipients of list CCNET-L <CCNET-L@uga>
Status: RO

Folks:

There are some bugs in the BIG5<->GB package (thanks to ygz@cs.purdue.edu).
The patch is in
        june.cs.washington.edu:pub/yeung/HCu.patches.tar.Z
See the file pub/yeung/README for patch instruction.

As a reminder, the directory pub/yeung contains other Chinese software
as well (see pub/yeung/README).

The internet address is 128.95.1.4, ftp login as 'anonymous', use
any password.  Don't forget to set binary mode before transferring.

By the way, if you could set up a permanent ftp site for the Chinese software,
please contact me.  -Ricky

From CCNET-L@uga.cc.uga.edu Wed Jul  8 20:18:06 1992
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.67/5.10) with SMTP id AA19612; Wed, 8 Jul 92 20:17:46 -0400
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 8098; Wed, 08 Jul 92 20:15:37 EDT
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 4924;
 Wed, 08 Jul 92 20:15:34 EDT
Date:         Thu, 9 Jul 1992 10:16:39 +1000
Reply-To: "HONGBO NI ~{D_:H2(~}" <87P0786@CSDVAX.CSD.UNSW.EDU.AU>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: "HONGBO NI ~{D_:H2(~}" <87P0786@CSDVAX.CSD.UNSW.EDU.AU>
Subject:      HZ Specification by F. F. Lee, 1989
Comments: To: ccnet-l@uga.uga.edu
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
Status: RO

From:	IN%"p8770786@cumulus.csd.unsw.OZ.AU"  7-JUL-1992 14:20:34.62
To:	IN%"87p0786@csdvax.csd.unsw.EDU.AU"
CC:
Subj:

Return-path: <p8770786@cumulus.csd.unsw.OZ.AU>
Received: from aix00.csd.unsw.OZ.AU by csdvax.csd.unsw.EDU.AU (PMDF #2556 ) id
 <01GM3M7HMOI88WXIOP@csdvax.csd.unsw.EDU.AU>; Tue, 7 Jul 1992 14:20:23 +1000
Received: by aix00.csd.unsw.OZ.AU (AIX 3.1/UCB 5.61/4.03) id AA06608; Tue,
 7 Jul 92 14:18:33 +1000
Date: 07 Jul 1992 14:18:33 +1000
From: p8770786@cumulus.csd.unsw.OZ.AU (Hongbo Ni)
To: 87p0786@csdvax.csd.unsw.EDU.AU
Message-id: <9207070418.AA06608@aix00.csd.unsw.OZ.AU>
Content-transfer-encoding: 7BIT


		HZ - A Data Format for Exchanging Files of
	      Arbitrarily Mixed Chinese and ASCII characters


		  Fung F. Lee (lee@umunhum.stanford.edu)
			    Stanford Univeristy

			     September 4, 1989


1. Introduction

Most existing computer systems which can handle a text file of arbitrarily
mixed Chinese and ASCII characters use 8-bit codes.  To exchange such text
files through electronic mail on ASCII computer systems, it is necessary to
encode them in a 7-bit format.  A generic binary to ASCII encoder is not
sufficient, because there is currently no universal standard for such 8-bit
codes. For example, CCDOS and Macintosh's Chinese OS use different internal
codes.  Fortunately, there is a PRC national standard, GuoBiao (GB), for
the encoding of Chinese characters, and Chinese characters encoded in the
above systems can be easily converted to GB by a simple formula. (* The ROC
standard BIG-5 is outside the scope of this article.)

HZ is a 7-bit data format proposed for arbitrarily mixed GB and ASCII text
file exchange.  HZ is also intended for the design of terminal emulators
that display and edit mixed Chinese and ASCII text files in real time.


2. Specification

The format of HZ is described in the following.

Without loss of generality, we assume that all Chinese characters (HanZi)
have already been encoded in GB.  A GB (GB1 and GB2) code is a two byte
code, where the first byte is in the range $21-$77 (hexadecimal), and the
second byte is in the range $21-$7E.

A graphical ASCII character is a byte in the range $21-$7E. A non-graphical
ASCII character is a byte in the range $0-$20 or of the value $7F.

Since the range of a graphical ASCII character overlaps that of a GB byte,
a byte in the range $21-$7E is interpreted according to the mode it is in.
There are two modes, namely ASCII mode and GB mode.

By convention, a non-graphical ASCII character should only appear in ASCII
mode.

The default mode is ASCII mode.

In ASCII mode, a byte is interpreted as an ASCII character, unless a '~' is
encountered. The character '~' is an escape character. By convention, it
must be immediately followed ONLY by '~', '{' or '\n' (<LF>), with the
following special meaning.

o The escape sequence '~~' is interpreted as a '~'.
o The escape-to-GB sequence '~{' switches the mode from ASCII to GB.
o The escape sequence '~\n' is a line-continuation marker to be consumed
  with no output produced.

In GB mode, characters are interpreted two bytes at a time as (pure) GB
codes until the escape-from-GB code '~}' is read. This code switches the
mode from GB back to ASCII.  (Note that the escape-from-GB code '~}'
($7E7D) is outside the defined GB range.)

The decoding process is clear from the above description.

The encoding process is straightforward. Note that an (ASCII) '~' is always
encoded as '~~'. A sequence of GB codes is enclosed in '~{' and '~}'.


3. Remarks & Recommendations

We choose to encode any ASCII character except '~' as it is, rather than as
a two byte code, and we choose ASCII as the default mode for the following
reasons. The computer systems we use is ASCII based.  A HZ file containing
pure ASCII characters (i.e. no Chinese characters) except '~' is precisely
a pure ASCII file. In general, the English (ASCII) portion of a HZ file is
directly readable.

The escape character '~' is chosen not only because it is commonly used in
the ASCII world, but also because '~' ($7E) is outside the defined range
($21-$77) of the first byte of a GB code.

In ASCII mode, other potential escape sequences, i.e., two byte sequences
beginning with '~' (other than '~~', '~{', '~\n') are currently invalid HZ
sequences. Hence, they can be used for future extension of HZ with total
upward compatibility.

The line-continuation marker '~\n' is useful if one wants to encode long
lines in the original text into short lines in this data format without
introducing extra newline characters in the decoding process.

There is no limit on the length of a line. In fact, the whole file could be
one long line or even contain no newline characters. Any DECODER of this HZ
data format should not and has no need to operate on the concept of a line.

It is easy to write encoders and decoders for HZ. An encoder or decoder
needs to lookahead at most one character in the input data stream.

Given the current mode, it is also possible and easy to decode a HZ data
stream by scanning backward. One of the implication is that "backspaces"
can be handled correctly by a terminal emulator.

To facilitate the effective use of programs supporting line/page skips such
as "more" on UNIX with a terminal emulator understanding the HZ format, it
is RECOMMENDED that the ENCODER (which outputs in HZ) sets a maximum line
size of less than 80 characters.  Since '\n' is an ASCII character, the
syntax of HZ then automatically implies that GB codes appearing at the end
of a line must be terminated with the escape-from-GB code '~}', and the
line-continuation marker '~\n' should be inserted appropriately. The price
to paid is that the encoded file size is slightly larger.

It is important to understand the following distinction.  Note that the
above recommendation does NOT change the HZ format.  It is simply an
encoding "style" which follows the syntax of HZ. Note that this "style" is
not built into HZ. It is an additional convention built "on top of" HZ.
Other applications may require different "styles", but the same basic HZ
DECODER will always work. The essence of HZ is to provide such a flexible
basic data format for files of arbitrarily mixed Chinese and ASCII
characters.


4. Examples

To illustrate the "stylistic" issue of HZ encoding, we give the following
four examples of encoded text, which should produce the same decoded
output. (The recommendation in the last section refers to Example 2.)

Example 1:  (Suppose there is no line size limit.)
This sentence is in ASCII.
The next sentence is in GB.~{<:Ky2;S{#,NpJ)l6HK!#~}Bye.

Example 2:  (Suppose the maximum line size is 42.)
This sentence is in ASCII.
The next sentence is in GB.~{<:Ky2;S{#,~}~

Example 3:  (Suppose a new line is started whenever there is a mode switch.)
This sentence is in ASCII.
The next sentence is in GB.~
Bye.



Acknowledgement

Edmund Lai was the first one who brought my attention to this topic.
Discussions with Ed, Tin-Fook Ngai, Yagui Wei and Ricky Yeung were very
helpful in shaping the ideas in this article. Thanks to Tin-Fook for his
careful review of the draft and numerous interesting suggestions.

Article 61891 of soc.culture.china:
Path: sol.ctr.columbia.edu!zaphod.mps.ohio-state.edu!sample.eng.ohio-state.edu!purdue!ygz
From: ygz@cs.purdue.edu (Yongguang Zhang)
Newsgroups: soc.culture.china
Subject: reading zW-HZ codes in cxterm
Keywords: cxterm, chinese software, zW, HZ
Message-ID: <19020@ector.cs.purdue.edu>
Date: 11 Jul 92 06:00:52 GMT
Sender: ygz@cs.purdue.EDU
Followup-To: soc.culture.china
Organization: Purdue University Department of Computer Sciences
Lines: 26


As zW and HZ are getting hot in alt.chinese.text, here is a program
"hztty" that you can use to read and write HZ code on cxterm:

	cs.purdue.edu:  pub/ygz/zW-HZ/hztty-0.?.tar.Z

where 0.? is the version number, currently being 0.3.  It is very primitive
and is still under development.  Don't be surprised if you can't make it or
it dumps core.

The good thing is that it is useful and I have tested it on Sun workstations.
You can take advantage of the fast output and powerful Chinese input
in cxterm.  And you don't need to change the code of cxterm.

Keep the bugs & fixes coming.  It's the only way to make it better and better.
I will constantly improve it, although it may take lower priority.

Enjoy zW/HZ on cxterm!

Yongguang Zhang
ygz@cs.purdue.edu


P.S.  Can someone tell me an NNTP site that I can connect and post to a.c.t?
      I can read but cannot post.  Also, I appreciate if someone can forward
      this message to a.c.t.  Thanks.


From @cuvmb.cc.columbia.edu:CCNET-L@UGA.BITNET Tue Feb 13 02:16:48 1990
Received: from CUVMB.COLUMBIA.EDU (cuvmb.cc.columbia.edu) by sirius.ctr.columbia.edu (4.1/5.10) id AA07961; Tue, 13 Feb 90 02:16:42 EST
Received: from CUVMB.COLUMBIA.EDU by CUVMB.COLUMBIA.EDU (IBM VM SMTP R1.2.1) with BSMTP id 5763; Tue, 13 Feb 90 02:16:45 EST
Received: from PUCC.PRINCETON.EDU by CUVMB.COLUMBIA.EDU (Mailer R2.05) with
 BSMTP id 6249; Tue, 13 Feb 90 02:16:44 EST
Received: from PUCC.BITNET by PUCC.PRINCETON.EDU (Mailer R2.06X) with BSMTP id
 7444; Tue, 13 Feb 90 02:16:28 EST
Date:         Mon, 12 Feb 90 21:57:17 PST
Reply-To: Ed Lai <lai%APPLE.COM@cuvmb.cc.columbia.edu>
Sender: Chinese Computing Network <CCNET-L%UGA@cuvmb.cc.columbia.edu>
From: Ed Lai <lai%APPLE.COM@cuvmb.cc.columbia.edu>
Subject:      Re:Encoding Chinese text for e-mail etc
Comments: To: CCNET-L%UGA.BITNET@cunyvm.cuny.edu
To: Multiple recipients of list CCNET-L <CCNET-L@uga>
Status: RO

This is a composite response to all the discussions on this topic.

There are three approaches to text exchanges.
1. We can do straight text exchange.
2. We can just use the file format of a single popular WP.
3. We can came up with a rich text/graphic/multi-media standard.

For number 2, if I am sending a document to someone who I know uses
the same WP, that certainly is not a problem. As far as encoding
is concerned, it is no different from sending any other binary file,
so there is no need to invent anything. But if I want to send to a
large group of people, there is no WP out there that is so popular
that it can serve as an exchange standard. I guess everybody want
the WP they are using to be the standard, so we can hardly agree
on one. So this solution is not viable.

For number 1, people would say it is the lowest common denominator,
and that it is technology backward, and so we should shoot for option
3. My answer to that is that this may very well be true, but before
we arrive this wonderful standard, can we in the mean time use the
good old text standard. I do not want to hold my breath waiting for
the new wonderful standard. After all, what are we doing here right
now? We are exchanging information using simple ASCII text. It may
not be ideal but it can be working now.

Next we have to decide on the internal code. I think in the long
run Unicode is the way to go, but until the software is available
we have to stick with less elegant solution. So we have to stick
with some of the existing standard. Three standards come into mind,
GB, Big-5, CCCII (may be also the telegraph code should be one too,
the problem is that everybody has modified the telegraph code so in
reality there is not a single telegraph code anymore). CCCII being
the superset of every thing else may look like a good candidate.
But it is three byte code which a lot of people (including myself)
do not like. But no exchange table is easily available and it is
not easy to build one since it is so massive. As for GB and Big-5,
when I proposed 'zW' I choose GB over Big-5 for several reasons.
However, I certainly would not say GB is 'art' and Big-5 is a mess.
The choice of characters is certainly more careful in GB than Big-5,
and Big-5 is the standard that everyone seem to love to hate. However
Big-5 at least is consistent in that in both level 1 and 2, it is
arrange in increasing stroke count order (and radical as secondary
key),unlike GB that uses one ordering scheme in one level and
another scheme in another level.

Actually there are good reason that the coding standard should be
based on a traditional char coding because they should be a superset
of the simplfied one. However I pick GB over Big-5 for several in
'zW' for several reasons. Outside Taiwan, GB is used more than
Big-5; to transmit big-5 in 7-bit printable really require 3 bytes;
the pre-decessor of 'zW' was proposed in May 89, the hope was that
there is a more efficient medium to sent Chinese data into China
so the decoding should be trival to do inside China.

Actually 'zW' and other comparable encoding standard in the guts are
very similar: Chinese character is transmitted as pure GB (pure in
the sense that it is as defined in GB and not as modified as it is
being used in any commerial systems). The fact that it is based on
GB does not mean that Big-5 system cannot use it, only that it would
require a bigger encoding/decoding program since a lookup table is
required.

But because the traditional/simplifed mapping is not one to one,
using traditional character with GB is not completely satisfactory.
What we need is an extended GB system, I shall not comment on this
because other people have more expertise on this, I just want to
point out that is what they do in commerical system that can switch
between the traditional/simplified font such as TianMa. This is an
area that is on the 'to-do' list on 'zW' but is put on hold because
of lack of sufficent interest.

Talking about lack of interest it is indeed discouraging to work on
an encoding standard. Workable encoding standard certainly exist and
'zW' is not even the only one. But none of them are being used and
at the same time people lament about that they cannot encode
Chinese in mail/news. There are recently discussion on Chinese
couplets in soc.culture.hongkong, and they are almost unreadable.

One more thing I want to mention is that 'zW' is not designed merely
as an encoding standard, one major goal is that it can also be used
at the same time for Chinese terminals, and it has certainly work
that way, there exists a Chinese terminal emulator that works for
'zW' (and also 'hz').

Paul Hui once forward me an article on how they do it in Japan, I
have forward it to a few other individuals and they all agree it
was intereting. I no longer have that article. It would be
interesting for anyone who still have that to post it to CCNET.


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

From @cuvmb.cc.columbia.edu:CCNET-L@UGA.BITNET Fri Feb 16 18:58:12 1990
Received: from CUVMB.COLUMBIA.EDU (cuvmb.cc.columbia.edu) by sirius.ctr.columbia.edu (4.1/5.10) id AA26550; Fri, 16 Feb 90 18:58:05 EST
Received: from CUVMB.COLUMBIA.EDU by CUVMB.COLUMBIA.EDU (IBM VM SMTP R1.2.1) with BSMTP id 0259; Fri, 16 Feb 90 18:58:01 EST
Received: from PUCC.PRINCETON.EDU by CUVMB.COLUMBIA.EDU (Mailer R2.05) with
 BSMTP id 9780; Fri, 16 Feb 90 18:58:00 EST
Received: from PUCC.BITNET by PUCC.PRINCETON.EDU (Mailer R2.06X) with BSMTP id
 0706; Fri, 16 Feb 90 18:57:49 EST
Date:         Fri, 16 Feb 90 14:44:00 PST
Reply-To: Ed Lai <lai%APPLE.COM@cuvmb.cc.columbia.edu>
Sender: Chinese Computing Network <CCNET-L%UGA@cuvmb.cc.columbia.edu>
From: Ed Lai <lai%APPLE.COM@cuvmb.cc.columbia.edu>
Subject:      Re: UUencoding for file transfer over the net
Comments: To: CCNET-L%UGA.BITNET@cunyvm.cuny.edu
To: Multiple recipients of list CCNET-L <CCNET-L@uga>
Status: RO

The issue is not sending binary file over the net. If that was the only issue
uuencode or any equivalent utitlity would do it. The problem is that different
machine uses different internal code for Chinese so that what is sent over
can only be used by machine of the same type. What we need is something that
is as easily as reading news/mail in English now.

That was why 'zW' was proposed. There has been a report on CCNET that 'zW' is
for Mac only. Nothing can be further from the truth. The history was somewhat
like this. There was a open letter written in Chinese from the Mac and it was
posted in binhex format (the most standard format of unloading Mac File) in
soc.culture.china. With that anyone with the Mac Chinese system should have
no problem looking at it. If the interest is for Mac only, the issue is
completely resolved and no work need to be done. At that time I said we should
give it a wider audience so that it can be read by people with other type of
machine. So I proposed an encoding scheme. Not much happened but a few month
later the topic was brought up again and yawei@ucs.indiana.edu proposed
putting 'zW' in front of each line so that it is easier to use it in terminal
mode and hence the name 'zW'. He had successfully generated article from
CCDOS and Byx (the encoding format actually is closer to CCDOS internal code
than Mac internal code) and I read it on my Mac. I have post document from the
Mac and he read it in his IBM PC. There was a big-5 document posted on the net
and he uudecode for me, I then convert it from big-5 to Mac internal code and
post it back again as 'zW'. Subsequently terminal program was developed so that
the Chinese charater is read directly off the screen. It is not perfect but
it is definitely a workable solution.

On the other issue of how many character are needed for research oriented
Chinese computing. We should look into the CCCII code. Actually it probably
make sense to use CCCII in place of 'zW', but we do not have the conversion
table so it take a lot of effort to make it a practical system. CCCII is used
mainly as exchange code (even PRC are leaning toward using it as exchange
code), but I had been told that there are system in Taiwan that use it directly
(don't ask me which, I don't know). CCCII is the effort of the "Chinese
character analysis group in Taiwan, their major goal is to collect all Chinese
character ever known to have been used, so their collection is bigger than
any dictionary. Also their handling of variant form of the same character is\
interesting. Since they use three byte code they have a lot of code space to
burn, so they assign the variant form in such a way if you want to treat all
variant form as the same character you just need to mask off a few bits and
then all of these variant form would map to the same code. I believe that
there is a US standard that use the same structure as CCCII (but not necessary
the same code table as CCCII) that is used in the East Asian Libraries.

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

From CCNET-L@uga.cc.uga.edu Fri Oct 16 11:07:40 1992
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.67/5.10) with SMTP id AA10749; Fri, 16 Oct 92 11:07:28 -0400
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 0079; Fri, 16 Oct 92 11:05:06 EDT
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.08 PTF008) with BSMTP id
 0071; Fri, 16 Oct 92 11:05:04 EDT
Date:         Fri, 16 Oct 1992 11:05:41 -0400
Reply-To: "(Dave Cottingham)" <dc@COBI.GSFC.NASA.GOV>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: "(Dave Cottingham)" <dc@COBI.GSFC.NASA.GOV>
Subject:      Possible reduction of bandwidth for HXWZ
Comments: To: ccnet-l@uga.cc.uga.edu
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
Status: RO

Perhaps this has been noted before, but I have noticed that the way
HXWZ encodes Chinese for mailing (uuencoded GB) is not the most byte
efficient way possible.  For example, the latest issue, cm9210c, has
about 47.5 Kbytes.  If you translate the GB into HZ (which is ASCII
and therefore mailable), the length is 38.6 Kbytes.  And if you
compress the GB file (using Unix compress) and run it through btoa (a
binary to ascii translator like uuencode, but more efficient) the
resulting file is 32.4 Kbytes.  These lengths include the table of
contents and instructions that are usually prepended to issues of
HXWZ, but do not include the mail headers.  So normalizing the file
sizes to the last method, we have

Method			Relative size
------			-------------
GB + uuencode		1.5
HZ			1.2
GB + compress + btoa	1.0

Of course, ease of use is more important than a reduction in mail
message size, but neither of these alternatives is impossible
(implausible maybe, but not completely impossible).  HZ is pretty
widely understood by printing and viewing programs now, and btoa and a
Unix compatible compress are available for a fair range of computers
and systems.

 - Dave Cottingham
   dc@cobi.gsfc.nasa.gov

From CCNET-L@uga.cc.uga.edu Fri Oct 16 12:58:12 1992
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.67/5.10) with SMTP id AA12223; Fri, 16 Oct 92 12:58:01 -0400
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 1077; Fri, 16 Oct 92 12:56:09 EDT
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.08 PTF008) with BSMTP id
 8856; Fri, 16 Oct 92 12:56:08 EDT
Date:         Fri, 16 Oct 1992 11:55:23 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:      Re: Possible reduction of bandwidth for HXWZ
Comments: To: ccnet-l@uga.bitnet
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
Status: RO

Hi, Shangjie,

]> Method			Relative size
]> ------			-------------
]> GB + uuencode		1.5
]> HZ			1.2
]> GB + compress + btoa	1.0
]>
]>  - Dave Cottingham
]>    dc@cobi.gsfc.nasa.gov
]
]You may miss one point. How about "GB + compress + uuencode"?
]Its size should be same as 1.0 or so.
]Anyway, this will ask HXWZ readers to set up the compress utility.
]
]Shangjie Jin

Good point, Shangjie.

I took cm9210c.gb for testing, and the relative sizes are,

Method			Relative Size
-----------		--------------------
GB+zip+uuencode		0.932
GB+lha+uuencode		0.862

Yes, it saves bandwidth.  But it requires readers to own and operate a
compressor every time.

Here could be the another way to solve the previous problem, by converting
the compressed files into self-extract format before uuencode.

Method			Relative Size
-----------		--------------------
GB+zip+exe+uuencode	1.485
GB+lha+exe+uuencode	0.937

You can see that using lha is still a big save.  However, this also limits
users to a specific machine, for instance, MS DOS or Unix.

Then, to save the bandwidth, HXWZ editors need to distribute more than one
version of package.  And users need to pick one that fit its plateform.  I
think it is a pain. :-)!

Oops, nothing is perfect.

Huijie
======

From xiaofei@acsu.buffalo.edu Sat Dec  5 18:18:54 1992
Received: from lictor.acsu.buffalo.edu by sirius.ctr.columbia.edu (5.67/5.10) with SMTP id AA02679; Sat, 5 Dec 92 18:18:50 -0500
Received: by lictor.acsu.buffalo.edu (4.1/1.35)
	id AA01490; Sat, 5 Dec 92 18:18:30 EST
Date: Sat, 5 Dec 92 18:18:30 EST
From: xiaofei@acsu.buffalo.edu (XiaoFei Wang)
Message-Id: <9212052318.AA01490@lictor.acsu.buffalo.edu>
To: cnd-cm@sdsc.edu, lee@umunhum.stanford.edu, yawei@bronze.ucs.indiana.edu,
        yjj@ctr.columbia.edu
Subject: convertion utilities
Status: RO

Jiang Yuan, yawei, Fung F. Lee, 
and HXWZ editors, 

I have put the following small files in ifcss.org:./incoming directory.

   1 -rw-r--r--  1 xiaofei       674 Dec  5 17:37 convert.readme
  15 -rw-r--r--  1 xiaofei     14481 Dec  5 17:17 gb2hz.exe
  13 -rw-r--r--  1 xiaofei     12465 Dec  5 17:17 hz2gb.exe
  12 -rw-r--r--  1 xiaofei     11315 Dec  5 17:17 zw2hz.exe

I hope it is helpful to those users who wish to use conversion
utilities on msdos machine but don't know how to compile them or do not
have means of compiling them.  Jiang Yuan, please move them to
softare/dos directory if you approve them.

The `convert.readme' says, 

The three files: 

gb2hz.exe ( convert gb to hz )
hz2gb.exe ( convert hz to gb )
zw2hz.exe ( convert zw to hz ) 

are compiled version for msdos machines of the conversion utilities
among GB, HZ and ZW. The source codes and documention can be found
in HZ-2.0.tar.Z package on ifcss.org in the directory software/unix. 

For a brief instruction of how to use them, please download the files to
your computer under binary mode and type `filename -h', where filename is
any one of `gb2hz', `hz2gb' and `zw2hz' that you wish to use. 

Users who wish to obtain more information please refer to the
documention and source codes of the original package mentioned above. 

xiaofei@acsu.buffalo.edu 

From CCNET-L@uga.cc.uga.edu Mon Oct 19 15:54:15 1992
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.67/5.10) with SMTP id AA22574; Mon, 19 Oct 92 15:54:09 -0400
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 5061; Mon, 19 Oct 92 15:52:28 EDT
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.08 PTF008) with BSMTP id
 1032; Mon, 19 Oct 92 15:52:27 EDT
Date:         Mon, 19 Oct 1992 15:45:03 EDT
Reply-To: Undetermined origin c/o Postmaster <POSTMASTER@uga.cc.uga.edu>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
Comments:     <Parser> E: Mail origin cannot be determined.
Comments:     <Parser> E: Original tag data was -> Simon Yeh <csf!syeh>
From: Undetermined origin c/o Postmaster <POSTMASTER@uga.cc.uga.edu>
Subject:      Re: Possible reduction of HXWZ bandwith
Comments: To: CCNET-L@uga.cc.uga.edu
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
Status: RO

This topic has already been discussed before, and there was some sort of
solution been suggested (I assume they were all archived somewhere).
For example, Ya-Gui Wei provided the zW format of HXWZ as an alternative:

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

As to whether the compressed format will make the procedure of reading
hanzi text more diffcult? Not really. For unix box, the following is jsut
what you need (kudo goes to Paul Rutter, author of atob).

-------------------------------> cut here <----------------------------
# This is a shell archive.  Save it in a file, remove anything before
# this line, and then unpack it by entering "sh file".  Note, it may
# create directories; files and directories will be owned by you and
# have default permissions.
#
# This archive contains:
#
#	tarmail
#	untarmail
#
echo x - tarmail
sed 's/^X//' >tarmail << 'END-of-tarmail'
Xif test $# -lt 2; then
X  echo "Usage: tarmail mailpath directory-or-file(s)"
X  exit
Xelse
X  mailpath=$1
X  echo "mailpath = $mailpath"
X  shift
X  echo files = $*
X  tar cvf - $* | compress | btoa | mail $mailpath
Xfi
END-of-tarmail
echo x - untarmail
sed 's/^X//' >untarmail << 'END-of-untarmail'
Xif test $# -ge 1; then
X   atob < $1 | uncompress | tar xvpf -
X   mv $1 /tmp/$1.$$
X   echo tarmail file moved to: /usr/tmp/$1.$$
Xelse
X   atob | uncompress | tar xvpf -
Xfi
END-of-untarmail
exit
-------------------------------> cut here <----------------------------

Of course, if you are uuencoded addict, minor modification can be easily
applied. To further simplify the preprocessing of e-mailed hanzi text,
another shell script can be derived to perform this task automatically,
if your system allows doing so (say, your mailer is sendmail).

Hujie also observed that...
>
> I took cm9210c.gb for testing, and the relative sizes are,
>
> Method			Relative Size
> -----------		--------------------
> GB+zip+uuencode		0.932
> GB+lha+uuencode		0.862
>
> Yes, it saves bandwidth.  But it requires readers to own and operate a
> compressor every time.
>
> Here could be the another way to solve the previous problem, by converting
> the compressed files into self-extract format before uuencode.
>
> Method			Relative Size
> -----------		--------------------
> GB+zip+exe+uuencode	1.485
> GB+lha+exe+uuencode	0.937
>
> You can see that using lha is still a big save.  However, this also limits
> users to a specific machine, for instance, MS DOS or Unix.
>
> Then, to save the bandwidth, HXWZ editors need to distribute more than one
> version of package.  And users need to pick one that fit its plateform.  I
> think it is a pain. :-)!

Not necessarily true, these process can be made quite painless as long as our
honorable hanzi list moderators don't feel uncomfortable to make their list
maintaining scripts a little bit sophisticate (does bitnet's listserv allow
some degree of customization?), and all we subscribers required is just to
specify the desired format (atob/uuencode, tar/zip/lha/compress/binhex,
gb/big5/HZ/zW...whatever) in our subscription requests. By providing more
alternatives to subscribers, many would be benefited, and so does the net
environment (as far as bandwith concerned).


--- Simon
                                           inet: csf!syeh@bcr.cc.bellcore.com
      .&______~*@*~______&.       m        uucp: ...!bellcore!bcr!csf!syeh
    "w/%%%%%%%%%%%%%%%%%%%\w"    mmm***
      `Y""Y""Y"""""Y""Y""Y'      mm*****   "One day our civilization,
   p-p_|__|__|_____|__|__|_q-q   mm**Y**    sublimation or vanity,
_-[EEEEM==M==MM===MM==M==MEEEE]-_.|..|....  will be over."  -- Zhang Ailing

