From CCNET-L@uga.cc.uga.edu Mon Mar 25 09:04:04 1991
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.64/5.10) with SMTP id AA15888; Mon, 25 Mar 91 09:03:59 -0500
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 3157; Mon, 25 Mar 91 09:03:10 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 8136;
 Mon, 25 Mar 91 09:03:09 EST
Date:         Mon, 25 Mar 91 07:01:50 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:      New library available by anonymous ftp
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
Status: RO

crl.nmsu.edu:pub/misc/wcslib.tar.Z

For you C hackers out there, I have finally gotten around to building
a set of tables, macros and functions to support ctype style character
type checking for the Big5, GB 2312, JIS X0208, and KS C5601 codesets,
using the wchar_t (16-bit character) type.  I have added an ISO 8859-1
Latin table at the beginning of each table as well.

Also included are some string functions that work on wchar_t *
strings.

I wrote this library for two main reasons:
1. systems that don't have "locale" support
2. systems that have "locale" support, but don't have enough
   documentation to figure out how to build ctype tables for two-byte
   character codesets (my situation) :-)

I have only tested the Big5 character type checking, so I'm not sure
if the checks work correctly in the other codesets.  Later, I'll be
supplying a testing program that will test all of the macros and
functions for each codeset.

The string functions have been used extensively, so I'm pretty sure
they work OK.

I hacked most of this library out over the weekend, so I haven't had a
chance to supply things like a manual page yet, and the documentation
in the README file is long and a little boring.

Please feel free to fix, change, or enhance the code in the library,
but please inform me about it so I don't fall behind on the code :-)
-----------------------------------------------------------------------------
mleisher@nmsu.edu                      "I laughed.
Mark Leisher                                I cried.
Computing Research Lab                          I fell down.
New Mexico State University                        It changed my life."
Las Cruces, NM                     - Rich [Cowboy Feng's Space Bar and Grille]

From CCNET-L@uga.cc.uga.edu Fri Mar 29 15:07:18 1991
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.64/5.10) with SMTP id AA18265; Fri, 29 Mar 91 15:06:20 -0500
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 8970; Fri, 29 Mar 91 15:04:31 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 4846;
 Fri, 29 Mar 91 15:04:29 EST
Date:         Fri, 29 Mar 91 11:51:03 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:      wctype library update
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
Status: RO

crl.nmsu.edu:pub/misc/wcslib.tar.Z

Once again, for you C hackers, I have significantly updated the wcslib
wctype and wstring library.

Thanks to Eric Bowles of the University of Tokyo pointing out a more
compact table representation, the character type tables are half the
size they used to be.

New features:

Standard C compile time checking is now done (the library can now be
compiled using old style C compilers, Standard C compilers, and C++
compilers).

The ASCII<->two byte ASCII equivalent conversion functions for the JIS
codeset now work like they should.

Added wstrcat and wstrncat to the wstr part of the library.

Removed dependency on the wchar_t type in the wctype part of the
library (everything is now integers).

Except for the default character type table, character type tables are
loaded dynamically when they are required.  They can also be unloaded
if more memory is needed.

Some new functions have been provided to detect characters that are in
some sense pairs (i.e. open and close parentheses and so forth).
These functions work with the two-byte codesets as well.

A character class table that can be added to at runtime (character
classes can be used to detect things like the beginning and end of
words, sentences, and paragraphs and also for things like regular
expressions).

A macro for getting the character class of a character.

A function to add a new character class.

A function to set the character class on a range of positions in a
codeset.

A function that returns the size of the character type table (for bounds
checking when setting character classes).


Things that will be added later:

Manual pages for the library.

A "real" character type table compiler.

Support for the other eight ISO 8859 codesets.

-----------------------------------------------------------------------------
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 Jan 28 18:11:34 1992
Received: from uga.cc.uga.edu by sirius.ctr.columbia.edu (5.67/5.10) with SMTP id AA00569; Tue, 28 Jan 92 18:11:21 -0500
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 3219; Tue, 28 Jan 92 18:10:06 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id 3895;
 Tue, 28 Jan 92 18:10:05 EST
Date:         Tue, 28 Jan 1992 18:10:14 EST
Reply-To: CPS0222%TURBO.KEAN.EDU@uga.cc.uga.edu
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: CPS0222%TURBO.KEAN.EDU@uga.cc.uga.edu
Subject:      letter
To: Multiple recipients of list CCNET-L <CCNET-L@UGA>
Status: RO

Dear Haizi:

    Answer your question.

    2 years ages, I worked on a company in Tawian.  In that time, I used
Clipper complier to generate the program codes.  Sometimes the compiler
didn't understand some special codes(beacuse Chinese system alaways use
special codes.  For example, ET Chinese system use 2 bytes to a word).
So, I wrote another tools to translate codes.

    Actually, I don't know that it is powerful to translate software from
English to Chinese.  I recommand that you should try some software, maybe
you can get the answer.


                                                                Ming

From @UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU Sun Feb 21 10:03:55 1993
Return-Path: <@UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU>
Received: from uga.cc.uga.edu by ifcss.org (4.1/IFCSS-Mailer)
	id AA24559; Sun, 21 Feb 93 10:03:41 CST
Message-Id: <9302211603.AA24559@ifcss.org>
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 0051; Sun, 21 Feb 93 11:00:00 EST
Received: from UGA.BITNET (NJE origin LISTSERV@UGA) by UGA.CC.UGA.EDU (LMail
 V1.1c/1.7e) with BSMTP id 7070; Sun, 21 Feb 1993 10:59:59 -0500
Date:         Sun, 21 Feb 1993 11:01:22 -0500
Reply-To: Jiqian Pan <jipan@GMUVAX2.GMU.EDU>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: Jiqian Pan <jipan@GMUVAX2.GMU.EDU>
Subject:      Re: Chinese parsing in Prolog
Comments: To: npu@AISUN1.AI.UGA.EDU
Comments: cc: ccnet-l@uga.cc.uga.edu
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
Status: RO

What kind of Chinese parsing would you will develop in Prolog?
A possible way to process Chinese language is to make use of
some techniques in processing English, even though there are
some differences between Chinese and English.  You may make
some specific processing to the differences, such as the
combinations of different characters.  So there are a number of
NLP books in Prolog for English, e.g., NLP in Prolog by Gerald
Gazdar and Chris Mellish.

Hope that would be useful to you.

-JP

From @UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU Fri Mar 12 17:59:32 1993
Return-Path: <@UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU>
Received: from uga.cc.uga.edu by ifcss.org (4.1/IFCSS-Mailer)
	id AA15874; Fri, 12 Mar 93 17:59:23 CST
Message-Id: <9303122359.AA15874@ifcss.org>
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 6114; Fri, 12 Mar 93 18:54:00 EST
Received: from UGA.CC.UGA.EDU (NJE origin LISTSERV@UGA) by UGA.CC.UGA.EDU
 (LMail V1.1d/1.7f) with BSMTP id 8385; Fri, 12 Mar 1993 18:53:35 -0500
Date:         Fri, 12 Mar 1993 17:57:25 -0600
Reply-To: Yueheng Xu <yxu@ORION.IT.LUC.EDU>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: Yueheng Xu <yxu@ORION.IT.LUC.EDU>
Comments: To: ccnet-l@uga.cc.uga.edu
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
Status: RO

Dear Netters:

    Thanks goes to Mr. Wang Wei for writing a really good commnet this
time. (3/12/93 )
    As for LianXiang card mentioned in Wang's note, It do modified the
Int 10h , similar to CCDOS. There is no way to display CHinese character
in graphics mode without modifying the int 10h. It was me (now someone
else) wrote the Int 10h for LianXiang Card.
    The LianXiang Card replaces the CGA/EGA/VGA card in text mode, so
it support the Chinese character display up to Direct Video Buffer
Access. With such a card, we can use many popular English editors to
write Chinese article or do programming, you can use the original
PE II, Turbo-Pascal, Turbo-C etc  editors to input Chinese. Compared with many
other Chinese systems, most of them have to use a Chinesenized (HAN4 HUA4)
WordStar or their variations (such as WPS in JingShan system) and
forced the user only works in graphics mode. As for this later matter,
since Borland International released their MicroStar editor's source code
(written in Turbo-Pascal), to write a Chinese editor working only in graphics
mode and keep the functional keyboard mapping
compatible with WordStar is only a modest project.

  Yueheng Xu

From @UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU Sat Mar 13 19:16:00 1993
Return-Path: <@UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU>
Received: from uga.cc.uga.edu by ifcss.org (4.1/IFCSS-Mailer)
	id AA01510; Sat, 13 Mar 93 19:15:46 CST
Message-Id: <9303140115.AA01510@ifcss.org>
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 1425; Sat, 13 Mar 93 20:11:50 EST
Received: from UGA.CC.UGA.EDU (NJE origin LISTSERV@UGA) by UGA.CC.UGA.EDU
 (LMail V1.1d/1.7f) with BSMTP id 5161; Sat, 13 Mar 1993 20:11:48 -0500
Date:         Sun, 14 Mar 1993 11:14:51 +1000
Reply-To: P8770786@CSDVAX.CSD.UNSW.EDU.AU
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: Hongbo Ni <P8770786@CSDVAX.CSD.UNSW.EDU.AU>
Subject:      Re: How to Display Chinese Characters ??? VERY EASY!!!
Comments: To: ccnet-l@uga.uga.edu
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
Status: RO

>And to add to your original question : "How is Chinese Characters displayed on
>the Screen?" I would like to ask you 'experts' :
>
>HOW is it possible to write a SIMPLE program to say 'HELLO WORLD' in Chinese
>?
>
>If this could not be made as easy as ABC, then what's the use of talking about
>Chinese Software Industry and so on? I believe all English programmers start
>with the classic C Language example that simply says 'Hello world'.

1. It is VERY simply if you want your program to run under CCDOS:

#include <stdio.h>
int main()
{
        printf("Hello World (In Chinese, use NJSTAR to edit)\n");
}

2. If you have to run your program without CCDOS, then you have to draw the
   Chinese charcaters and ascii characters by yourself in Graphic mode, it
   is very complicated and time consuming.

   The Good New is I have made the task easy with my newly developed NJSDK
   -- a Chinese Software development Kits based on NJSTAR v2.1+. NJSDK
   includes Chinese Display, input and Printing routines. The Hello world
   example can be as easy as ABC

#include <stdio.h>
#include "njsdk.h"
int main()
{
        int row=10, col=20;

        NJ_init();    /* A - Load Chinese font and dictioaries */
                      /* B - Do what you want to do on the screen */
        NJ_puts("Hello World (in Chinese)", row, col);
        getkey();     /* wait for a key stroke */
        NJ_end();     /* C - back to DOS */
}


I will post more information if more people are interested in NJSDK.


Hongbo Ni
----------------------------------------------------------------------------
P O Box 866                     Tel:   +61-2-399-9876
Kensington NSW 2033             Fax:   +61-2-399-9876 (Auto Detection)
Australia                       Email: P8770786@csdvax.csd.unsw.edu.au
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

From @UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU Mon Mar  1 05:49:49 1993
Return-Path: <@UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU>
Received: from uga.cc.uga.edu by ifcss.org (4.1/IFCSS-Mailer)
	id AA12382; Mon, 1 Mar 93 05:49:31 CST
Message-Id: <9303011149.AA12382@ifcss.org>
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 9833; Mon, 01 Mar 93 06:44:41 EST
Received: from UGA.CC.UGA.EDU (NJE origin LISTSERV@UGA) by UGA.CC.UGA.EDU
 (LMail V1.1d/1.7f) with BSMTP id 2298; Mon, 1 Mar 1993 06:44:40 -0500
Date:         Mon, 1 Mar 1993 06:44:35 -0500
Reply-To: hubo@IFT.FHG.DBP.DE
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: Bo HU <hubo@IFT.FHG.DBP.DE>
Organization: FHG
Comments: To: Yueheng Xu <yxu@ORION.IT.LUC.EDU>
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
In-Reply-To:  <Classification and Techniques of Chinese Character System on
              DOS*>
Status: RO

I think that it is important to point out that there is a fourth kind
of compatibility besides the ones mentioned in in your very informative article
:

(Video) Memeoy Access Compatibility (need not to be DMA/Register compatible)

On a Chinese system of such a level of compatibility, which garantees
not only the DOS and BIOS compatibilities, you can run the most
character orientad western programms for your Chinese applications
without any adaption. As a matter of fact many people use the original
dBASE, FoxPro, MS-WORD and so on for their Chinese data bases and word processi
ng.

In contrary to the register compatiblity the memory access compatibilty
can be achieved by software-only solutions and does not need any
special designed Chinese video card.

Test method: after loading the Chinese system you can run MS-WORD
4.0-5.5 for DOS. The screen display of both Chinese and ASCII
characters can be more slowly then without the Chinese system.


Bo

From @UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU Mon Mar  1 12:51:10 1993
Return-Path: <@UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU>
Received: from uga.cc.uga.edu by ifcss.org (4.1/IFCSS-Mailer)
	id AA19645; Mon, 1 Mar 93 12:50:45 CST
Message-Id: <9303011850.AA19645@ifcss.org>
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 3797; Mon, 01 Mar 93 13:45:19 EST
Received: from UGA.CC.UGA.EDU (NJE origin LISTSERV@UGA) by UGA.CC.UGA.EDU
 (LMail V1.1d/1.7f) with BSMTP id 5158; Mon, 1 Mar 1993 13:45:15 -0500
Date:         Mon, 1 Mar 1993 12:48:53 -0600
Reply-To: Yueheng Xu <yxu@ORION.IT.LUC.EDU>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: Yueheng Xu <yxu@ORION.IT.LUC.EDU>
Comments: To: ccnet-l@uga.cc.uga.edu
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
Status: RO

        Questions and Answers

        Yueheng Xu   yxu@orion.it.luc.edu
        ( March/01/1993 )

1.  Input Method

>Xu Yueheng says the most popular input method for Chinese characters is
>Pinyin.  I remember an article said Wang Weimin's wu-bi-zi-xing covers
>90% of Chinese computing market in the Mainland.  I also heard Cang-jie is the
>most popular system in Taiwan, because it is much faster than PinYin.

>What is the real situation on this matter?  Thanks for information.

>G. Chang

Answers:  No confusion. I say PingYing is most popular because every
          GB Chinese system is equipped with it and 90% of the total
          computer users use it as first choice (Not only casual users,
          Those Chinese system developers like me, with a LXPC Chinese Card,
          can easily inputed my 100 page PhD disseration in a short time
          by using PingYing, we also input all our software document by
          PingYing. In this point, I agree a lot with Dr. Yan Yong-xin).
          Wang Yong-ming's wu-bi-zi-xing may be available (not already
          covered ) on 90% of Chinese computing system if you need to
          install it, but only trained professional typist use it. It may
          be possible to advertise that wu-bi-zi-xin covers 90 % of the
          professional typist's market. (Statistics can be interpretated
          much differently, isn't it ?). As for Cang-jie, I have no idea
          about it, I simply infer that there are much more population in
          mainland than in Taiwan.

          Because no input method is both satisfied by general population
          and professional typist. so any meaningful comparison should be
          made in two different categoryies: 1) for general population;
          2) for typist;

          Just for your information, Mr. Zhang Dao-Zheng, a young technical
          employee in State Department of PRC (also a graduate student of
          Beijing Aeronautical and Aerospace University ) and a former major
          contributor to Wang's wu-bi-zi-xin, has registered his patent of
          Jian-Fan Wu-bi-zi-xin both in China and in USA. This version of
          wu-bi-zi-xin can be used both for the input of simplized chinese
          (Jian-Ti) and for traditional chinese (Fan-Ti). Because Wang's
          version is sensitive to the difference of Jian-Ti / Fan-Ti, I believe
          Zhang's wu-bi-zi-xin may be a hope for the unification of mainland's
          Chinese input and Tainwain's Chinese input methods. Right now, no
          Taiwan Chinese system (like Chinese version of MS-DOS, CWIN, etc. )
          used by people came from mainland simply because we do not know how
          to input and have no ineterst to spend time to learn it.


          Finally, I don't believe any one in CCNET-L will became a professional
          typist in the future for a living, so just stick to any one input
          methos you already familair with, but pay attention to the LianXiang,
          Self-learnning, CiZu, Phrase-input and other intelligent software
          features implemented on a system when the input methods is an issue.
          If you are Chinese system developer, you'd better let your system
          to be able to dynamically load any third party's input method (like
          LXPC, CCDOS 2.13 series has ). If you are an application programmer,
          you don't even have to care anything. Even the key combinations are
          re-definable in LXPC and other systems, thus able to avoid function
          key conflicts with your application program.


2. Library Chinese System and more ...

>    temporarily. And in a few library systems we need makek use of the whole
>    64k range of character set and treat ASCII set as its subset and forget
>    about the confilict and any consequencial compatibility problem. In this
>    case, the library computer system is specially designed and thus not
>    much need for compatability ). The Beijing Library (National Library
>    of China ) use a NEC made system for such kind of job.

>very interesting.  would you please provide more detail about this NEC
>system: when introduced? the detail of coding they are using?

>this will help for me to understand the NEC business.

>thanks in advance.

>yih

  Answer: When I visited Beijing Library before the end of 1991, I saw many
         idle terminals (no power, no connection yet) have been put in some
         reading room since the openning of this new site of the library,
         I asked staff about the system. They told me that this system
         is still under construction yet, it is a gift from NEC and the Chinese
         character set for this system will be 64k. I have no other direct
         information except a later newpaper report about its operation. But
         At the time I visited there, they only use PC and CD-ROM reading
         system like MedLine in some seperated reading room and index-room.
         But no Library-wide book information system is in operation like we
         used in USA universities nowadays.

         The libray of Chinese Academy of Science is a little bit better, all
         the books and patron ID's are now maked by bar code and loan-return
         is processed by a single PC-based system which use Light Pen for
         reading bar code. This system is developed by Hope Computer company
         which is known for its UCDOS chinese character system I mentioned in
         my 01/29/93 article in CCNET-L.  I like to mention here that, Chinese
         students and programmers now in USA can easily contribute a lot to
         mainland China if you have access the source code of any bar-code
         reading related multi-user transaction system like we used here every
         day in Library, Supermarket, Banks, etc.  Together with the field of
         network communication in China, these are two fields that you can
         contribute a lot only with a little effort. This is also a good
         field for programmers to open/market your software business in China.
         Your PC softarware is hard to be copyright protected, but these
         systems never have problem.

3. Chinese code standard

>Finally, I am a little curious about how the government controls
>what type of system is sold on the market. I read on People's Daily
>about the ban on non-standard systems, and now I hear it from
>Mr. Xu again.  Mr. Xu also says this ban is "by law".  Does Mr.
>Xu has more detail about this?  Which Chinese law is being applied
>to this ban, specifically? and How?  Does this ban apply only to
>Chinese character coding, or does it apply to other technologies and
>products as well?  (I can't imagine a law is written to single
>out the character coding standard for protection.)

>I think it is not wise to enforce official standards by law.
>It can only inhibit technological advancement and market competition.
>It takes time for a standard to be formulated and adopted, which
>means it is impossible for a standard to include the latest
>technological advances and innovations. I can understand the
>desire to have systems being compatible with each others, but
>there are other better ways of achieving this, inhibiting
>innovation is too high a price to pay for compatibility.

>  Ya-Gui Wei

  This law may be is an administrative law, it is enforced by import/export
departments, the details may be available by calling Chinese consul nearest
you. It seems to me that this law is primarily used to prohibit the Chinese
system developed in Taiwan to appear in mainland to avoid a multi-code
confusion in mainland China. It saves a lot of conversion questions that
we see every week in CCNET-L. To my understanding, this is not a political
consideration, nor a pre-mature administrative decision, it is based on a
desperately needed economic and technical standardnization consideration. The
standardnization process of Chinese character set system has already past its
4th decades and already existed as a accepted satndard for past 12 yeras.
Now the GB font (16x16, 24x24) are already standardnized and in massively
production as ROM chips and even the interface circuitry of them is in public
domain. In the future, every display panel of a instrument, of a Beeper, of
...... , will probably has such a ROM font built-in. The only complains among
our system developers about the internal coding schem of GB is that, some
Chinese character is identical with some double positioned frame symbol in
128-256 range. It takes more software work to deal with this.


   As for the 7-bit code schem used for ZWDOS, I believe it is a valuable
innovation in the existing Internet community. I don't believe it is the
target of above law. The Internet is said going to extended to mainland
China through a gateway in South Korean. Whether the ZWDOS schem will find
a opportunity to appear in China, I recommend the author of this schem to
contact Prof. Hua-Ling Qian, Institute of Computing Technology, Chinese
Academy of Sciecne, Beijing, 100080, P.R. China as soon as possible. He is
the leader of the Zhong-Guang-Cun network project which is the first
WAN project in China and might be the first back born of Internet to mainland
China. Any practices and experiences accumulated through this project will
probably have decisive influence over the national standard and therefore
the technical law in this field in the future.


4.  Unicode etc.

>Dear Mr. Xu -- I enjoyed reading your article about Chinese DOS that
>was discributed on CCNET.   I wonder if you know anything about the
>knowledge/acceptance/use of Unicode in mainland?  Is the industry there
>prepared or planning to adopt Unicode-based products,  such as a new
>operating system?   I'll appreciate any information about this.
>Thanks,  --  TinKam Ho (tkh@research.att.com)

 Answer: I have no direct information about what is going in government
  policy and the activities of standardnization institute. I only heard about
  Unicode not long time ago and read a MicroSoft document about it yesterday.
  But we programmers are eagerly waiting for big computer and software
  providers such as IBM, DEC, HP, Microsoft to support the Unicode (or other
  Double Byte Character Set, or DBCS )in their standard software in the future,
  not just in the Chinese version of MS-DOS, Chinese version of MS-Windows,
  etc..... If this is supported, there is no special need of Chinese computing
  systems. We then can treat Chinese as another font and our greatest
  programmers in China do not have to spend time in developing so many
  Chinese sytems, instead, we can spend more time to do application
  development.  (althoug this will reduce the importance of our jobs. )


5.  Spelling of PinYin, etc.

Thanks for the Chinese-on-DOS info.
For next time, could you correct your spellings PingYing and ZhuYing to
PinYin and ZhuYin? (I forgot if there was also a ShuangPing which should
be ShuangPin). It might confuse some people.

   Answer: Thanks, you are right.



From @UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU Tue Mar  2 21:26:06 1993
Return-Path: <@UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU>
Received: from uga.cc.uga.edu by ifcss.org (4.1/IFCSS-Mailer)
	id AA22113; Tue, 2 Mar 93 21:26:00 CST
Message-Id: <9303030326.AA22113@ifcss.org>
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 9213; Tue, 02 Mar 93 22:21:26 EST
Received: from UGA.CC.UGA.EDU (NJE origin LISTSERV@UGA) by UGA.CC.UGA.EDU
 (LMail V1.1d/1.7f) with BSMTP id 4059; Tue, 2 Mar 1993 22:21:24 -0500
Date:         Wed, 3 Mar 1993 11:23:43 +0800
Reply-To: guojin@ISS.NUS.SG
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: GUO Jin <guojin@ISS.NUS.SG>
Subject:      banned by law?!
Comments: To: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
Status: RO

Thanks to Mr. Xu Yueheng for the very informative article posted
to CCNET.  I also cann't help adding a line.

To my knowledge, there never be a LAW on Chinese character coding.
Even has no "hong tou wen jian" on that.  No national internal code
standard exists.

In fact, China is always an active actor in the preparation of CJK
code and a supporter of the unicode (unicode got released only
AFTER China's approval!).

The ORIGINAL GB code as a national standard is ONLY for
"information interchange" purpose and nothing to do with computer
processing.  GB in fact is a double-SEVEN-bit standard (GB has no
definition on the 8th bit or you can say the 8th bit is defined as
zero (0).  The original purpose to develop GB IS to "interchange" on
7bit lines!!!  In certain cense, GB is a super-set to ASCII.)

The double-8th-bit-on internal code (unfortunately being
misleadingly named GB code) is in fact only ONE internal code
adopted by the 6th institute in CCDOS.  The earlier version of
CCDOS (BTW, they never stopped developing new versions of CCDOS,
two years ago, they were promoting CCDOS 4.1 to 4.3, and a chief
developer told me privately they even got donation from UNITED
NATIONS for their efforts in promoting and standarizing of
ShuangPin bottom-up from primary school.  Sorry I have no their
recent versions) also accept other two types of internal codes:
first-8th-bit-on and 4-byte-alphabetical-code.  Even today,
many Chinese word processors accept the first-8th-bit-on
internal code.

On China's market, there are always so many "non-standard" Chinese
computer/computing systems.  Just name a few: IBM5550, WANG MVS.

Then, how to express the "inconsistency" with People's Daily?  In
fact, it's on Chinese character FONTS rather than CODES!

More and more Press/publishing house in China now use computer to do
publishing.  To keep the consistency among publishings (and, I
guess, to stop the revival of traditional Chinese characters),
China has published many national characeter fonts standards.  A
"hong tou wen jian" informed all publishing house to use ONLY
standard character fonts and not to use any non-standard (FONTS)
systems for general publishing.

Furthermore, there is a plan (in action?) to BAN any publishing
(computer) system with no standard fonts (you can add any
non-standard fonts 'for artistic purpose').  This plan has raised so
many argues.  First, the national font standard is from human experts
and artists through traditional dot-by-dot drawing on large paper
matrices.  It's well known that Chinese bitmap fonts are so memory
intensive.  Some kind of font compression is necessary for low
price commercial systems.  But the standard asks distortion-free
compression!  (I heard recently that they have allowed up to
certain percentage distortion.)  Second, those systems developed
in Taiwan, a PRC claimed province, are hard (if not impossible )
to enter the mainland market.  It's just a traditional
protection trick widely in use in, for example, western europe.

Any mistakes, pls let me know.  Thanks.

GuoJin

From @UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU Wed Mar  3 10:42:23 1993
Return-Path: <@UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU>
Received: from uga.cc.uga.edu by ifcss.org (4.1/IFCSS-Mailer)
	id AA02720; Wed, 3 Mar 93 10:42:00 CST
Message-Id: <9303031642.AA02720@ifcss.org>
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 3962; Wed, 03 Mar 93 11:36:54 EST
Received: from UGA.CC.UGA.EDU (NJE origin LISTSERV@UGA) by UGA.CC.UGA.EDU
 (LMail V1.1d/1.7f) with BSMTP id 6547; Wed, 3 Mar 1993 11:36:51 -0500
Date:         Wed, 3 Mar 1993 00:03:53 -0500
Reply-To: Wei Wang <14744w19@CPS201.CPS.CMICH.EDU>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: Wei Wang <14744w19@CPS201.CPS.CMICH.EDU>
Subject:      About Mr YH Xu's article
Comments: To: ccnet-l <ccnet-l%uga.bitnet@cmuvm.csv.cmich.edu>
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
Status: RO

Hi, dear fellow CCNETters,

I hope I could comment on Mr Xu's original article. But I've deleted the mail,
so I'll try to remember what I can.


> 1.  Input Method
......

> Answers:  No confusion. I say PingYing is most popular because every
>           GB Chinese system is equipped with it and 90% of the total
>           computer users use it as first choice (Not only casual users,
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
        I don't agree with this. Most (or we can say almost all) machines are
        equipped with QuWei input method too. But you can never say that's the
        most popular input method. Though I don't have the statistics figures,
        but I believe most of the Chinese key-in jobs in main land China is
        done by the damned Wang Ma (WuBiZiXing -- I don't like it!).

......

>           Just for your information, Mr. Zhang Dao-Zheng, a young technical
>           employee in State Department of PRC (also a graduate student of
>           Beijing Aeronautical and Aerospace University ) and a former major
>           contributor to Wang's wu-bi-zi-xin, has registered his patent of
                                                               ^^^^^^^^^^
        Is that a applied patent or registered one? These are two different
        terms.

>           Jian-Fan Wu-bi-zi-xin both in China and in USA. This version of
......

> 2. Library Chinese System and more ...

> >    temporarily. And in a few library systems we need makek use of the whole
> >    64k range of character set and treat ASCII set as its subset and forget
> >    about the confilict and any consequencial compatibility problem. In this
> >    case, the library computer system is specially designed and thus not
> >    much need for compatability ). The Beijing Library (National Library
> >    of China ) use a NEC made system for such kind of job.
>
> >very interesting.  would you please provide more detail about this NEC
> >system: when introduced? the detail of coding they are using?
>
> >this will help for me to understand the NEC business.
>
> >thanks in advance.
>
> >yih
>
>   Answer: When I visited Beijing Library before the end of 1991, I saw many
>          idle terminals (no power, no connection yet) have been put in some
>          reading room since the openning of this new site of the library,
>          I asked staff about the system. They told me that this system
>          is still under construction yet, it is a gift from NEC and the
 Chinese
                                                    ^^^^
        As far as I know, the system is NOT a gift from anybody. The government
        paid for it. Actually, the large Chinese character set was not just
        invented by NEC. It was a draft national standard besides GB2312/80,
        which was often refered to as G0 set. I don't know if the other G1, G2
        G3 sets had become national standards. But they were used in the
        Beijing Library project. They didn't do that just for fun, of course.
        The number of characters used in those books is far beyond what the
        GB2312 can cover. And they have to deal with things like the publica-
        tions from the Hua GuoHeng's reign (Any body remember the second set
        simplified characters published at that time?) Though the time period
        was short, but the publications have to be there for the history. We
        may consider this as an extreme example for setting up a standard too
        casually. That causes a lot of truble for the people who have to deal
        with the standard.

>          character set for this system will be 64k. I have no other direct
>          information except a later newpaper report about its operation. But

......

> 3. Chinese code standard

......

>   This law may be is an administrative law, it is enforced by import/export
         ^^^
        To my knowledge, I'd say there's never been such a law in existance,
        nor an administrative one. People talked about standardizing font
        patterns, but never about the internal coding of Chinese characters.
        Theoretically, the GB2312 is meant to standardize interchange of info-
        mation between systems supporting Chinese. It doesn't deal with
        internal representation of Chinese characters. Actually, people were
        talking about modifying GB2312 or adopting new national standard for
        Chinese character set, when first the TCA code set and then UNICODE got
        attention of the policy makers of China. I see that as a posibility,
        because we all see many contradictions in GB2312. One thing is the
        different character sequencing policies between the class 1 and 2
        characters.

        Back to the law issue, I don't think such a law would make any sense
        in any way. Market has its own rules for the games, right? I don't
        think the guys in Taiwan and Hong Kong can afford not to support GB
        if they want to enter the main land market, simply because it so
        popularly used there.

> departments, the details may be available by calling Chinese consul nearest
> you. It seems to me that this law is primarily used to prohibit the Chinese
> system developed in Taiwan to appear in mainland to avoid a multi-code
> confusion in mainland China. It saves a lot of conversion questions that
> we see every week in CCNET-L. To my understanding, this is not a political
> consideration, nor a pre-mature administrative decision, it is based on a
> desperately needed economic and technical standardnization consideration. The
> standardnization process of Chinese character set system has already past its
> 4th decades and already existed as a accepted satndard for past 12 yeras.
  ^^^^^^^^^^^
        I don't think so. Can you name one who has done Chinese computing on a
        computer in 1953?

......


> 4.  Unicode etc.

......

>  Answer: I have no direct information about what is going in government
>   policy and the activities of standardnization institute. I only heard about
>   Unicode not long time ago and read a MicroSoft document about it yesterday.

        I can tell that the UNICODE and ISO14644(?) have long entered the
        Chinese policy making circle, at least three years ago. Actually China
        is one of the country actively involved in UNICODE beside the US,
        Japan, and South Korea. That also intrigues the discussion about
        modifying GB2312.

>   But we programmers are eagerly waiting for big computer and software
>   providers such as IBM, DEC, HP, Microsoft to support the Unicode (or other
>   Double Byte Character Set, or DBCS )in their standard software in the
 future,
>   not just in the Chinese version of MS-DOS, Chinese version of MS-Windows,
>   etc..... If this is supported, there is no special need of Chinese computing
>   systems. We then can treat Chinese as another font and our greatest
>   programmers in China do not have to spend time in developing so many
>   Chinese sytems, instead, we can spend more time to do application
>   development.  (althoug this will reduce the importance of our jobs. )

        I strongly disagree with what Mr Xu stated in the above section.
        Nobody can afford to wait for such a big event. If China does not
        involve actively in this game, there would be even less share in the
        software market for the Chinese software industry (if we can say there
        is any of them) in the future. UNICODE does Chinese processing a great
        favor since the Chinese people don't have to invent the wheel. But it's
        also a great challenge. If we don't face it actively, we'll lose this
        chance just like we do with chips -- the basic brick for computer
        hardware.


> 5.  Spelling of PinYin, etc.
>
> Thanks for the Chinese-on-DOS info.
> For next time, could you correct your spellings PingYing and ZhuYing to
> PinYin and ZhuYin? (I forgot if there was also a ShuangPing which should
> be ShuangPin). It might confuse some people.
>
>    Answer: Thanks, you are right.
             ^^^^^^^^^^^^^^^^^^^^^

        But you are using the wrong spelling right in this Q&A message.
-------------------------------------------------------------------------------

And I'd like to give my opinion on "compatibility". Mr Xu used this word in
his orginal article many times. But I'd say it's not so appropriate to say
compatible or not with the internal coding of Chinese characters. Compatibility
concerns only the interaction of two systems. And further more, using standard
coding scheme does NOT make one software compatible with the others. It just
make it easier to be compatible. This seems like word game, but actually
compatibility and standardization are two concepts. I've experinced myself of
being restricted to use specific standard, no matter it fitted or not. Say, it
is very hard to use the CCDOS GB coding scheme in a multiple language environ-
ment, which including Latin languages, Arabic, Chinese, Japanese, Korean, and
the traditional Chinese all together. You just have to invent your own wheel,
or you are going to die real hard.

So I'd say what Mr Xu gave us in his orginal article were mostly old craps.
What we need today is probably a real software industry in China. The Chinese
government has to encourage companies, which maybe are not as powerful as
Microsoft, to write software. I don't know how. Maybe just publish a software
protection law is not enough. It has to be enforced. There could be more good
software systems like the FangZheng (HuaGuang) DTP package only after the
industry in China goes into a well-doing up-rising loop. One more important
point is that, we can't do it individually, like we used to do things.

Any comments are welcome. But don't just flame me.

Regards to all.

Wang Wei

From @UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU Wed Mar  3 15:29:54 1993
Return-Path: <@UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU>
Received: from uga.cc.uga.edu by ifcss.org (4.1/IFCSS-Mailer)
	id AA07890; Wed, 3 Mar 93 15:29:43 CST
Message-Id: <9303032129.AA07890@ifcss.org>
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 7096; Wed, 03 Mar 93 16:24:26 EST
Received: from UGA.CC.UGA.EDU (NJE origin LISTSERV@UGA) by UGA.CC.UGA.EDU
 (LMail V1.1d/1.7f) with BSMTP id 3684; Wed, 3 Mar 1993 16:24:23 -0500
Date:         Wed, 3 Mar 1993 13:25:21 PST
Reply-To: Yongxin Yan <yxyan@SIGNUM.MV.US.ADOBE.COM>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: Yongxin Yan <yxyan@SIGNUM.MV.US.ADOBE.COM>
Subject:      Re: banned by law?!
Comments: To: CCNET-L@uga.cc.uga.edu, guojin@ISS.NUS.SG
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
Status: RO

My information seems to support GuoJin's article. I think the font standard
won't stay for long. "GB", however, shall be with us for a long time.

Yan Yong-Xin
***********************************************************************


Thanks to Mr. Xu Yueheng for the very informative article posted
to CCNET.  I also cann't help adding a line.

To my knowledge, there never be a LAW on Chinese character coding.
Even has no "hong tou wen jian" on that.  No national internal code
standard exists.

In fact, China is always an active actor in the preparation of CJK
code and a supporter of the unicode (unicode got released only
AFTER China's approval!).

The ORIGINAL GB code as a national standard is ONLY for
"information interchange" purpose and nothing to do with computer
processing.  GB in fact is a double-SEVEN-bit standard (GB has no
definition on the 8th bit or you can say the 8th bit is defined as
zero (0).  The original purpose to develop GB IS to "interchange" on
7bit lines!!!  In certain cense, GB is a super-set to ASCII.)

The double-8th-bit-on internal code (unfortunately being
misleadingly named GB code) is in fact only ONE internal code
adopted by the 6th institute in CCDOS.  The earlier version of
CCDOS (BTW, they never stopped developing new versions of CCDOS,
two years ago, they were promoting CCDOS 4.1 to 4.3, and a chief
developer told me privately they even got donation from UNITED
NATIONS for their efforts in promoting and standarizing of
ShuangPin bottom-up from primary school.  Sorry I have no their
recent versions) also accept other two types of internal codes:
first-8th-bit-on and 4-byte-alphabetical-code.  Even today,
many Chinese word processors accept the first-8th-bit-on
internal code.

On China's market, there are always so many "non-standard" Chinese
computer/computing systems.  Just name a few: IBM5550, WANG MVS.

Then, how to express the "inconsistency" with People's Daily?  In
fact, it's on Chinese character FONTS rather than CODES!

More and more Press/publishing house in China now use computer to do
publishing.  To keep the consistency among publishings (and, I
guess, to stop the revival of traditional Chinese characters),
China has published many national characeter fonts standards.  A
"hong tou wen jian" informed all publishing house to use ONLY
standard character fonts and not to use any non-standard (FONTS)
systems for general publishing.

Furthermore, there is a plan (in action?) to BAN any publishing
(computer) system with no standard fonts (you can add any
non-standard fonts 'for artistic purpose').  This plan has raised so
many argues.  First, the national font standard is from human experts
and artists through traditional dot-by-dot drawing on large paper
matrices.  It's well known that Chinese bitmap fonts are so memory
intensive.  Some kind of font compression is necessary for low
price commercial systems.  But the standard asks distortion-free
compression!  (I heard recently that they have allowed up to
certain percentage distortion.)  Second, those systems developed
in Taiwan, a PRC claimed province, are hard (if not impossible )
to enter the mainland market.  It's just a traditional
protection trick widely in use in, for example, western europe.

Any mistakes, pls let me know.  Thanks.

GuoJin

From @UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU Fri Mar  5 20:14:42 1993
Return-Path: <@UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU>
Received: from uga.cc.uga.edu by ifcss.org (4.1/IFCSS-Mailer)
	id AA29290; Fri, 5 Mar 93 20:14:12 CST
Message-Id: <9303060214.AA29290@ifcss.org>
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 1565; Fri, 05 Mar 93 21:09:38 EST
Received: from UGA.CC.UGA.EDU (NJE origin LISTSERV@UGA) by UGA.CC.UGA.EDU
 (LMail V1.1d/1.7f) with BSMTP id 5913; Fri, 5 Mar 1993 21:09:36 -0500
Date:         Fri, 5 Mar 1993 20:13:29 -0600
Reply-To: Yueheng Xu <yxu@ORION.IT.LUC.EDU>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: Yueheng Xu <yxu@ORION.IT.LUC.EDU>
Comments: To: ccnet-l@uga.cc.uga.edu
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
Status: RO

Subject:     Response to the criticism of Mr. Wang Wei on 3/3/93
------------------------------------------------------------------
        From: Yueheng Xu  yxu@orion.it.luc.edu

1.

>>  standardnization process of Chinese character set system has already past it
s
>>  4th decades and already existed as a accepted standard for past 12 yeras.
>>  ^^^^^^^^^^^
>        I don't think so. Can you name one who has done Chinese computing on a
>        computer in 1953?

   Answer: Early related works did date back to the 1950's when the public
           telegraphy code for Chinese characters was established (if we do
           not say that this process was dated back to the Qin Dynasty when the
           KANG Xi Dictionary was first compiled, like we say that computer
           history begins from Babbage).

               Similar for PinYin schem, its history begins in 1950's, but we
           implemented it on computer as an input method much later. How
           do we count its history when we want to count its weight of
           influence ?

               Admittedly, the specific statistical researches targetted for
           setting up the GB 2312 was performed in 1970's and the GB 2312 was
           published in 1981. As for this project, there was an interesting
           story: Due to Mr. Lin Biao's name was appeared in nearly
           everyday's newspapers and many other publications in those days,
           the character BIAO was categoried as a high-frequency character,
           although this is not true now.

2.

>       I strongly disagree with what Mr Xu stated in the above section.
        (about my description that our programmers are eagerly waiting for
         big companies to support Unicode in their standard products)
>       Nobody can afford to wait for such a big event. If China does not
>       involve actively in this game, there would be even less share in the
>       software market for the Chinese software industry (if we can say there
>       is any of them) in the future. UNICODE does Chinese processing a great
>       favor since the Chinese people don't have to invent the wheel. But it's
>       also a great challenge. If we don't face it actively, we'll lose this
>       chance just like we do with chips -- the basic brick for computer
>       hardware.

     Answer: I am describing the issue in a viewpoint of programmer, not as
        a policy maker or a advisor of Chinese government. Right now, no
        ordinary programmers in PRC have voting rights on this issue, and
        most of them are just too busy with the software products that will
        be sold 3 month or at most one year later.  I encourage Mr. Wang Wei
        and those who have influence in this matter  do more to promote it.




3.
>>           Just for your information, Mr. Zhang Dao-Zheng, a young technical
>>           employee in State Department of PRC (also a graduate student of
>>           Beijing Aeronautical and Aerospace University ) and former major
>>           contributor to Wang's wu-bi-zi-xin, has registered his patent of
                                                               ^^^^^^^^^^
 >       Is that a applied patent or registered one? These are two different
 >       terms.

>>           Jian-Fan Wu-bi-zi-xin both in China and in USA. This version of
>>  ...

    Answer: The Chinese patent No. 89103862
            The USA patent No.  07/540,491


4.

> ... So I'd say what Mr Xu gave us in his orginal article were mostly
>   old craps.

  Answer: It not sounds so bad to everybody except Mr. Wang Wei.
          Many of the materials are prepared for my friends in Chicago area
          who are working in USA software companies as programmers and need
          information about how to make their current works can be ported to
          Chinese market easily. I believe that my information is pertinent
          and practical (even it is based on experiences before 1992).
          If Mr. Wang Wei have something that is jade compared with my brick,
          try to organize it systematically and post it here instead of just
          finding fault with other contributor. This will do good to this
          network and to your personality development.




From @PUCC.PRINCETON.EDU:OWNER-CCNET-L@UGA.CC.UGA.EDU Tue Mar 16 21:04:02 1993
Return-Path: <@PUCC.PRINCETON.EDU:OWNER-CCNET-L@UGA.CC.UGA.EDU>
Received: from pucc.Princeton.EDU by ifcss.org (4.1/IFCSS-Mailer)
	id AA18200; Tue, 16 Mar 93 21:03:57 CST
Message-Id: <9303170303.AA18200@ifcss.org>
Received: from PUCC.PRINCETON.EDU by pucc.Princeton.EDU (IBM VM SMTP V2R2)
   with BSMTP id 5468; Tue, 16 Mar 93 22:02:05 EST
Received: from PUCC.BITNET (NJE origin LISTSERV@PUCC) by PUCC.PRINCETON.EDU (LMail V1.1d/1.7f) with BSMTP id 3383; Tue, 16 Mar 1993 22:02:05 -0500
Date:         Wed, 17 Mar 1993 13:02:00 +1000
Reply-To: P8770786@CSDVAX.CSD.UNSW.EDU.AU
Sender: Chinese Computing Network <CCNET-L%UGA.BITNET@pucc.Princeton.EDU>
From: Hongbo Ni <P8770786@CSDVAX.CSD.UNSW.EDU.AU>
Subject:      NJSDK will be uploaded to IFCSS.ORD very soon.
Comments: To: ccnet-l@uga.uga.edu
To: Multiple recipients of list CCNET-L <CCNET-L%UGA.BITNET@pucc.Princeton.EDU>
Status: RO

>  I am interested in NJSDK.
>  But , what's "NJSDK"?
>        How to use it ?
>        How can get it ?

NJSDK is a Chinese Software Development Kits based on NJSTAR v2.1 Plus. It
is a C library which takes all the responsibilities to Input, Display and
Printing Chinese (and soon Japanese). Any one who can program in C is able
to develope a Chinese application using NJSDK. NJSDK handles mouse, keyboard
and monitor automatically.

I am preparing the document right now, and I will upload a trial version in
IFCSS.ORG very soon. Watch out CCNET-L list!

Hongbo Ni
------------------------------------------------------------------------------
P O Box 866                             Tel: +61-2-399-9876
Kensington NSW 2033                     Fax: +61-2-399-9876  (auto detection)
Australia                               Email: P8770786@csdvax.csd.unsw.edu.au
------------------------------------------------------------------------------

From @UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU Mon Mar 22 22:36:47 1993
Return-Path: <@UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU>
Received: from uga.cc.uga.edu by ifcss.org (4.1/IFCSS-Mailer)
	id AA19780; Mon, 22 Mar 93 22:36:34 CST
Message-Id: <9303230436.AA19780@ifcss.org>
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 9646; Mon, 22 Mar 93 23:33:00 EST
Received: from UGA.CC.UGA.EDU (NJE origin LISTSERV@UGA) by UGA.CC.UGA.EDU (LMail V1.1d/1.7f) with BSMTP id 6589; Mon, 22 Mar 1993 23:32:58 -0500
Date:         Mon, 22 Mar 1993 23:32:53 -0500
Reply-To: Tan E Ming - guojin <emtan@ISS.NUS.SG>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: Tan E Ming - guojin <emtan@ISS.NUS.SG>
Subject:      WuBiZiXing Research Group of Kelantan
Comments: To: CCNET-L%UGA.BITNET@nusvm.nus.sg
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
Status: RO

I am very glad to received so many e-mails following the e-mail "We are
together". Most of the netters didn't know that there is such "healthy" thing
happening in Malaysia as well.
Since most of them is asking whether the group had published any book
or manual on the "super fast" learning method of WuBiZiXing Input Method, I have
posted the following brief history of the group to CCNET. I hope this will help.


        In 1988, Mr Foo Meng Yen was invited by Chung Cheng Secondary School
(SM Chung Cheng) principal Mr Gun It Gon, to teach 3 teachers and 9 students
from the school, thus establishing the foundation for the set-up of the Kelantan
WuBiZiXing Research Group.

        Two years later, SM Chung Cheng, SM Chung Hwa and Chung Hwa Private
jointly organized with the co-sponsorship from Tong Yong Computer Ltd. Co., the
WuBiZiXing Input Method seminar, intoducing the skill of WuBiZiXing Input Method
to the education institutions and the printing establishments. In order to
facilitate the work load incurred, with the proposal and the support from Dr Foo
Meng How, his elder brother Mr Foo Meng Yen and Mr Gun It Gon, the WuBiZiXing
Research Group of Kelantan was officially established in 21st September 1990.

        The group committee board are as the following :

        Advisors         : Foo Meng How, Foo Meng Yen
        President        : Gun It Gon
        Secretary        : Poh Kim Hee
        Treasury         : Tan Boon Siong
        Commitee members : Chang Swee Cheong, Ng Li Po,
                           Luo Mei Li, Wei Shu Sheng

        Since the setting up of the WuBiZiXing Research Group, the group has
been continuously planning and studying, through various means, among others
through seminars, flash courses and newspapers, vigorously proposing and
recommending the usage of WuBiZiXing Input Method throughout the nation.

        When the group was formed, it embraces a will : To introduce, promote
and integrate the Chinese word-processing software used in preparing and
printing the examination papers by the nation's Chinese language teachers
Thus allowing the teachers to exchange the information and ideas. Therefore,
the group has been putting in great effort promoting and organizing WuBiZiXing
Input Method seminars and flash courses, and had also been invited to various
part of the nation to conduct the flash courses.  Until the end of 1991, the
group had been successfully promoting the skill of WuBiZiXing Input Method
nationwide. These include Batu Pahat, Selangor, Pahang and Trengganu. The
authorities involved or participated are like the academic institutions, Chinese
Commerce Association executive members, Malaysian Chinese Association (MCA)
executive members, Chinese Information Research Center (Hua2 She4 Zi1 Liao4 Yan2
Jiu1 Zhong1 Xin1) and so on.

        1991 August 21st, WuBiZiXing inventor and developer, Prof. Wang Yong
Ming together with the manager, Mr Xu Zhen Lu visited the group, acknowledging
and praising the effort put and the success achieved by the group. On top of
that, the group was also granted the franchise of promoting and distributing
WuBiZiXing 1991 Version (Wang Ma Ver.5.00) and Wang Ma 480 Desktop Publishing
System.

        The next aim of the group is to promote the printing system (da3 yin4
xi4 tong3). The group unanimously agree that WuBiZiXing Input Method and the
printing/ouput of Lian2 Xiang3 Shi4 Han4 Ka3 system must work together due to
the vast applications of Lian2 Xiang3 Shi4 Han4 Ka3.

        The manuals published by the group include :
        WuBiZiXing Index Searching Booklet      (1990 February )
        WuBiHua Index Searching Booklet         (1992 February )
        Chinese Computing Coding Method Manual  (1992 February )

        Please note also that the WuBiZiXing Research Group main objective is
not commercially oriented but rather it is especially for the benefits of the
users of the WuBiZiXing Input Method and for the Chinese information processing
and computing in general.

        Anybody who wish to contribute his/her idea to the group or who shares
the common view could contact the group through the following address :

        WuBiZiXing Research Group of Kelantan
        3597, Jalan Ismail,
        15000 Kota Bharu, Kelantan.
        West Malaysia.
        Tel : 09-783518


emtan
Good luck.

From @UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU Fri Mar 26 01:05:07 1993
Return-Path: <@UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU>
Received: from uga.cc.uga.edu by ifcss.org (4.1/IFCSS-Mailer)
	id AA05045; Fri, 26 Mar 93 01:05:04 CST
Message-Id: <9303260705.AA05045@ifcss.org>
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 1928; Fri, 26 Mar 93 02:02:01 EST
Received: from UGA.CC.UGA.EDU (NJE origin LISTSERV@UGA) by UGA.CC.UGA.EDU (LMail V1.1d/1.7f) with BSMTP id 9976; Fri, 26 Mar 1993 02:02:00 -0500
Date:         Fri, 26 Mar 1993 17:05:20 +1000
Reply-To: P8770786@CSDVAX.CSD.UNSW.EDU.AU
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: Hongbo Ni <P8770786@CSDVAX.CSD.UNSW.EDU.AU>
Subject:      NJSDK - Chinese Software Development Kits uploaded to IFCSS.ORG
Comments: To: ccnet-L@uga.uga.edu
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
Status: RO

Dear netters,

NJSDK shareware v2.1 has been uploaded to IFCSS.ORG. The file is located in
/software/dos/sdk/njsdk21.zip & njsdk21.doc.

For those who know how to program in C, NJSDK is a Chinese software
development kits based on NJSTAR v2.1 Plus. NJSDK is provided as a MS C
library which handles Chinese Input, Display and Printing. Extensive
documentations are provided in text file and in WinWord 2.0 format.

If you donot know it how program in C, there is a Chinese Name and Address
management Program - NJCARD included. You can Dial the phone number through
modem automatically in NJCARD. NJCARD.c is included as an example to show
the developer how to use NJSDK.

'One man's energy is often limited', so I decide to make NJSDK available
to all the programmers and lets everyone make some thing useful.
I hope that many stand-alone Chinese applications will be developed based
on NJSDK. It is recommended that those applications are distributed as
shareware. There are many discussions about shareware in this net. From
my experience, I can tell you that SHAREWARE WORKS if it is a good one.

BTW, I am visiting Florida next monday to help an US company developing
a Chinese character paging system for China. I will mainly stay at Tempa /
St. Petersburg and will visit New York in later stage, If any one want to
discuss with me over there, please email Huijie Chen (chenh@ucs.indiana.edu)
in APRIL to find out my Phone number there. I shell be back in May.

HONGBO NI
-------------------------------------------------------------------------
P O BOX 866                     PHONE/FAX: +61-2-399-9876
KENSINGTON NSW 2033
AUSTRALIA                       EMAIL: P8770786@CSDVAX.CSD.UNSW.EDU.AU
=========================================================================

From @UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU Mon Apr 19 21:29:37 1993
Return-Path: <@UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU>
Received: from uga.cc.uga.edu by ifcss.org (4.1/IFCSS-Mailer)
	id AA27495; Mon, 19 Apr 93 21:29:33 CDT
Message-Id: <9304200229.AA27495@ifcss.org>
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 4589; Mon, 19 Apr 93 22:25:20 EDT
Received: from UGA.CC.UGA.EDU (NJE origin LISTSERV@UGA) by UGA.CC.UGA.EDU (LMail V1.1d/1.7f) with BSMTP id 4426; Mon, 19 Apr 1993 22:25:18 -0400
Date:         Mon, 19 Apr 1993 22:25:13 -0400
Reply-To: Tan E Ming - guojin <emtan@ISS.NUS.SG>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: Tan E Ming - guojin <emtan@ISS.NUS.SG>
Subject:      Dr Foo's e-mail
Comments: To: ccnet-l@uga.cc.uga.edu
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
Status: RO

I have just received an e-mail that I have been waiting for so long.
This may be a good news for those who are interested in trying to
contact Kelantan WuBiZiXing Research Group. The person to contact
is Dr Foo Meng How and I have forwarded his e-mail to me here
for those interested :

> From foo@mhfoo.pc.my Mon Apr 19 23:08:19 1993
> Return-Path: <foo@mhfoo.pc.my>
> Received: from jaring.my by iss.nus.sg (4.1/SMI-4.1)
>       id AA07323; Mon, 19 Apr 93 23:08:05+080
> Received: from mhfoo.pc.my by jaring.my (4.1/SMI-4.1)
>       id AA23915; Mon, 19 Apr 93 23:07:21 MYT
> Received: by rangkom.ism.my (5.60/5.9)
>       id AA29646; Mon, 19 Apr 93 23:07:23 MYT
> Received: by mhfoo.pc.my (UUPC) Mon, 19 Apr 93 22:38:51 MYT
> Date: Mon, 19 Apr 93 22:38:51 MYT
> From: Dr. Foo Meng How <foo@mhfoo.pc.my>
> Message-Id: <51@mhfoo.pc.my>
> To: emtan@iss.nus.sg
> Status: R
>
> 19th April 93
>
> Dear Tan,
>
> I am so impressed with your effort to keep the world informed
> about the little that we are doing in KB. I have been trying
> to find out about E-Mailing since a year ago. This is a new
> facility in Malaysia and it is interesting that I am now able to
> learn more about it to communicate with my children and other
> special groups overseas.
>
> I am still interested in the progress made in Chinese computing.
> There is no doubt in my mine that there is no other race in the
> world which have so many systems created for itself. The Malays need
> to have it's Jawi system developed by the French and the Punjabi
> have the Multilingual Scholar developed for them by a German
> in the US - and they are so much easier to do. I looked at the
> new Chinese Window 3.1 and I am impressed with this race -
> notwithstanding the numerously cultural defects. There is the CD
> containing 50 beautiful Chinese fonts all for Windows and compatible
> with the TTF. What else can one expect ? And we can be proud of this.
> There is no doubt that the race will dominate the world in no time.
>
> The recent improvements in inputs are mainly in the pronunciation
> based methods. With AI included, it is now possible to input SENTENCES
> with reasonable accuracy.
>
> With greater exposure to capitalism and commercialism, there
> will be many new ideas and inventions coming from the 1.2 billions
> in the Mainland.
>
> My details:
>
> FAX: 609-771834
> Internet E-Mail:   foo@mhfoo.pc.my
> Tel: 609-783518 (clinic) or 771834 (house)
>
> I will be demo the E-Mail to the group when I can spare the time.
>
> Dr Foo
>

Hope this help.

emtan
ISS NUS, Singapore.

From @UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU Fri May 21 00:59:03 1993
Return-Path: <@UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU>
Received: from uga.cc.uga.edu by ifcss.org (4.1/IFCSS-Mailer)
	id AA23833; Fri, 21 May 93 00:58:51 CDT
Message-Id: <9305210558.AA23833@ifcss.org>
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 2653; Fri, 21 May 93 01:58:01 EDT
Received: from UGA.CC.UGA.EDU (NJE origin LISTSERV@UGA) by UGA.CC.UGA.EDU (LMail V1.1d/1.7f) with BSMTP id 4884; Fri, 21 May 1993 01:57:59 -0400
Date:         Fri, 21 May 1993 00:19:55 EDT
Reply-To: ingar.holst@ADMIN.UIO.NO
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
Comments:     To: ccnet-l@uga.bitnet
Comments:     Resent-From: Wei Wang <34CDHC7@CMUVM>
Comments:     Originally-From: Ingar Holst <ingar.holst@ADMIN.UIO.NO>
From: Wei Wang <34CDHC7%CMUVM.BITNET@uga.cc.uga.edu>
Subject:      WAY (to where...?)
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
Status: RO

Hi, dear fellow netters,

Here is Wang Wei, the author of WAY for Windows. I've received a few
mails like the followings since I put the program onto the net. So I'd
like to clear things a little bit here.

I stated in the readme file of WAY that it was an add-on module for
Windows, which might not be precise. WAY does not work like CCDOS
which changes the nature of the original DOS, so that it can support
Chinese in a ASCII environment. While WAY provides only a means of
Chinese input and display interface for new applications to be
developed for Windows. It does not work with the original Windows
applications like NotePad, Write, PaintBrush, or Word for Windows.
Although it can put the GB code for a Chinese character into a
NotePad or Write window, but the code is not recognised by that
software as a Chinese character. I haven't had a chance to try
it in a MS Windows Chinese version. Though it would not be hard
for me to support a Chinese Windows, but I doubt that Microsoft is
really serious about its Chinese products now. So I'll leave WAY
as it is for the time being.

So basically, WAY works for you if you are writing a Chinese program
MS Windows, it does not work for you yet if you just want to write
Chinese texts or put some Chinese character into a picture.

Just a couple of days ago, Mr Tian BoGang released a program called
ChPad from Italy. So I believe if you are writing a Chinese software
in MS Windows, WAY might be able to work for you as well.

My new phone number is (517)-773-1656. My e-mail address stays the same
until I leave the school (maybe in next May).

Regards to all

Wang Wei

----------------------------Original message----------------------------
Dear Netters,
   I have FTP'ed the WAY3002 windows programme from ifcss.org and success-
fully installed and been able to run it.
   Now there is just one small problem, only one thing which I don't
understand:

What is this programme for? What does it do?

It is not an editor.
It doesn't work with WordForWindows.

The font is real nice, but...

Hope someone can enlighten me. Because it must be a helluwa programme, so
nicely designed and all, once I only find out what it does. I tried phoning
the author - but he had moved and hadn't left the new address.

Ingar

From @UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU Fri May 28 07:46:09 1993
Return-Path: <@UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU>
Received: from uga.cc.uga.edu by ifcss.org (4.1/IFCSS-Mailer)
	id AA25099; Fri, 28 May 93 07:45:49 CDT
Message-Id: <9305281245.AA25099@ifcss.org>
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 6224; Fri, 28 May 93 08:44:46 EDT
Received: from UGA.CC.UGA.EDU (NJE origin LISTSERV@UGA) by UGA.CC.UGA.EDU (LMail V1.1d/1.7f) with BSMTP id 8536; Fri, 28 May 1993 08:44:44 -0400
Date:         Fri, 28 May 1993 08:44:38 -0400
Reply-To: cwnn <walt!omcp.omron!cwnn@UUNET.UU.NET>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: cwnn <walt!omcp.omron!cwnn@UUNET.UU.NET>
Comments: To: uunet!uga.cc.uga.edu!CCNET-L@uunet.UU.NET
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
Status: RO

>
>Your user name is "Cwnn project". Could you please tell us
>more about this project? I wonder if there is already a
>file called Cwnndict or so.
>
>Bo
>

Some time ago in 1992, I have sent one article on this cWnn project.
I will now send again for your reference ....

-Ang

***********************************************************************
*  Release of cWnn 4.10 (A Chinese Input System on Unix Workstations) *
***********************************************************************

  cWnn is an integrated Chinese Input system running on Unix Workstations.
  It supports a wide range of input methods, satisfying the needs of the
  Chinese users from all over the world, including both P.R.China and Taiwan.

  cWnn is capable of carrying out Hanzi conversion from an arbitrary Pinyin
  or Zhuyin sequence, hence improving the speed of Pinyin/Zhuyin input.
  cWnn is developed on Omron LUNA workstation and has been ported to other
  Unix workstations.


System Architecture and Configurations
=======================================
  cWnn adopts the Client-Server Model of Unix operating system.  The server
  will perform the service requests from all the clients, which may reside
  in the same or different machines.  In this way, resources are shared and
  multi-user environment is achieved.

  cWnn is capable of displaying Chinese characters based on GB and CNS
  internal codes.

  Current machines/OS that support cWnn are:
      Hardware           Operating System       Window system
    --------------       ----------------       -------------
    LUNA (Omron)         UniOS-U, UniOS-B       X, GMW
    LUNA II (Omron)      UniOS-U, Mach          X, GMW
    LUNA 88K (Omron)     Mach                   X
    Sun-3                SunOS 4.1              SunView, X
    Sun-4                SunOS 4.1              SunView, X
    SPARCstation         SunOS 4.1              SunView, X


Input Methods and Features of cWnn
===================================
  The current input methods available from cWnn are the commonly used
  phonetic input methods such as Pinyin (Quanpin, Erpin, Sanpin), and
  Zhuyin.
  The encoded input methods include Wubi and Qianma.  However, cWnn
  enables any encoded input methods to be installed easily.
  Other input methods include Guobiao, Quwei, Neima, Banjiao and
  Quanjiao input.

  The features of cWnn are:
  (1) Multi-phrase Hanzi Conversion
      - System is able to convert an arbitrary length of Pinyin/Zhuyin
        to the expected Hanzi at one time.

  (2) Standardization of Pinyin and Zhuyin
      - User is able to input both Pinyin and Zhuyin, while the system
        will still be able to carry out the conversion.

  (3) Ideal Input Environment
      - There will be a check on all user input, and warning is provided
        during illegal input.
      - Auto-correction may be performed on certain Pinyin/Zhuyin.
      - Automatic segmentation of input.
      - Auto-mapping of input performed by the preprocessor.
      - Error tolerance for 4 tones, which may be omitted or input wrongly.
      - Error tolerance for Pinyin.  User can have his individual
        definitions for Pinyin which he often gets confused.

  (4) Easy Installation of Any Input Method

  (5) Environment Independent
      - Multi-environment / multi-user
      - Each user has his individual environment
      - Input environment can be defined and modified.

  (6) Good and Flexible Environment Setup
      - Setup of dictionary
        User is able to have his own dictionary setup according to his needs.

      - User interface
        User is able to setup his own input environment, including keyboard
        definition and conversion key setup.

      - Setup of input methods
        Input methods can be easily selected.

      - Conversion parameters
        User is able to change the parameter values used for conversion.

      - Addition / modification / deletion of grammar files is possible
        (Note: After modification, the definitions in the dictionary and
               grammar file should be consistent)

  (7) Resource Sharing
      - Sharing of dictionaries, usage frequency and grammar files.
      - Sharing of conversion service.

  (8) Library functions available for implementation of other Chinese
      applications.


Other Functions
===============
  (1) Candidates Selection
      - User is able to select other candidates having the same pronunciation.

  (2) Re-Conversion
      - Re-input and re-conversion of input is possible after the initial
        conversion.

  (3) Self Adaptation
      - Usage frequency is updated whenever a word is selected.

  (4) Addition / Deletion of Dictionary
      Registration / Search / Deletion of Words


Where and How to Access cWnn Source
===================================
  cWnn has been released together with X11R5 by X-consortium, MIT.
  A multi-language input client called "Xwnmo", which makes use of various
  language servers including cserver, is also available from X-consortium.

  cWnn's source program is now available from the X-consortium.  However,
  an alternative source is from the FTP site in Japan.

  FTP address in Japan:
        ftp.wg.omron.co.jp

  IP address:
        133.210.4.4

  Procedure to obtain cWnn source from FTP site:
        % ftp ftp.wg.omron.co.jp
        user(ftp): ftp
        passwd:
        > cd ~/pub/X11R5

  You may obtain all cWnn related information from the above directory.

  Online manual and man files are available.  These include cWnn usage
  and installation, and they are found under the directory cWnn/manual.en.

  cWnn is now freely distributed, and we welcome any questions regarding
  cWnn to be sent to us if problems are encountered.  Please direct your
  questions to:
        cwnn@nff.ncl.omron.co.jp
        cwnn@omcp.omron.co.jp


CWNN DEVELOPMENT TEAM

From @UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU Mon Jun 14 11:18:21 1993
Return-Path: <@UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU>
Received: from uga.cc.uga.edu by ifcss.org (4.1/IFCSS-Mailer)
	id AA28597; Mon, 14 Jun 93 11:18:13 CDT
Message-Id: <9306141618.AA28597@ifcss.org>
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 5003; Mon, 14 Jun 93 12:16:18 EDT
Received: from UGA.CC.UGA.EDU (NJE origin LISTSERV@UGA) by UGA.CC.UGA.EDU (LMail V1.1d/1.7f) with BSMTP id 4584; Mon, 14 Jun 1993 12:16:16 -0400
Date:         Mon, 14 Jun 1993 02:57:39 MYT
Reply-To: "Dr. Foo Meng How" <foo@MHFOO.PC.MY>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: "Dr. Foo Meng How" <foo@MHFOO.PC.MY>
Comments: To: CCNET-L@UGA.UGA.EDU
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
Status: RO

Netters,

This mail, from Malaysia, is from a new netter. Over the 2 weeks
there has been little mention of Chinese systems from the PRC. DOS
based Xin4 tong1, Wang1 ma3 ver 5 & 6, hua2da2, PUC (WPS) ver 5 & 5.1,
LXPC, ABC are popular in Malaysia and Singapore. WM6 and Xt 6.1 are
both useable with Q_edit. Window 3.1 systems in M'sia and S'pore are
Twinbridge and Cstar 1.1 (no hardware protection) and 1.2 (hardware
protection). The most popular input methods are Wubizixing and Pinyin.
The educational system in Singapore and Malaysia (jianbi,
multilingualism, pinyin etc) explains the popularity of PRC systems.
Eten and KC have lost their prominence of the early 1980s although the
latest floppy versions are "PRC"-alike in inputs. Nobody has heard of
NJStar or ZWDOS !!!  The NJStar printout is too poor for classroom
use. And Chinese on the Mac is too expensive.

Compared with Singapore, HK, Taiwan, and the PRC, M'sia must be the
only country with Internet cheaply avail to an ordinary citizen.

___Foo

From @UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU Fri Jul  9 19:59:10 1993
Return-Path: <@UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU>
Received: from uga.cc.uga.edu by ifcss.org (4.1/IFCSS-Mailer)
	id AA15978; Fri, 9 Jul 93 19:57:31 CDT
Message-Id: <9307100057.AA15978@ifcss.org>
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 8890; Fri, 09 Jul 93 20:56:22 EDT
Received: from UGA.CC.UGA.EDU (NJE origin LISTSERV@UGA) by UGA.CC.UGA.EDU (LMail V1.1d/1.7f) with BSMTP id 9380; Fri, 9 Jul 1993 20:56:18 -0400
Date:         Fri, 9 Jul 1993 20:54:50 -0400
Reply-To: Rupert Zhu <rzhu@KBL.UWATERLOO.CA>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: Rupert Zhu <rzhu@KBL.UWATERLOO.CA>
Subject:      FYI:  Large character set support  (Standard C column)
Comments: To: CCNET-L@uga.bitnet
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
Status: RO

Journal:    C Users Journal  May 1993 v11 n5 p10(6)
* Full Text COPYRIGHT R & D Publications Inc. 1993.
-------------------------------------------------------------------------
Title:     Large character set support. (Standard C column) (Tutorial)
Author:    Plauger, P.J.


Abstract:  Standard C has a minimal set of functions for converting
           between multibyte and wide character.  Capabilities are being
           added to the existing print and scan functions, along with
           other changes in the works for Standard C being proposed by
           the member nations of ISO and other interested parties: the
           WG14 ISO C standards committee.  Two new conversion specifiers
           are now recognized by each family of functions.  The ability
           to read and write wide characters directly will not be added
           to the original C Standard, however a format string can
           contain multibyte characters as part of its literal text.  A
           meta-character data type is implemented as type int with
           additional semantic constraints.
-------------------------------------------------------------------------
Full Text:

Introduction

Last month, I described the new machinery for processing Defect
Reports--to interpret or correct the C Standard.  (See "State of the Art:
Formal Changes to C,"C Users Journal, April 1993.) I also outlined the
"normative addendum" that will add a number of features to Standard C.
Those changes are now being balloted for approval.  Some are designed to
help programmers write C source code that is more readable.  I described
them last month.  But most of the changes are designed to ease writing
programs that manipulate large character sets, a topic of growing
interest.

My goal this month is to start showing you the other, more extensive
group of changes in the works for Standard C. Understand, they are still
subject to modification.  Member nations of ISO, and other interested
parties, get several rounds of comments before we in WG14 freeze the
normative addendum.  I like to think, however, that this particular
material is reasonably stable. It should give you a portent of how
Standard C will look in another year or so.

Equally important, my goal is to suggest some ways you might actually use
these new capabilities.  To some extent, the conversion to using a large
character set is simple.  Just look for all the places where you
manipulate text as type char.  Replace them with objects and values of
type wchar_t.  Whatever the implementation chooses for a large character
set, its codes must be representable as that type.  But all sorts of
subtle changes must occur as well.  I'll endeavor to show you some of
them.

The Lightweight Approach

I begin by emphasizing that many programs can already speak Japanese, as
it were.  Programs often just read and write text without interpretation.
 You can feed them strings containing singlecharacter and multibyte
sequences intermixed, and they don't mess them up.  (If they do, you can
often fix the programs with little effort.  Typically, you just stop
presuming that you can break a string of text arbitrarily between any two
characters.)

A display or printer that does the right thing with these multibyte
sequences may well show Kanji characters, just the way the user desires.
Your program neither knows nor cares what happens to them outside its
boundaries.  Multibyte is usually the representation of choice outside
programs.  If you plan to do little or no manipulation of such text, it
can also be the representation of choice inside a program as well.

But lets say you have occasion to manipulate small amounts of text from a
large character set within your program.  You need to distinguish
character boundaries so you can rearrange text or insert other
characters.  In that case, wide characters are the representation of
choice inside the program.  You want to deal, at least sometimes, in
elements and arrays of type wchar_t.

Standard C already provides a minimal set of functions for converting
back and forth between multibyte and wide character.  You can also write
wide-character constants, as L 'x ', and wide-character strings, as
l"abc".  Several people have demonstrated that you can do quite a bit of
work with just what's already standardized.  (See, for example, my book,
The Standard C Library, Prentice Hail, 1992.)

One thing we chose not to add to the original C Standard, however, was
the ability to read and write wide characters directly.  A format string
can contain multibyte characters as part of its literal text, but you
cannot easily read and write data of type wchar_t.  You have to convert
wide characters to a multibyte string in a buffer before you print it
out.  Or you have to read a multibyte string into a buffer before you
convert it to wide characters.  That can be a nuisance.

Print and Scan Additions

So one of the changes in the normative addendum is to add capabilities to
the existing print and scan functions.  These are the functions declared
in <stdio.  h> with print or scan as part of their names.  Each family of
functions now recognizes two new conversion specifiers, %.C and %S.  For
the print functions:

%C writes to the output the multibyte sequence corresponding to the
wchar_t argument.  A shift-dependent encoding begins and ends in the
initial shift sequence.  That can result in redundant shift codes in the
output, but the print functions make no attempt to remove them.

%S writes to the output the multibyte sequence corresponding to the
null-terminated wide-character string pointed to by the pointer to
wchar_t argument.  The same rules apply for shift codes as for %C.  You
can use a precision, as in %.5S, to limit the number of array elements
converted.

In no event will either of these conversion specifiers produce a partial
multibyte sequence.  They may, however, report an error.  A
wide-character encoding may consider certain values of type wchar_t
invalid.  Try to convert one and the print functions will store the value
of the macro ElLSEQ in errno.  That macro is now added to the header
<errno.  h>.

As usual, the behavior of the scan functions for the same conversion
specifiers is similar, but different from that for the print functions:

%C reads from the input a multibyte sequence and converts it to a
sequence of wide characters.  It stores these characters in the array
designated by the pointer to wchar_t argument.  You can use the field
width to specify a character count other than one, as in %5C.  The input
sequence must begin and end in the initial shift state (if states
matter).

%S does the same job, but with two critical differences.  The multibyte
sequence to be converted is determined by first skipping leading
whitespace, then consuming all input up to but not including the next
whitespace.  Here, whitespace has its old definition of being any single
character for which isspace returns true in the current locale.  (Yes,
that can cause trouble with some multibyte encodings.) The resultant
sequence must begin and end in the initial shift state.  The other
difference is that the scan functions store a terminating null after the
sequence of converted wide characters.

A multibyte encoding may consider certain character sequences invalid.
Try to convert one and the scan functions will store the value of the
macro EILSEQ in errno.  The print functions may generate no incomplete
multibyte sequences, but the scan functions aren't nearly as tidy.  They
can leave the input partway through a multibyte character, or in an
uncertain shift state, for all sorts of reasons.  Remember, both families
of functions are still essentially byte-at-a-time processors.

Staying light

These additions to the print and scan functions were discussed before the
C Standard was frozen, as I indicated earlier.  We rejected them at the
time because they offered only partial solutions to several problems:

* eliminating redundant shift states when generating a stream of
multibyte characters

* keeping track of shift states across function calls when scanning a
stream of multibyte characters

* producing and consuming whole multibyte characters even in the absence
of shfft codes

The new "wide-character streams" solve such problems, but at a higher
cost in machinery.  I'll discuss them in a later installment.

So why did WG14 agree to add machinery which is known to be inadequate?
Because, for many applications, it is good enough, thank you.  People
writing "internationalized" applications have discovered a whole spectrum
of needs.  Earlier, I described a class of programs that need essensially
no special support for large character sets.  Others can use what's
already in the C Standard.  The biggest nuisance that many practicing
programmers keep reporting is this omitted ability to read and write wide
characters directly. For a small cost in code added to the print and scan
functions, you get enough code to help many programmers.

The Header <wchar.h>

But let's say you need to get more serious about large character sets.
In that case, you need more machinery.  The normative addendum provides
lots more machinery when you include the new header <wchar.h>.  Listing l
shows a representative version of this header.  The actual types used in
the type definitions may vary among implementations, as can the value of
the macro WEOF.  I have simply made cantman choices.

As you can see, this header declares quite a few new functions.  Most of
the new names are weird, but they can conceivably clash with those in
existing C programs.  That bodes ill for backward compatibility, a prime
virtue in any update to a programming language standard.

WG14 ameliorated the problem by deviating slightly from past practice.
The name of every current library function is reserved in the external
name space whether or not you include the header that declares it.  That
lets an optimizing compiler look for function names such as sqrt with
fewer fears that it's guessing wrong in treating it special.  But the
names of functions declared in <wchar.  h> are not similarly reserved.
If you include the new header in any translation unit of a program, you
have to look for conflicts.  Otherwise, you can ignore the new stuff
without fear.

You'll notice a handful of type definitions in the new header.  The first
three are old friends.  size_t and wchar_t are, in fact, already declared
in multiple headers.  struct tm, up to now, has been declared only in the
header <time.h>.  It is needed here to declare the function wcsftime.
Note, however, that in <wchar.h> it is declared as an incomplete
structure type.  You still have to include <time.h> if you want to
complete the type declaration, so you can poke at its innards.

Wide Meta-Characters

Books on C seldom emphasize the point, but C has long supported a
"meta-character" data type.  It is implemented as type int with
additional semantic constraints.  Look, for example, at what the function
fgetc returns. We're promised that the int return value is one of two
things:

* a character code that can be represented as type unsigned char, or

* the value of the macro EOF, declared in <stdio.h>

Further, we are assured that EOF is distinguishable from all valid
character codes.  The typical implementation, in fact, has eight-bit
characters and sets EOF to -1.  So valid values for a meta-character are
in the closed interval [-1, 255].  We use meta-characters all the time.
We read them with fgetc or one of its sisters, getc or getchar.  We test
them with the functions declared in <ctype.h>, such as isdigit or
isalnurm.  And, provided we filter out stray EOFs, we can even write them
with fputc or one of its sisters, putc or putchar.  Pretty handy.

It is only natural that the world of wide characters should demand
analogous machinery.  Thus <wchar.  h> defines a macro and a type that
support programming with wide metacharacters:

* The type wint_t can represent any value representable as type wchar_t.

* The macro WEOF can be represented as type wint t and is distinguishable
from all valid wide-character codes?

Now you should be able to understand why so many of the functions are
declared the way they are in <wchar.  h>.  They simply carry on the old,
and demonstrably useful, C tradition of trafficking in meta-characters.
Only now they're wide metacharacters.

There's one small subtlety I hate to let slide by without notice.  The
type wint_t is often represented with more bits than the type wchar_t.
That gives the implementor lots of choices for the value of WEOF.  But
that need not be the case.  It's perfectly valid for wint_t to be the
same size as wchar_t.  Then, the value of WEOF must be chosen from among
the invalid wide-character codes.  (And there better be at least one to
choose from.)

So don't fall into the habit of thinking of wchar_t as some unsigned
integer type.  And don't assume that WEOF is -1, or any other negative
value.  You may one day be surprised.  (If you want to write highly
portable code, in fact, prepare for the possibility that types char and
int are the same size.  But that's a whole another sermon.)

State Memories

One of the notorious shortcomings of the Standard C library is its
dependence on private memory.  A number of functions maintain static
storage to remember various values between calls.  Some storage is even
shared among different functions.  The drawbacks of private memory in
library functions are well known:

* What a function does each time you call it depends on more than just
the value of its arguments.  That makes its interface harder to learn and
to use properly.  Stroke, for example, is notoriously hard to master.

* You can't share the use of a function with memory among different tasks
at the same time.  Or you have to be very careful to save and restore
context, as with set locale and localeconve.

* A stored pointer from one call can be sabotaged by a later call.
tmpnam(NULL), for example, returns a pointer to a filename that changes
with each call.  Even worse, a call to gmtime changes the data pointed at
by an earlier return from localtime.

We knew these shortcomings when we developed the C Standard.  Much as we
wanted to fix many of the offending functions, we decided it was too
troublesome to change them.  Too much existing code would have to be
rewritten.

Worse, we perpetuated this practice when we added several functions that
manipulate large character sets.  As they parse or generate multibyte
strings, they may have to keep track of the current shift state.  So the
functions mblen, mbtowc, and wctomb have private memory.  You initialize
the memory to the initial shift state with one kind of call.  You then
progress through a multibyte string with other kinds of calls, and the
memory tracks the shift state.

Our major reason for using private memory was to avoid adding yet another
argument to each of these functions.  That argument also needs a special
type definition as well.  We didn't want all that semantic detail if
people weren't going to parse multibyte strings all that much.  After
all, we've gotten by with strtok all these years, haven't we?

Well, it turns out we were wrong.  Seems lots of people are manipulating
multibyte strings these days.  And they chafe at the shortcomings I
outlined above.  Thus the new type defintion mbstate_t, and the new
functions that use it.  I'll describe them all next month.

Conclusion

You'll find one more new type definition in <wchar.  h>.  The type
wctype_t serves a limited role.  It describes the "handle" returned from
the function wctype.  You use the handle only in the wide-character
testing function iswctype.  The handle corresponds to one of an
open-ended set of character classifications.  What are the
classifications and how can you make new ones? The answer is sufficiently
complex that I must also defer it to next month.

It has taken me a whole installment just to iay the groundwork for
understanding the large character set support being added to Standard C.
A glance at Listing 1 shows that <wchar.  h> declares a mess of
functions.  By now, you can probably guess what many of them do.  Your
guesses are probably even right in most cases.  My next task is to
reinforce your prejudices where you're right and show you the surprises
elsewhere.  Tune in next month.
-------------------------------------------------------------------------
Type:      tutorial
Topic:     C Programming Language
           Programming Instruction
           Functional Capabilities
           Enhancements
           Kanji
           Character Graphics
           Character Sets

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

From CCNET-L@uga.cc.uga.edu Mon Feb  1 02:20:09 1993
Return-Path: <CCNET-L@uga.cc.uga.edu>
Received: from uga.cc.uga.edu by ifcss.org (4.1/IFCSS-Mailer)
	id AA24597; Mon, 1 Feb 93 02:20:01 CST
Message-Id: <9302010820.AA24597@ifcss.org>
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 7278; Mon, 01 Feb 93 03:08:47 EST
Received: from UGA.BITNET by UGA.CC.UGA.EDU (Mailer R2.08 PTF008) with BSMTP id
 9980; Mon, 01 Feb 93 03:07:37 EST
Date:         Mon, 1 Feb 1993 02:07:25 CST
Reply-To: "Z. Zhang" <zzhang@CSRD.UIUC.EDU>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: "Z. Zhang" <zzhang@CSRD.UIUC.EDU>
Subject:      Re: computing in China
Comments: To: CCNET-L@uga.cc.uga.edu
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
In-Reply-To:  <199302010629.AA09033@s46.csrd.uiuc.edu>; from
              "yxu@VIOLET.UWATERLOO.CA" at Jan 31, 93 12:38 pm
Status: RO

>
> >
> >              Chinese Computing in Mainland China
> >
> >               Yueheng Xu      Jan. 29, 1993

Thanks for the author of the posting for giving us very interesting insight
of the topic.

I have been watching this net for a while and have the impression that it
links only with software side issues. Could anybody kindly confirm me if
this is the case.

I'm of more interested in system/hardware issues of the mainland computer
industry. If we divide it roughly, the market will consist: 1) Embedded
system for real time control. 2) PC/Desktop for word processing and small
scale computing. 3) Workstation and mini-supercomputer(like Vax). 4) Super-
computer R&D.

The lower layer being VLSI, chip fabrication etc.

Any info is welcome! Thanks!

- Z.Zhang at UIUC

From @UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU Wed Jul 21 00:30:02 1993
Return-Path: <@UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU>
Received: from uga.cc.uga.edu by ifcss.org (4.1/IFCSS-Mailer)
	id AA28232; Wed, 21 Jul 93 00:30:00 CDT
Message-Id: <9307210530.AA28232@ifcss.org>
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 4735; Wed, 21 Jul 93 01:28:56 EDT
Received: from UGA.CC.UGA.EDU (NJE origin LISTSERV@UGA) by UGA.CC.UGA.EDU (LMail V1.1d/1.7f) with BSMTP id 8259; Wed, 21 Jul 1993 01:28:55 -0400
Date:         Wed, 21 Jul 1993 01:16:00 EST
Reply-To: SJJ%UFBIOT.BITNET@uga.cc.uga.edu
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: SJJ%UFBIOT.BITNET@uga.cc.uga.edu
Subject:      UNICODE and others
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
Status: RO

Hi, CCNET readers,
I am pleased to receive the files sent by Rupert Zhu about UNICODE.
This is a development that is going to affect future Chinese computing.
I hope more information on this and similar topic can be seen
in this newsgroup.

This brings up my recent memory on the troublesome Electronic Magazine
sent by some enthusiasts in Taiwan. In that "Magazine", I was particularly
interested in the article on the Chinese codes from past to now. It was such
a well-written article that every Chinese should take a look. The coding
methods and input methods are still very confusing and lack of a standard.
I hope we can reach an agreement in the near future.

That particular Electronic Magazine also illustartes an interesting method
of distributing Chinese articles: the magazine include two files
one of which is an executable which can display the magazine on a PC
screen without the aid of any Chinese system or converter. I was quite
impressed and believed that this is the trend to follow. Another file
is a Big-5 text file for that magazine, which can be viewed by a viewer
or converted into a GB file or other file type. This additional file
is simply the traditional method of distributing text file, and
requires converter or viewer to read the file.

Anyway, I think the coding methods, and similarly the input methods,
need our attention and agreement if we are going to establish
a really efficient Chinese computing environment. I would welcome any discussion
on this topic.

Song-Muh Jong
sjj@icbr.ifas.ufl.edu

From @UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU Thu Aug 26 06:06:56 1993
Return-Path: <@UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU>
Received: from uga.cc.uga.edu by ifcss.org (4.1/IFCSS-Mailer)
	id AA10120; Thu, 26 Aug 93 06:06:45 CDT
Message-Id: <9308261106.AA10120@ifcss.org>
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 3229; Thu, 26 Aug 93 07:05:22 EDT
Received: from UGA.CC.UGA.EDU (NJE origin LISTSERV@UGA) by UGA.CC.UGA.EDU (LMail V1.1d/1.7f) with BSMTP id 9619; Thu, 26 Aug 1993 07:05:20 -0400
Date:         Thu, 26 Aug 1993 15:31:45 MYT
Reply-To: Ng Liang Shing <liang@HSNG.PL.MY>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: Ng Liang Shing <liang@HSNG.PL.MY>
Organization: Organization
Subject:      Pinyin: data structure and algorithm
Comments: To: Chinese Computing Network <ccnet-l@uga.cc.uga.edu>
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
Status: RO

The Pinyin Input Method: Data structure and algorithm

Pinyin Input Method is by far the most popular, though not the most efficient,
Chinese character input method. Hence, it deserves a closer look by all
Chinese programmers.

Its structure is in sharp contrast to Pinxing input methods (pin-compose,
xing-shape; e.g. Wubizixing and Cangjie). Pinxing is both more efficient both
in use and in algorithm. I will discuss Pinyin here and Pinxing later.

An input procedure should take keyboard input and give Chinese characters
coded in one of Big5, Guobiao or Hz.

The procedure can be further broken into the following steps:
1. read key
2. parsing: convert key values into pinyin codes
3. lookup: find the characters matching the pinyin codes.
4. ask & confirm: let the user choose one among all homophones (characters
with the same pronunciation)
5. echo & store: display the chosen characters to the screen and store the
characters into a variable.

The crucial part is the Pinyin Dictionary. This is a lookup table of the
characters. I will describe its implementation in detail. For specific example
i.e. where to find a reusable pinyin dictionary files, please email to me.

A pinyin dictionary should have two essential parts:  the index and the list
of characters.

Each entry in the index is a pair of two numbers - the pinyin code and the
location of the homophones.  A typical implemetation would be :
pinyin code: one byte for consonant, one byte for vowel plus tone, two bytes
(to form one integer) for the location of the characters in the list.

The list of characters lists all Chinese characters in the order of the pinyin
codes. It is a continuous string of characters grouped together according to
the pinyin codes. Each group of homophones is pointed to by an entry in the
index.

As an example, consonants {b, c, ch, d, f,...} has the pinyin codes {86, 87,
88, 89, 8A, ....} (in hexadecimal notation). vowels { a1, a2, a3, a4, a5, ai1,
ai2, ai3, ai4 ai5,.....} are { 1, 2, 3, 4, 5, 6, 7, 8, 9, A,.....}.

An entry in the index could be
86 01 AA 01,
86=b, 01=a1, hence all characters can pronounced as ba1 can be
found at location number 01AA in the list of characters. (note: here I use the
familiar format of storing integer - low byte first, high byte next - to store
the number 01AA in the format AA 01)

The next entry in the index would be
86 04 B1 01.
This is because homophones ba2, ba3 does not exist. 86 04 is ba4,
the location is at 01B1. Note you can determine the number of homophones ba1
by taking the difference of 01B1 - 01AA.

Liangsheng WU
26 Aug 1993
--
Ng Liang Shing            |   This is an Internet node host inside
Sungai Petani, Malaysia   |   an old 286.  A few years back, this place
liang@hsng.pl.my          |   was not more than a small town.

From @UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU Wed Oct 27 09:55:44 1993
Return-Path: <@UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU>
Received: from uga.cc.uga.edu by ifcss.org (4.1/IFCSS-Mailer)
	id AA21840; Wed, 27 Oct 93 09:55:41 CDT
Message-Id: <9310271455.AA21840@ifcss.org>
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 2868; Wed, 27 Oct 93 10:53:47 EDT
Received: from UGA.CC.UGA.EDU (NJE origin LISTSERV@UGA) by UGA.CC.UGA.EDU (LMail V1.1d/1.7f) with BSMTP id 5213; Wed, 27 Oct 1993 10:53:45 -0400
Date:         Wed, 27 Oct 1993 10:52:44 EDT
Reply-To: Tex Texin <texin@BEDFORD.PROGRESS.COM>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: Tex Texin <texin@BEDFORD.PROGRESS.COM>
Subject:      Looking for Asian Software Developers
Comments: To: CCNET-L@uga.cc.uga.edu
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
Status: RO

Hello all,

First, I hope mail messages like this are acceptable to this list.
If not I apologize.

I am the Asian Software Development Manager for Progress
Software. Progress is a maker of Application Development Tools,
in particular 4GL and relational database for client-server markets.
We support multiple platforms, UNIX, MS-Windows, VMS, BTOS,
 CTOS, and others.

Progress is a $100M co. and has experienced steady growth since
its formation about 11 years ago.

We have existing products for Asian markets and are now expanding
our development, quality assurance, technical support and
other staff positions to increase the capabilities of
our Asian software.


Progress is based in Bedford, Mass., just outside of Boston.
All positions are based in Bedford. (At least all the ones I
am trying to fill.)

My primary function is managing software development, not recruiting,
so if I get many messages, I may not reply right away.

However, if you are looking to develop, test or provide customer
support for software
that will be used in Taiwan, PRC, Japan, Korea, Thailand, and other
Asian countries, please contact me by email or fax.


Tex Texin
Asian Software Development Manager

Progress Software
14 Oak Park,
Bedford, MA 01730

Fax 617-280-4949

From @UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU Wed Nov  3 13:10:53 1993
Return-Path: <@UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU>
Received: from uga.cc.uga.edu by ifcss.org (4.1/IFCSS-Mailer)
	id AA27445; Wed, 3 Nov 93 13:10:25 CST
Message-Id: <9311031910.AA27445@ifcss.org>
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 3727; Wed, 03 Nov 93 14:09:06 EST
Received: from UGA.CC.UGA.EDU (NJE origin LISTSERV@UGA) by UGA.CC.UGA.EDU (LMail V1.1d/1.7f) with BSMTP id 5111; Wed, 3 Nov 1993 14:09:01 -0500
Date:         Wed, 3 Nov 1993 16:49:07 GMT
Reply-To: "L.S.Ng" <L.S.Ng1@SOUTHAMPTON.AC.UK>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: "L.S.Ng" <L.S.Ng1@SOUTHAMPTON.AC.UK>
Subject:      Q & A - Chinese Programming Basics
Comments: To: Chinese Computing Network <ccnet-l@uga.cc.uga.edu>
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
Status: R

I received over 20 responses and requests for the Q & A for Chinese
Programming Basics.

I am posting Part I - Coding and Accessing CCLIB.16 to CCNET-L.

(Part II - QBASIC source code for the Chinese printf() functions, and
its Q & A, will be posted later upon request. I have sample source code
for Displaying and Printing 16x16 bitmap both horizotally and
vertically. The principle for 24x24 bitmap is similar. 16x16 bitmap is
easy to handle and understand.)

I decided to post it to the CCNET for the following reasons:

1.  the whole document is about 300 lines, which is not very big.

2.  I wish to hear about comments and opinions from experts and seniors
in this fields.

3.  I hope to initiate discussion on this and other
related topics.

The document is included at the end of this mail. Note that my email
address was <liang@hsng.pl.my> but I am at <lsn@mail.soton.ac.uk> now.
So please mail me at <lsn@mail.soton.ac.uk> for futher correspondence.

Thanks for your attention

Hope you enjoy it.

Sincerely
Liangsheng WU

------------------------------------------------------------
liang.1:
From:   IN%"liang@hsng.pl.my"  8-AUG-1993 05:40:08.57
To:     IN%"ZHANG@utkvx.utk.edu"
CC:
Subj:   RE: Superset of codes

Glad to know you. I am Mr. WU3, Liang2sheng4.

> Would you please enlighten me about it, --- like recommending a book or so
> to me ?

I couldn't find a book on Chinese Programming in the market, perhaps becuase
it is too new. Sorry about that. But I am willing to share my idea via
correspondence.

Chinese Computing - the first step - how to write 'hello, world' in Chinese.

> BTW, I am a computational fluid dynamics major, and have some experience in
> graphics (animation & contouring) in C and Pascal.

Since you are a graphics programmer, this would be in fact not a problem at
all. You would learn about coding Chinese Characters and handling the Bitmap
fontfile plus turning the pixels on and off (the last part is your expertise).

> My first question, I guess, is to access the HZ library; --- or it is a
wrong question ?

Your first question - 'to access the HZ library' is a bit ambiguous :-) .
Please state your question more specifically.  Do you mean how to handle the
Bitmap fontfile of Chinese character?  Or do you mean what program should you
run to read HZ coded Chinese Characters?  (note:  HZ is a name for a Chinese
coding scheme)

I answer the question on handling the Bitmap fontfile.

I guess you are familiar with the mechanism of displaying ASCII character to
the screen. Basically a function such as 'printf()' is required. You pass a
string of ASCII code as the parameter. The function lookup a table of
ASCII bitmap fontfile and turn on/off the pixel of the screen to display the
character.

Of course, these are all transparent to novice programmers as the
English/American programmers had already done all the dirty job of bit/pixel
control etc.  for you.  But now, as for Chinese, no body has done this for
you, so you must start from scratch.  You must know about the coding, the
bitmap lookup and the pixel control.

To say 'no body has done this for you' is not exactly true.  I have done some
of this job for QBASIC - just to show how easy it is.  Hongbo Ni has written
more with Microsoft C.  You might need to rewrite for your platform.  So far,
no one that I know has done this for the Unix platform.  If you do that on
Unix, it would be the best. I suggest you write some Chinese characters in
your animation and contouring program, such as some words saying 'the results
is xxxx' etc and your name of course! The Englishman or American would be
amazed!

Please continue to write to me.

Sincerely
liangsheng wu

ps.  Please do not include my message in whole when replying.

--
Ng Liang Shing            |   This is an Internet node host inside
Sungai Petani, Malaysia   |   an old 286.  A few years back, this place
liang@hsng.pl.my          |   was not more than a small town.
*********

liang.2:
From:   IN%"liang@hsng.pl.my"  9-AUG-1993 11:59:36.09
To:     IN%"ZHANG@utkvx.utk.edu"
CC:
Subj:   RE: Superset of codes

> Sorry. I took HZ as *Chinese Character" when saying "HZ Library" (though
> vaguely know that it is some sort of coding), which I meant to be the
> library of the CC font files. So it should be CC library ???

I will explain about the HZ coding schemem later.

"Chinese Character library" is the correct term. "Font files" would mean the
same thing.

> By "accessing" CC library, I mean to call up a CC font file from say
> a C program, --- by providing the information the CC-lib needs such as
> the PinYin.

Yes you are asking a correct question accurately. I will explain the detail
mechanism - about Pinyin input method and others.

> Many questions here as you can imagine. First, how ? Second, do you
> "scratch" it *mannually*, by which I mean that you define a square of
> pixels, and turn on/off them according for each CC, or you first develope
> a tool (platform ??) and then "scratch" all the CC sort of standardly ?
> Third, how about the CC-lib; is there a shared CC-library, on which we
> can program directly, including rescale it ?

OK. Let's go back to our first question. How to say "hello, world" in Chinese.

1. you must have function similar to printf() that writes Chinese
Characters to the screen.

2. you have to build your own Chinese printf().

Now, we go one level deep into the question: how will the Chinese printf()
work?

1. it will take Chinese code as the parameter.

2. it will write Chinese characters to the screen.

Now, we identify that we need a Chinese Character library (cclib) i.e. the
fontfile. The fontfile defines the bitmap of each Chinese characters. By
reading the bitmap, we then turn on/off the pixels on the screen to display
the chinese characters.

To answer your question: is there a shared CC-library? Yes, there is. This can
be obtained by ftp various Chinese ftp site e.g.
ifcss.org:software/font/cclib.16

Try to get a cc-library file called cclib.16. There are many others. This is a
good place to start. Try investigating the file. e.g. size, structure etc. I
will explain more.

--
Ng Liang Shing            |   This is an Internet node host inside
Sungai Petani, Malaysia   |   an old 286.  A few years back, this place
liang@hsng.pl.my          |   was not more than a small town.
********

liang.3:
From:   IN%"liang@hsng.pl.my" 11-AUG-1993 06:15:03.60
To:     IN%"ZHANG@utkvx.utk.edu"
CC:     IN%"looi@lml.sf.ca.us"  "Looi Wan Wah"
Subj:   RE: Superset of codes

To understand what is CCLIB.16, you can ftp
ifcss.org:/sofware/dos/editor/njs210-1.zip njs210-2.zip njs210-3.zip for
NJSTAR Wordprocessor version 2.1. Read the file GUOBIAO.DOC using NJStar.

CCLIB.16 is a fontfile consisting of symbols and 6763 Chinese Character.
All the characters can therefore be represented as a number. e.g. Character
no.1 is 'a symbol', character no. 1411 is 'a1' etc.

A clever scheme has be thought out to represent those characters: they are
grouped in a subgroup of 94 characters and there are 94 such subgroup. So
character no.1 'a symbol' is given the first character of the first group
whose code is 0101.  and character no 1411 'a1' is the 1st character of
subgroup no 16 hence is coded as 1601.

But why 94? This is how it is clever. There are 94 ordinary characters in the
ASCII character set (from ASCII 33 to ASCII 126). (The rest are control codes
ASCII 01-31, space 32, DEL 127).  So instead of writing 0101 and 2255 we
can code the character as two ASCII character so that 0101 becomse ASCII 33 +
ASCII 33 = !!  and 2255 becomes ASCII 32+16 + ASCII 32+1 = '0!'.

This is the coding scheme we are going to employ in the as the
parameter in printf() function. So we say printf("!!6W"); it means we want to
display the character 'a symbol' and 'a1'. So we do not need to write
printf(1,1411).

What are the advantages of this coding scheme instead of straight decimal
numbers?

liang

--
Ng Liang Shing            |   This is an Internet node host inside
Sungai Petani, Malaysia   |   an old 286.  A few years back, this place
liang@hsng.pl.my          |   was not more than a small town.
********

liang.4:
From:   IN%"liang@hsng.pl.my" 14-AUG-1993 14:03:22.10
To:     IN%"ZHANG@utkvx.utk.edu"
CC:     IN%"looi@lml.sf.ca.us"  "Looi Wan Wah"
Subj:   RE: Superset of codes

char no.1 is coded as 0101. To convert 0101 to 1 the formula is
(01-1)*94 + 1=1. i.e. a character coded as AABB correspond to
(AA-1)*94 + BB. Hence 1601 -> (16-1)*94+1 = 1411.

The coding scheme we discussed so far is also called Hz coding scheme. The
Guobiao coding scheme is similar. The difference is that it employs the upper
128 characters of ASCII. i.e. For 1601 the ASCII code equivalent is
(128+32+16, 128+32+1) => (176,161) [in Hz it is (48,33).] Also, a name is
given to the coding scheme 1601 - Quwei, though this is not implemented
directly.

Here is a summary of the coding schemes we discussed:

Character number 1411 in cclib:

QuWei: 1601   (first character subgroup no 16, format AABB, AA=subgroup
               number=Qu in Chinese, BB=position in a subgroup=Wei in Chinese
               hence the name QUWEI)

Hz:   (48,33)="0!"   (X,Y): X,Y=ascii value of the character
GB:  (176,161)="(non-printable in email)" [note:  this is an disadvantage of
                                            GB ]


The file cclib.16 that comes with NJStar and the cclib.16 that you ftp has the
following structure:
every 32 bytes defines one character. You should divide the file size by 32 to
get the number of characters. Note that they are different. Further, divide
the number of characters by 94 to obtain the number of subgroups.

For each characters, every two bytes defines one row of pixels (there are 16
pixels in one row), there are 16 rows in total.  The values of the two bytes
represent the binary value that turns on/off the corresponding pixels in a
row.  e.g. Say you read two bytes each time. The first byte is HEX FF and
the second byte is HEX 0F, then the pixel pattern should be

XXXXXXXX____XXXX
 F   F   0   F

Q: What is the pixel pattern of HEX ABCD?
(Answer: X_X_X_XXXX__XX_X ), note: X_X_ = 1010 (binary) = HEX A = DEC 10

I shall talk about the Pinyin dictionary later. As for now, please be
convinced that cclib is only a set of graphic fonts and contain no more
information than that.

You should now have gathered enough information to write printf(). However,
there are some quirks in the CCLIB.16 file which I shall discuss later.

(clue:  note the different number of subgroups in NJStar CCLIB.16 and cclib.16
in /software/fonts. How many subgroups are there in each case? How many
subgroups are for Chinese characters? How many subgroups are for symbols?)

liang
--
Ng Liang Shing            |   This is an Internet node host inside
Sungai Petani, Malaysia   |   an old 286.  A few years back, this place
liang@hsng.pl.my          |   was not more than a small town.
**************

liang.5:
From:   IN%"liang@hsng.pl.my" 16-AUG-1993 13:31:02.52
To:     IN%"uunet!utkvx.utk.edu!ZHANG@uunet.UU.NET"
CC:
Subj:   RE: cclib

> 1. I edited the HZ file of " home-letter of mine written by NJSTAR before.
>    It was started with "Ba4 Ba4 Ma1 Ma1", i.e., ~{0V0VBhBh~} in HZ. I
>    changed it into ~{0VBh~}, and it then became "Ba4 Ma1:". --- It is
>    amazing for me.

Excellent. Note that the Hz code must be enclosed in tilde+curlie-brackets.

>
> 2. I have also typed (using the DOS _type_) both GUOBIAO.DOC and QUWEIMA.DOC,
>    just to look at the "up ASCII" characters. I also translated them into the
>    readable HZ, and it then came to my attention that their HZ sizes are
>    about doubled. Does this mean that the font size of the up-ASCII
>    a character is about half of a "low" one ?

Note that the Hz code is enclosed in tilde+curlie-bracket. The
tilde+curlie-bracket pairs adds up the extra size.


>
> >Q: What is the pixel pattern of HEX ABCD?
> >(Answer: X_X_X_XXXXX__XX_X ), note: X_X_ = 1010 (binary) = HEX A = DEC 10
>                 ^^^^^

Sorry. It's my silly mistake. Thanks for spotting it.

> Sorry for my repeated asking about PinYin. I was just trying to draw as
> much as I can info from your mail. In future, whenever you find a question of
> mine improper, put it aside.

Now we talk about CCLIB. When we're finished with this soon, we will talk
about Dictionary (for Input).



The difference between NJstar CCLIB.16 AND others.

NJSTAR CCLIB.16: 246656 bytes
Standard CCLIB.16: 237632 bytes

The Standard CCLIB.16 has 72 subgroups of Chinese Char and 7 subgroups of
symbols (marks and letters). (read Guobiao.doc note at the beginning)

NJStar CCLIB.16 has 73 subgroups of Chinese Char and 9 subgroups of symbols.
The extra subgroups in NJStar CCLIB.16 are subgroup no. 8,9 and 15. This means
that NJStar CCLIB.16 has extra symbols and Chinese Char. But they are
non-standard, according to the standard defined in Guobiao2312-80. This means
that those characters are not guanranteed for support by other Chinese
softwares.

Now let me explain what I mean by 'quirk'. Now you know that the first Chinese
Character 'a1' is coded as 1601 (quwei). However, it's absolute position in
the CCLIB.16 is immediately after the symbols. Hence, in standard CCLIB.16, it
is 7 subgroups x 94 char per subgroup x 32 bytes per char + 1 = byte no 21057
In NJStar, it is, however, immediately after the symbols (subgroup 1 to 9)
plus the extra Chinese char subgroup (subgroup 15), i.e. its absolute position
is therefore 10 x 94 x 32 + 1 = 30081 byte.

The quirk or discontinuity occurs only at one place, luckily. So when you
build printf(), you must consider the absolute starting position of the
charater you wish to access.

Q: Is there a formula to cater for the two CCLIB.16 despite their difference?
(clue: there are only 72 subgroups of standard Chinese char, and they are
placed after the symbols. Note also the CCLIB has only two parts: the symbols
[7 subgroups] and Characters[72 subgroups].)

If you have no further questions, I will send you a sample print() function
written in QBASIC. I hope you can build it for 'C' for DOS and Windows and for
Unix.


Note: all symbols and characters have the same size i.e. 16x16 pixels or 32
bytes.

--
Ng Liang Shing            |   This is an Internet node host inside
Sungai Petani, Malaysia   |   an old 286.  A few years back, this place
liang@hsng.pl.my          |   was not more than a small town.
**************

From @UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU Mon Nov  8 07:56:28 1993
Return-Path: <@UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU>
Received: from uga.cc.uga.edu by ifcss.org (4.1/IFCSS-Mailer)
	id AA27157; Mon, 8 Nov 93 07:56:11 CST
Message-Id: <9311081356.AA27157@ifcss.org>
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 9706; Mon, 08 Nov 93 08:52:30 EST
Received: from UGA.CC.UGA.EDU (NJE origin LISTSERV@UGA) by UGA.CC.UGA.EDU (LMail V1.1d/1.7f) with BSMTP id 8443; Mon, 8 Nov 1993 08:49:10 -0500
Date:         Mon, 8 Nov 1993 08:49:04 -0500
Reply-To: "HU Bo, IFT Munich, +49 89 54759129" <hubo@IFT.FHG.D400.DE>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: "HU Bo, IFT Munich, +49 89 54759129" <hubo@IFT.FHG.D400.DE>
Organization: FHG
Subject:      Re: Estimate COST of building <chnio.h>
Comments: To: "L.S.Ng" <L.S.Ng1@SOUTHAMPTON.AC.UK>
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
In-Reply-To:  <DFNGATE:OdHKyQFx*@MHS>
Status: R

Some aspects against the usage of application-level Chinese I/O
===============================================================

As a software author of both system-level and application-level Chinese
(and Japanese) I/O routines I'd like mention some aspects against your
call for <chio.h>:

- "They have got no ETen!"
So they may buy one or use KC or something else. Or some other products in
the GB-World. The routines by some applications' programmers are definitely
worse and more expensive. Generally, the authors of system-level Chinese I/O
routines have more experiences and can focus themselves to solve Chinese I/O
problems, much better than one, for example, who is a database specialist.
And, since the system-level products may be used for many other people, they
become more cheap. Or, what would you say to someone who tells you that he
has got no DOS?

- Portability
Remember: an application dealing with basical I/O problems is never portable.

- Make your application user friendly
Users want to focus to their actual problem. On the other hand, everyone uses
nowadays more than one application. It must be a horrible vision that one has
to switch to another Chinese I/O interface each time when he switches to
another program!

- Reusability
You hope that everyone on the market who wants to develop an application will
also develop a Chinese I/O. But the reality is that (almost) nobody does. So
be happy that someones have developed some system-level solutions which can
be reused by many applications.

- data interchanges
A system-level Chinese I/O provides a more problemless data interchange between
different applications.

- Copyright problems
Software products are coproductions by many individuals. It is a utopy to force
all people write FreeWare products together with the souce code published. It
is a communist thought. System-level Chinese I/O routines are a good compromise
between the interest of the authors of I/O routines and the users (and futher
application authors). The motivation to develop a software should never be that
the available one is too expensive. As I pointed out before, "self-sufficiency"
is always much more expensive.

- <chio.h> is not a good interface
As a matter of fact, I/O routines like prinf, scanf are very rarely used in
professional programs under DOS. If you really want to repeat the work that
many authors have done before, try to begin with some more basic routines, or
try to jump to a windowed Chinese I/O system (Like my <easywin.h>. There was
also some one before you, as you see!).


Bo

From @UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU Mon Nov  8 08:20:15 1993
Return-Path: <@UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU>
Received: from uga.cc.uga.edu by ifcss.org (4.1/IFCSS-Mailer)
	id AA27323; Mon, 8 Nov 93 08:20:07 CST
Message-Id: <9311081420.AA27323@ifcss.org>
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 0030; Mon, 08 Nov 93 09:15:23 EST
Received: from UGA.CC.UGA.EDU (NJE origin LISTSERV@UGA) by UGA.CC.UGA.EDU (LMail V1.1d/1.7f) with BSMTP id 1471; Mon, 8 Nov 1993 09:07:51 -0500
Date:         Mon, 8 Nov 1993 09:07:45 -0500
Reply-To: "HU Bo, IFT Munich, +49 89 54759129" <hubo@IFT.FHG.D400.DE>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: "HU Bo, IFT Munich, +49 89 54759129" <hubo@IFT.FHG.D400.DE>
Organization: FHG
Subject:      System-level or application-level
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
Status: R

Let's have a closer look at this problem from a more pratical
point of view:

Using a home brue Chinese system, I am able to use Microsoft
WORD (and WordPerfect and, and,..) since 1989 (!). Chinese
texts are editted, formatted and printed out as if they where
English ones.

There are many strong functions there which nobody of us has
even dream of to implement. Especially for us living in a non-
Chinese society, a Chinese system is such a short cut leading
us to modern applications that you will never want to miss it.

Which word processor are you using when you want to write a
pure English text?


Bo

------- End of Forwarded Message

From @UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU Fri Nov 12 07:12:34 1993
Return-Path: <@UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU>
Received: from uga.cc.uga.edu by ifcss.org (4.1/IFCSS-Mailer)
	id AA01149; Fri, 12 Nov 93 07:12:23 CST
Message-Id: <9311121312.AA01149@ifcss.org>
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 4881; Fri, 12 Nov 93 08:09:31 EST
Received: from UGA.CC.UGA.EDU (NJE origin LISTSERV@UGA) by UGA.CC.UGA.EDU (LMail V1.1d/1.7f) with BSMTP id 9613; Fri, 12 Nov 1993 08:09:25 -0500
Date:         Sat, 13 Nov 1993 00:08:51 EST
Reply-To: Youzhen Cheng <youzhen@CIVENG.UNSW.OZ.AU>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: Youzhen Cheng <youzhen@CIVENG.UNSW.OZ.AU>
Subject:      DateStar - Chinese Calendar Producer
Comments: To: ccnet-l@uga.cc.uga.edu
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
Status: R

CCnet-L friends:

I have uploaded <<DateStar>> - Chinese Calendar Producer
on ifcss.org[129.107.1.155]:/software/dos/chinese-utils

The following is a simple introduction to the program.

*****************

1.1  What is DateStar

The DateStar program is a friendly Chinese perpetual calendar producer that
displays and prints a combination form of Western and Chinese calendar, and
runs on the IBM PC and compatible computers. The DateStar produces yearly
calendars, monthly reminder calendars or weekly working planner calendars.

DateStar was developed with the following goals in mind:

   - Multiple Environment - DateStar was designed to meet various operating
     environments which are:


       - PC-DOS, MS-DOS ASCII only system
       - CC-DOS, GuoBiao Chinese Operating system
       - Eten, KC, etc. BIG-5 Chinese Operating system
       - PC-DOS, MS-DOS with ZWDOS environment
       - Postscript Laser Printer
       - HP LaserJet Printer


   - Ease of Use - This version of DateStar includes:

       - Command line options
       - One single executable file performing all DateStar's features
       - Customizing Configuration File (for advanced users)


   - Compact Program Size - Every effort was made to keep the size of
     program as compact as possible. DateStar never requires more
     memory than absolutely necessary.


1.2  Features

The main features that you will enjoy while using DateStar are listed
below:

   - DateStar displays and prints calendars between AD 1841 - 2060.

   - User defines the calendar in whatever monthly reminder
     calendar or weekly working plan calendar.

   - Solar Terms (24 JieQi), Birth Characters (ShengChen BaZi) and
     also the Lucky Days (HuangDao JiRi) are included in DateStar.

   - DateStar supports Postscript laser printer, HP LaserJet series and
     various Chinese Character Code systems.

   - It is Configurable.  DateStar can be easily customised in the way you
     like it.  This includes the code generation, calendar format, printer
     selection as well.


1.3  System Requirements

DateStar runs on the IBM PS/2, PC/AT, PC/XT, PC, PC/Jr, and on IBM
compatible computers including the Compaq, NCR, Tandy, and WYSE PC's.
MINIMUM requirements are:

   - 64 KB of memory
   - PC-DOS 2.0 or greater (or MS-DOS 2.0 or greater)
   - One diskette drive
   - Either a color or a monochrome monitor with 80-column display


1.4  Sample Output on ASCII Terminal

                           November 1993

Sunday    Monday    Tuesday   Wednesday Thursday  Friday    Saturday

           1 [18]    2 [19]    3 [20]    4 [21]    5 [22]    6 [23]
 7 [LD]    8 [25]    9 [26]   10 [27]   11 [28]   12 [29]   13 [30]
14 [10]Y  15 [ 2]   16 [ 3]   17 [ 4]   18 [ 5]   19 [ 6]   20 [ 7]
21 [ 8]   22 [XX]   23 [10]   24 [11]   25 [12]   26 [13]   27 [14]
28 [15]   29 [16]   30 [17]


1.5  DateStar Reference Card

software: DateStar - Chinese Calendar Producer
version : 1.1
function: Displays Chinese and western calendar in
          ASCII code, BIG-5 code (Hongkong, Taiwan),
              GuoBiao code (PRC Standard), and HZ code (Network)
          Prints on two most popular laser printers
              PostScript laser printers, and
              HP LaserJet (PCL) printers
          Generates four different format
              Yearly calendar, Monthly calendar,
              One-page Weekly calendar, and Two-page Weekly calendar
          Shows calendar with 24 Solar Terms (JieQi),
              the Heavenly Stems and Earthly Branches
              (TianGan DiZhi Eight Characters)
          Supports user defined annotations
          Applicable from year 1841 through to 2060
ftp site: ifcss.org[129.107.1.155]:/software/dos/chinese-utils
filename: datestar.txt datestar.zip.
author  : Youzhen Cheng <youzhen@civeng.unsw.OZ.AU>
comment : MS-DOS 2.0 and above

--
Youzhen
youzhen@civeng.unsw.OZ.AU

From @UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU Fri Dec 24 08:12:51 1993
Return-Path: <@UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU>
Received: from uga.cc.uga.edu by ifcss.org (4.1/IFCSS-Mailer)
	id AA15950; Fri, 24 Dec 93 08:12:17 CST
Message-Id: <9312241412.AA15950@ifcss.org>
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 4353; Fri, 24 Dec 93 09:10:05 EST
Received: from UGA.CC.UGA.EDU (NJE origin LISTSERV@UGA) by UGA.CC.UGA.EDU (LMail V1.1d/1.7f) with BSMTP id 8136; Fri, 24 Dec 1993 09:10:02 -0500
Date:         Fri, 24 Dec 1993 14:08:01 GMT
Reply-To: "L.S.Ng" <L.S.Ng1@SOTON.AC.UK>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: "L.S.Ng" <L.S.Ng1@SOTON.AC.UK>
Subject:      ZIKU Buffer - part I
Comments: To: Chinese Computing Network <ccnet-l@uga.cc.uga.edu>
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
Status: RO

A Memory Model for Chinese Font -  ZIKU Buffer
------------------------------------------------


Here I will discuss a memory model for Chinese fonts. By Chinese
fonts, I mean the bitmap or scalable glyphs for Chinese characters.

I shall consider the memory bitmap to implement a prototypical Chinese
OUTPUT printf() function.  This can be extended to include full page
scrolling or scalable font.

An understanding of Chinese Bitmap is essential for optimised program
development. For example, if you were to write a Chinese word processor,
you won't be using the simple and plain Chinese printf() function.
Rather, you may like to write your own funciton to scroll a whole page
of Chinese characters. The same goes to if you were to program a
terminal emulator such as Telnet or other specialised applications such
as a Fax program.



OUTPUT prototype function
=========================

As mentioned above, we are considering an OUTPUT function i.e. how to
display Chinese character on a device (a display or printer or a file)
efficiently.


Let's work backward and analyse what we need to do:

1. We are to display several Chinese characters on the screen. (for
example).

2. Let's consider these few Chinese characters on the screen as an
graphical image.

3. So we must use an array of memory to hold the graphical image. I call
it IMAGE BUFFER.

Nowadays, most compiler/graphics library support BitBlt function i.e.
copy a piece of memory to the display memory (e.g.  PUT in QBASIC,
putimage in Borland C <graphics.h> and MS-Windows bitblt() ).

What the programmer need to do is to define an array of memory large
enough to hold the image (typically an array an integer type).  Then you
can manipulate the image as you wish before you put it onto the display.

Finally, you issue the Bitblt command to copy the image (image buffer)
on to the screen (display memory).  Like this, the image appear on the
screen at one go, like flashing, you won't notice the pixel is drawn one
by one.



The ZIKU buffer
===============

4. For each character, the bitmap is stored somewhere. We will copy this
bitmap into the image buffer. This is what I mean by 'manipulating' the
image.

5. Because we need to lookup for bitmap for different characters quite
frequently, so it is best to store it in the RAM.

6. We must define ONE CONTIGUOS piece of memory to hold the bitmap of
all characters of a font.

For 16x16 Guobiao bitmap, it would be 87x94x32 bytes = 261696.
For 16x15 Big5 Bitmap, it would be 89x157x30 = 419190 bytes.
For 24x24 Guobiao bitmap, 87x94x72 = 588816 bytes ( >> 512 K!! )
For 24x24 Big5 bitmap, 89x157x72 = 1006056  (almost 1 MEGA byte !!)

I shall call this the **ZIKU buffer**.

7. Hence, it is obvious that we would need XMS memory if we use DOS. Or
you don't have to worry above this if you use better OS such as OS/2 or
Unix. If you use MS-Windows, Windows itself use XMS implicitly.


Using HBF and Feicangguizi bmp
==============================

8. ZIKU buffer is taken from Bitmap files. There are many variations
of Bitmap files around. Some fonts are made up of several bitmap files.
Merging these information in bitmap files into ONE ZIKU buffer save
considerable effort in programming.

9. You may employ Hanzi Bitmap Font Header or HBF to read the bitmap
files into the ZIKU buffer.

(You may choose to use your own method. Others: TTF or FNT in
MS-Windows; SNF or PCF in X-Windows.)

10. As for Feicangguizi i.e. Non-standard characters, you can read the
bitmap and store in in the empty spaces within the ZIKU buffer. There
are plenty of spaces in Guobiao scheme i.e. group/region 8 to 14. For
Big5, you can either use the lower blocks ( 0x8E40 to 0xA0FE ) or upper
blocks ( 0xFA40 to 0xFEFE )

[ For more detail on Feicangguizi, please email me. ]


An illustration of the above arguments:

                                  'manipulating'
  Bitmap file 1   -+                 (simple)
  Bitmap file 2    |                 (memcpy)
  Bitmap file 3    |-->  ZIKU Buffer   --->  Image Buffer  --> Devices
    .......        |    (one contiguos       (a few lines     (Display,
 Feicangguizi bmp -+    chunk of memory)    to a few pages)    printer,
                                                               file)


Scalable Fonts
==============

For scalable font:
                                       'manipulating'
  Scalable font file 1 -+              (Scan convert)
  Scalable font file 2  |                (rasterize)
  Scalable font file 3  |-->  ZIKU Buffer    -->     Image buffer
     .........          |                                 |
 Feicangguizi scalable -+                                 |
                                                          V
                                                        Device

Simple scan convert/rasterize algorithm for Bezier curves are widely
documented in graphics programming texts.  Of course, if optimised in
assembly language or even machine implemented (graphics accelerator!!!)
that would be the ultimate!!

Suggested reference:

Kent Porter: Stretching Turbo C (Brady, New York 1989)

Plastock and Kalley: Theory and Problems of Computer Graphics,
                           Schaum's Outline Series in Computer,
                           McGraw-Hill 1986


Last words
==========

Manipulating image buffer differentiate a Chinese programmer from a
Graphics programmer.

People who write GIF viewers do manipulate image buffer. So does a
Chinese programmer.

Doing the same job in different way distiguish one from another.




From @UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU Fri Feb 18 08:10:33 1994
Return-Path: <@UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU>
Received: from uga.cc.uga.edu by ifcss.org (4.1/IFCSS-Mailer)
	id AA23336; Fri, 18 Feb 94 08:10:26 CST
Message-Id: <9402181410.AA23336@ifcss.org>
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 3832; Fri, 18 Feb 94 07:15:41 EST
Received: from UGA.CC.UGA.EDU (NJE origin LISTSERV@UGA) by UGA.CC.UGA.EDU (LMail V1.1d/1.7f) with BSMTP id 0162; Fri, 18 Feb 1994 06:17:51 -0500
Date:         Fri, 18 Feb 1994 12:15:44 +0100
Reply-To: JAA@NOV.CRI.DK
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: Jan Andersen <JAA@NOV.CRI.DK>
Subject:      International wordprocessing.
Comments: To: ccnet-l@uga.uga.edu
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
Status: RO

Hi.

This is the first time I mail to this list, so i'll start by
introducing myself. I'm a software developer, working in
Denmark at a company called CRI. I've been working at PC's for
the last 12 years - right now I develop programs for OS/2
(Presentation Manager), which is an excellent operating system
in my opinion; better than Windows by a long shot.

I'm very interested in the discussion about wordprocessing and
fonts, and I think I may have a qualyfied opinion about this
subject. I believe that it would be fair to say, that word
processing (on a computer) must at least include: font handling,
keyboard handling, text presentation (screen and printer), text
formatting and 'tools' (like spell checking, name identification
(I'd like that feature in Chinese!), etc.).

I have very good experiences with designing programs in such a
way that they are 'general', that is: the program in itself does
not know anything specific about 'the world' (printer, screen
etc.), but it is able to communicate in a standardized way with
other programs (or programparts; -> 'drivers') that each handle
one limited aspect of the exterior world. Like most word
processors: how to print text on a specific printer is quite
unknown to the wordprocessing part of the program. Printing is
handled by a more or less external driver, that is able to
translate the wordprocessor's wishes about how the text should
look to 'printing actions'.

One great advantage about splitting up wordprocessing in 'actual
wordprocessing' and 'drivers' (handling fonts, etc. etc.) is that
often you can make a driver 'configurable' so that you're able to
tell e.g. the font driver by means of parameters how each single
character should be created on a screen or printer, how to
interpret diverse codes (like which binary values correspond to
which character) etc. In that way the font driver could be made
so that it would understand ANY encoding scheme like GouBiao,
BIG5, HZ or some future scheme, for that matter. Likewise the
keyboard driver could be made so that it could interpret ANY
input method and keyboard-to-character-code mapping. That would
be nice, wouln't it?

Another advantage of doing things this way is that it becomes
MUCH easier to write the actual program.

Hope this wasn't too long a message. Maybe somebody would like
to comment these viewpoints - I'd appreciate it. :)

Jaa@nov.cri.dk

From @UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU Sun Feb 20 10:00:57 1994
Return-Path: <@UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU>
Received: from uga.cc.uga.edu by ifcss.org (4.1/IFCSS-Mailer)
	id AA16032; Sun, 20 Feb 94 10:00:56 CST
Message-Id: <9402201600.AA16032@ifcss.org>
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 0296; Sun, 20 Feb 94 10:57:41 EST
Received: from UGA.CC.UGA.EDU (NJE origin LISTSERV@UGA) by UGA.CC.UGA.EDU (LMail V1.1d/1.7f) with BSMTP id 3472; Sun, 20 Feb 1994 10:57:40 -0500
Date:         Sun, 20 Feb 1994 15:50:58 GMT
Reply-To: "L.S.Ng" <L.S.Ng1@SOTON.AC.UK>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: "L.S.Ng" <L.S.Ng1@SOTON.AC.UK>
Subject:      Re: Chinese viewer on NeXT
Comments: To: "Daniel R. Kegel" <dank@alumni.cco.caltech.edu>
Comments: cc: Chinese Computing Network <ccnet-l@uga.cc.uga.edu>
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
In-Reply-To:  <199402192102.NAA27288@punisher.caltech.edu>; from "Daniel R.
              Kegel" at Feb 19, 94 1:02 pm
Status: RO

For those who are interested in writing Chinese function library on
their platform, here is some legal considerations.

(Why write Chinese function library? Because there is no Chinese
function library available for your platform.  Ignore this if this is
not true for your case.)

There are two kind of databases required for Chinese input and output,

1. Dictionary Files
2. Font files

Dictionary files are available in the public domain via anonymous
ftp:ifcss.org/software/x-win/cxterm-dictionaries

Each file has two columns, one list the input sequence, the other list
the corresponding Chinese code(s). There are character dictionary and
phrase dictionary. With this, we can write character and phase input
functions.

(The source code for CXTERM is available. But unfortunately source code
level documentation is not. So hopefully you can extract the dictionary
function from it. But I think it is still easier to rewrite your own.)


As with font files, those available in the public domain are up to 24x24
bitmap fonts. They are available by anonymous ftp from
ifcss.org:software/fonts

(Correct me if I am misinformed)

It is pretty boring to go strictly by law.:-) Here's the grey area.
(hopefully I am still legal bound)

1. there are tricks to 'generate' better bitmap fonts.
2. use standard vector fonts such as TTF

Font file handling falls into the category of data structure handling,
which is platform independent.  At the moment, my algorithm handles
bitmap fonts.  I hope we will do some TTF next.  The hottest (latest)
font now is vector composite font (proprietary), no standard as yet.
(Please tell me if you have decoded its format :-) )

From @UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU Mon Feb 21 13:42:21 1994
Return-Path: <@UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU>
Received: from uga.cc.uga.edu by ifcss.org (4.1/IFCSS-Mailer)
	id AA10420; Mon, 21 Feb 94 13:42:16 CST
Message-Id: <9402211942.AA10420@ifcss.org>
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 4040; Mon, 21 Feb 94 14:39:15 EST
Received: from UGA.CC.UGA.EDU (NJE origin LISTSERV@UGA) by UGA.CC.UGA.EDU (LMail V1.1d/1.7f) with BSMTP id 4479; Mon, 21 Feb 1994 14:39:12 -0500
Date:         Mon, 21 Feb 1994 19:33:11 GMT
Reply-To: "L.S.Ng" <L.S.Ng1@SOTON.AC.UK>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: "L.S.Ng" <L.S.Ng1@SOTON.AC.UK>
Subject:      Re: International wordprocessing. -Reply
Comments: To: JAA@nov.cri.dk
Comments: cc: Chinese Computing Network <ccnet-l@uga.cc.uga.edu>
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
In-Reply-To:  <sd68776f.001@nov.cri.dk>; from "JAA@nov.cri.dk" at Feb 21,
              94 8:24 am
Status: R

I am writing for example, a Chinese printf function and creating a
Chinese Function Library similar to prinf function in the Standard
Function Library.

This is my architecture:

scanf: workhorse is a tree search algorithm, which search the Chinese
character corresponding to a sequence of keys.

'printf': workhorse is an algorithm that looks up the bitmap correponding
to a Chinese character code, and copy it to a device (e.g. display or
printer)

As for scanf, the search is done through a 'Dictionary tree' (a kind of
extension to a binary tree)

As for printf, the bitmap is stored in a memory block called Font
Buffer.

As you can see, it does not really matter what the font file format is.
All we need to do is to scan-convert the font file into font bitmap
which is stored in the Font Buffer.

Of course if you are using display postcript, there is not need to
convert to bitmap.  I talk about bitmap because most display is bitmap
nowadays.

Or even you have a postcript file, the first thing to do is to convert
it to bitmap and store it in the font buffer. This is dynamic and can be
done on the fly.



> What one needs is one standard for fonts, that will work in any

Unfortunately in reality, o standard for font cannot be established.
There are already TTF, Postcript, Bitmap, and the latest Composite font.
Trend is changing all the time.

So to 'shield' the head-aching ever changing font format from the
Chinese printf() function, I thought out the design of Font Buffer,
which serve as a buffer between font files of various format and the
actual device format (e.g.  bitmap or postcript or vector).

Having said that, I have no objection with what you have said
about postscript.  I think the programming problem can be simplified
using Font Buffer, i.e.  to break the problem into two, (1) handling
font file (2) output to devices.  So you can help in writing postscript
scan-convert algorithm to bitmap, then I can concentrate on the second
part: bitmap to device.



You can also see the extra benefit here i.e.  various combinations of
font format and output format.  e.g.  If I have written a font
scan-convert algorithm for TTF, say, then the same Font Buffer can be
used for either Display or Printer!! On the other hand, if I also use
postscript, then I can use both TTF and postscript at the same time,
because they are sharing the Font Buffer!!

On the contrary, if you are not using Font Buffer, you then need to
write functions for each type of output and each type of font format.

If the previous case with font buffer we need N font algorithm + M
output algorithm = N+M algorithm, we would require N x M algorithms for
various combination of output and font format.


> As for libraries: I think that in systems like Windows, OS/2 and
> actually anything apart from DOS it would be more desirable to
> use Dynamic Link Libraries (DLL's). DLL's are not part of the

Yes, indeed. DLL should reduce the size of executables.

(Just a amusing thought: How come Windows programs get larger and larger
despite DLL and other OOP design? They are supposed to reuse existing
code, aren't they?)

From @UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU Tue Feb 22 09:26:40 1994
Return-Path: <@UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU>
Received: from uga.cc.uga.edu by ifcss.org (4.1/IFCSS-Mailer)
	id AA13717; Tue, 22 Feb 94 09:26:29 CST
Message-Id: <9402221526.AA13717@ifcss.org>
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 0170; Tue, 22 Feb 94 10:22:49 EST
Received: from UGA.CC.UGA.EDU (NJE origin LISTSERV@UGA) by UGA.CC.UGA.EDU (LMail V1.1d/1.7f) with BSMTP id 7760; Tue, 22 Feb 1994 10:22:46 -0500
Date:         Tue, 22 Feb 1994 15:01:18 GMT
Reply-To: "L.S.Ng" <L.S.Ng1@SOTON.AC.UK>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: "L.S.Ng" <L.S.Ng1@SOTON.AC.UK>
Subject:      Re: International wordprocessing. -Reply
Comments: To: HU Bo <ucc02au@sunmail.lrz-muenchen.de>
Comments: cc: Chinese Computing Network <ccnet-l@UGA.CC.UGA.EDU>
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
In-Reply-To:  <9402212156.AA06747@sun3.lrz-muenchen.de>; from "HU Bo" at Feb 21,
              94 10:56 pm
Status: R

> I don't know if you really mean printf and scanf by word. They are namely

Of course not. I use 'printf' and 'scanf' to refer to the core
algorithm.

I am only interested in writing the core algorithm for printf and scanf.
And I plan to make them as macro or subroutine to a higher level
funtion, i.e. the actual printf or scanf. Similarly they can be tailored
to suit page-scroll display or interactive input (e.g. in wordpro system).

e.g.  the core algorithm of scanf is a function returning a pointer to
the GB code with a string of input sequence as argument.

e.g. the core algorithm of printf is a function that copy bitmap from
the font buffer and paste it into the image buffer at a given
coordinate.

It is then up to the programmers to tailor these core algorithm.

Of course, I will also write the printf and scanf itself, either as an
example or for use with writing 'small Chinese programs' such as 'type,
cat' .....

I am now writing the documentation which has roughly two parts.

i) how to use such core algorithm
ii) how to design such core algorithm for a given platform.


Sincerely
Liangsheng WU

From @UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU Fri Mar 18 17:22:11 1994
Return-Path: <@UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU>
Received: from uga.cc.uga.edu by ifcss.org (4.1/IFCSS-Mailer)
	id AA28897; Fri, 18 Mar 94 17:22:09 CST
Message-Id: <9403182322.AA28897@ifcss.org>
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 3341; Fri, 18 Mar 94 18:17:30 EST
Received: from UGA.CC.UGA.EDU (NJE origin LISTSERV@UGA) by UGA.CC.UGA.EDU (LMail V1.1d/1.7f) with BSMTP id 0981; Fri, 18 Mar 1994 18:17:18 -0500
Date:         Fri, 18 Mar 1994 23:13:29 GMT
Reply-To: "L.S.Ng" <L.S.Ng1@SOTON.AC.UK>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: "L.S.Ng" <L.S.Ng1@SOTON.AC.UK>
Subject:      Segmented model for Font Buffer
Comments: To: Chinese Computing Network <ccnet-l@uga.cc.uga.edu>
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
Status: R

Having talked about a few points on merit of using font buffer, here is
some points on implementation.

Memory needs to be allocated for font data (converted to bitmap). A
table of pointers needs to be maintained. Each pointers points to the
address of the bitmap of a character. The table of pointers is indexed
according to the code of a character. (e.g. Guobiao code)

Using the simple memory model, the table size required is Code Space
(94*94= 8836 for Guobiao) times the pointer size. i.e. 32 bits. =  35344
bytes. (Since we would normally need to access more than 64K of bitmap
equivalent of bitmap font data, we need 32 bits pointer. A 24x24 bitmap
(decent by today's standard), is 72 byte big. A 64K block can only
contain 910 of them.)

The size of the table can be reduced from 35K to 9K by using segmented
memory model. In this scheme, two tables are maintained. The first table
consists of a total of 94 32-bits pointer. The second table consists of
a total of 8836 8-bits offset. So the bitmap address of a character can
be calculated as follows:

bitmap address =
       32-bits_pointer[HIbyte of GB code]
       +  (8-bits_offset[GBcode])*sizeof(bitmap)

Where sizeof(bitmap)=72 for 24x24 bitmap.


The tables are now 94*4=376 bytes and 8836 bytes big respectively,
making a total of 9212 bytes.


Bitmap is important if you are working with bitmap device. Nowadays most
device are bitmap. Vectored device are rare. Regardless the original
format of a font, e.g. TTF, it must be converted to bitmap before
displayed. Font buffer exists to overcome the bottlneck of disk read and
rasterizing, trading off for memory usage, which is nowadays cheap &
plentiful.


Segmented memory model provides a efficient way of handling font buffer.
Although the memory saving achieved is 35-9=26K (only!), it is very much
needed for writing 'very small Chinese programs', especially in some
archaic 16 bits environment (read DOS!!).

Sincerely,
Liangsheng WU

From @UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU Fri Mar 18 17:40:03 1994
Return-Path: <@UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU>
Received: from uga.cc.uga.edu by ifcss.org (4.1/IFCSS-Mailer)
	id AA29405; Fri, 18 Mar 94 17:40:00 CST
Message-Id: <9403182340.AA29405@ifcss.org>
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 1073; Fri, 18 Mar 94 18:37:31 EST
Received: from UGA.CC.UGA.EDU (NJE origin LISTSERV@UGA) by UGA.CC.UGA.EDU (LMail V1.1d/1.7f) with BSMTP id 3571; Fri, 18 Mar 1994 18:37:29 -0500
Date:         Fri, 18 Mar 1994 23:35:10 GMT
Reply-To: "L.S.Ng" <L.S.Ng1@SOTON.AC.UK>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: "L.S.Ng" <L.S.Ng1@SOTON.AC.UK>
Subject:      Memory required for Input Method
Comments: To: Chinese Computing Network <ccnet-l@uga.cc.uga.edu>
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
Status: R

Memory is a big concerned for writing 'very small Chinese programs'.
Chinese programs are notorious for memory-hungry. Two components consume
a lot of memory, i.e. the font and the dictionary (or Input Method).

The minimum memory required by a decent input method is about 60K.
Consider the specific case of character base input method, which is
decent, time-tested (read old) and reliable. A typical input sequence of
a few keys is normally compressed to a long int (4-byte). [ in Eten, to
save memory, it implements a special data type of 3-byte long ]. There
will be 94*94 (or less) of them in Guobiao code. The total number of
bytes required by the dictionary file is therefore  35344 bytes. But
normally only 6768 bytes (Non-symbol Character) are used. So it would be
27072 byte.

To search the dictionary effectively, a binary tree needs to be
maintained.

(A deviation from the discussion: YG Zhang implemeted the search tree in
what he called 'trie', which is a multinode tree. I eventually found
that it is IMPOSSIBLE to be implemented on DOS machine because of its
sheer size, >> 640K. He did it on Unix. :-) Also what can be done by
multinode tree can be done by binary tree with a minimum requirement of
42K memory.)

The size of a binary tree is the CODE SPACE (6768) times the size of
each node. Suppose each node contained three 16-bits pointers, i.e.
left, right, self, then the tree size would be about 7000*6 = 42K. This
assumes the dictionary size is less than 64K, else 32 bits pointer would
be required, which makes the tree node twice as large.

So the total size is 42K + 28K = 60K.

For the so called 'intelligent' input method like phrase input, the
memory required is much more than that. Firstly the dictionary file
would be larger than 64K anyway, and the CODE SPACE is not limited to
7000, it is as many as the number of phrases in the dictionary. Two
times 60K would be a rough estimate.



Sincerely,
Liangsheng WU

From @UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU Fri Mar 18 17:53:52 1994
Return-Path: <@UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU>
Received: from uga.cc.uga.edu by ifcss.org (4.1/IFCSS-Mailer)
	id AA00239; Fri, 18 Mar 94 17:53:50 CST
Message-Id: <9403182353.AA00239@ifcss.org>
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 9058; Fri, 18 Mar 94 18:48:07 EST
Received: from UGA.CC.UGA.EDU (NJE origin LISTSERV@UGA) by UGA.CC.UGA.EDU (LMail V1.1d/1.7f) with BSMTP id 4862; Fri, 18 Mar 1994 18:48:06 -0500
Date:         Fri, 18 Mar 1994 23:43:48 GMT
Reply-To: "L.S.Ng" <L.S.Ng1@SOTON.AC.UK>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: "L.S.Ng" <L.S.Ng1@SOTON.AC.UK>
Subject:      Very small Chinese program
Comments: To: Chinese Computing Network <ccnet-l@uga.cc.uga.edu>
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
Status: R

A very small Chinese program would require about 100K minimum of memory.

Calculations show that for input method we need about 60K of memory.
Statistics show that during a lifetime of a file reader, there are about
1000 Chinese character being used, which requires 72K bytes of bitmap
memory (using the decent 24x24 bitmap). Then there is a 9K Font Buffer
table to be maintaned.

All those number adds up to 140K (about).

If you use 16x16 bitmap, for font it would be 32K (each 16x16 bitmap
takes up 32 bytes). The total being 100K.

Suppose at one time, you would need two input methods active instead of
one, you then require another 60K.

All this figures add up nicely to about 200K.

And the conclusion is, for a decent, acceptable very small Chinese
application program, the memory required is about 200K.

(For the extreme case of ZWDOS, it put its font on disk, uses a somehow
limited input method, it takes only less than 20K!!)

And that is excluding the real part of the program.

Well, for DOS programmers, this means you have about another 400K to fiddle
around.

Sincerely,
Liangsheng WU

From @UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU Sat May 28 17:52:33 1994
Return-Path: <@UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU>
Received: from uga.cc.uga.edu by ifcss.org (4.1/IFCSS-Mailer)
	id AA15857; Sat, 28 May 94 17:52:31 CDT
Message-Id: <9405282252.AA15857@ifcss.org>
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 3357; Sat, 28 May 94 18:51:39 EDT
Received: from UGA.CC.UGA.EDU (NJE origin LISTSERV@UGA) by UGA.CC.UGA.EDU (LMail V1.1d/1.7f) with BSMTP id 8928; Sat, 28 May 1994 18:51:38 -0400
Date:         Sat, 28 May 1994 18:49:53 -0400
Reply-To: susan lasovick <lasovick@WORLD.STD.COM>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: susan lasovick <lasovick@WORLD.STD.COM>
Subject:      Re: Computer Processing of Chinese and Oriental Languages
Comments: To: Ted Ma <tedm@OASYS.SA-HTN.VALMET.COM>
Comments: cc: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
In-Reply-To:  <199405280013.AA27136@world.std.com>
Status: R

Professor Yaohan chu
ClCS Membership Chairman
U. of Maryland

ychu@cs.umd.edu
tel: 301-405-2719
fax:301-405-6707


Regards,
Susan Lasovick
lasovick@world.std.com


On Fri, 27 May 1994, Ted Ma wrote:

> Hi,
>
> Is there anyone over there knows "The Chinese Language Computer Society
> (CLCS)" and the person & e-mail address I can get contact with. I am
> interested in subscription of their publication of "Computer Processing
> of Chinese and Oriental Languages".
>
> Thank you in advance.
>
>
> Ted Ma
>
>
>  -----------------------------------------------------------------------
> | Ted Ma                            |                                   |
> | R&D Department                    | Phone:  (403) 253-6878 ext. 322   |
> | Valmet Automation Ltd., Canada    | Fax:    (403) 259-2926            |
> | 10333 Southport RD, S.W.          | E-Mail: tedm@sa-cgy.valmet.com    |
> | Calgary, Alberta, Canada T2W 3X6  |                                   |
>  -----------------------------------------------------------------------
>

From @UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU Tue Jul 12 01:04:22 1994
Return-Path: <@UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU>
Received: from uga.cc.uga.edu by ifcss.org (4.1/IFCSS-Mailer)
	id AB18817; Tue, 12 Jul 94 01:04:19 CDT
Message-Id: <9407120604.AB18817@ifcss.org>
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 7151; Tue, 12 Jul 94 02:02:23 EDT
Received: from UGA.CC.UGA.EDU (NJE origin LISTSERV@UGA) by UGA.CC.UGA.EDU (LMail V1.1d/1.7f) with BSMTP id 3190; Tue, 12 Jul 1994 02:01:24 -0400
Date:         Mon, 11 Jul 1994 14:33:46 MYT
Reply-To: Ng Liang Shing <liang@HSNG.PL.MY>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: Ng Liang Shing <liang@HSNG.PL.MY>
Subject:      Handling String for Future O/S
Comments: To: Chinese Computing Network <ccnet-l@uga.cc.uga.edu>
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
Status: R

Handling String for Future O/S

As future O/S moves towards double-byte string compatibility, new data
structures for handling string has been proposed.  I have seen such proposals
in at least two occasions:  Unicode string handling and NeXT API.

Traditionally, a string is represented in C as a pointer to character i.e.
char *.  The new structure being proposed is to represent string using derived
types.  e.g.  In the new NeXT API, string should use NSString *.  NSString is
derived and defined in the API.  The same idea goes behind Unicode string, the
keyword being a wee bit different.

As the standard has not settle as yet, during the transition, what structure
should we use for handling string?

My answer is to use a unique keyword that is different from char. Any keyword
will do.  We may define our own structure for the moment.  When moving onto a
few platform, replace the keyword with the platform specific one.

e.g.  declare string using type CHString * 'Chinese string'.  In DOS at the
moment, use

typedef struct { char t; /* type:  ASCII, GB or Big5 */
                 char h; /* the High byte */
                 char l; /* the Low byte */ } CHString;

When move to NeXT, use

typedef NSString CHString


The reason for using a unique keyword from char is simple:  because string is
different from char in terms of what it is.  char CAN be used for string or
any other 8-bit value.  String is a special case, so we must distinguish
string from char.

This is true even for single byte string. It is always a good practice to
define a new type to mean a different variable. In this case, simply use

typedef char String

Then declare a String variable using String *.


The CHString above is 3 byte per character, the extra character being used for
type. This can be saved to two bytes if we use some enconding scheme.

ASCII: high byte = 0
GB:    high byte = 1 to 127 (lower ASCII range)
Big5:  high byte = 129 to 255 (upper ASCII range)

However, this is an internal representation. So it should not be confused with
the Extended HZ coding scheme.

GB low byte should use lower ASCII range instead of upper ASCII range.

--
Ng Liang Shing            |   This is an Internet node host inside
Sungai Petani, Malaysia   |   an old 286.  A few years back, this place
liang@hsng.pl.my          |   was not more than a small town.

From @UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU Fri Jul 15 07:03:41 1994
Return-Path: <@UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU>
Received: from uga.cc.uga.edu by ifcss.org (4.1/IFCSS-Mailer)
	id AB23894; Fri, 15 Jul 94 07:03:37 CDT
Message-Id: <9407151203.AB23894@ifcss.org>
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 2295; Fri, 15 Jul 94 08:02:12 EDT
Received: from UGA.CC.UGA.EDU (NJE origin LISTSERV@UGA) by UGA.CC.UGA.EDU (LMail V1.1d/1.7f) with BSMTP id 2919; Fri, 15 Jul 1994 08:01:56 -0400
Date:         Fri, 15 Jul 1994 09:51:04 MYT
Reply-To: Ng Liang Shing <liang@HSNG.PL.MY>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: Ng Liang Shing <liang@HSNG.PL.MY>
Subject:      Type 3 Chinese Systems
Comments: To: Chinese Computing Network <ccnet-l@uga.cc.uga.edu>
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
Status: R

I have identified 3 types of Chinese systems, namely:

1. localised Chinese Operating Systems, with specific applications
   e.g. Microsoft Chinese Windows
2. standard (non-Chinese) O/S, patched with Chinese subsystems
   MS-Windows with CStar. Applications need not be specific

(note: specific means the applications are specially written for such a
Chinese systems. In Type 2, the Chinese patcher overrides the I/O subsystems
of the parent O/S, and 'forcing' Chinese services over ALL running
applications, whether or not the apps request for the Chinese services.)

3. standard (non-Chinese) O/S. Applications have Chinese functions built in.


Let's investigate what it takes to implement a Chinese systems, thus
justifying the pro's and con's of each type of these systems.

The fundamental part of a Chinese systems is very simple. It is the Chinese
Character Input and Output system. The Chinese Output system can be expressed
as:

     character codes ---( Chinese Output Systems )---> glyph data

The Chinese Input systems can be expressed as:

     key sequences   ---( Chinese Input Systems  )---> character code

The I/O systems can have very simple implementation up to very complicated
ones. However, for modest Chinese I/O functions, it does not take much to
implement.

So Chinese applications are indeed very simple. They are exactly same as all
standard (non-Chinese) programs, except that it request for Chinese functions
at some point of its lifetime.

It is the way services are requested and granted which differ in each type of
the systems. And this ultimately determines the complexity and stability (many
times they are inversely proportional to each other) of such a Chinese
systems.

1. In Type 1, the Chinese services are part of the O/S. There is often a
consistent set of API (application programming interface, i.e. how services
are requested and granted) to live with.

2. In Type 2, the patcher patches the parent O/S especially in the I/O
subsystem. In DOS, a Chinese patcher such as Eten will normally replace the
character I/O interrupt service routines (ISR) with its own ISR. The same idea
goes behind CStar and Windows.

3. In Type 3, the Chinese services are part of the application programs.



>From application programmers point of view:

Type 2 is a nightmare for application programmers. Patching the I/O subsystems
of the parent O/S often causes conflicts. A great deal of effort (indeed a
very great deal of effort) has been taken on the part of the Patcher developer
to minimise the conflict. However, some conflicts are fundamental.

I have met recently with two database application programmers. They both
develop programs using Eten on DOS. One of them uses Fox-pro, the other uses
Clipper.

The Fox-pro guy found major problem with loading his programs after
Eten is loaded - not enough conventional memory. So his solution was to sell a
ROM based version of Eten (with Eten card) to his customer. So I said this
added unneccessary cost on top of his software. But many would argue that such
cost will be paid by the customer anyway, so why bother? The trouble is what
if some one else produce a cheaper solution? A lower cost either mean the
product can be sold at a lower price and hence gain more market share OR the
product can be sold at the same price and hence increase the profit margin.
But at the moment, I have not seen an optimised solution as yet. So the
developer can sleep in peace for a while, but not too long.

The Clipper guy has problem with the Box characters. The internal clipper
dialogue box uses a ASCII box characters. They are interpretted as Chinese
character. In an intelligent mode (Z mode) Eten has added in its latest
version (not available in 3.0), the box character will be treated as box
character if 4 box characters occur consecutively. (This feature was
discovered but not documented). I think the logic behind is so that some
Chinese characters will be interpretted correctly. But it ultimately breaks
down when there exist two Chinese characters which are all made up of box
characters.

The Clipper guy also told me that he needed BOTH Jianti AND Fanti at the same
time.  But at the moment, Eten has only either Jianti OR Fanti version.  He
urged me to develop systems that works flexibly with both Jianti and Fanti (if
I am ever going to develop such a system)

So I would not encourage anybody who wish to write Chinese Apps for Type 2
systems.

We can see that although the applications gain some functions from using Eten,
at the same time, Eten has imposed many limits on them
1. memory
2. box characters
3. Jianti AND Fanti

I was worried about one potential problem. What happens when the programs are
networked (LAN or WAN)?  Will the Clipper network function conflict with Eten
network functions?  Suppose it won't, but it may take the programmers' a day
or two or may a week to fixed such problem.  And such difficulties in
maintenence ultimately means money and time.

And Eten only exist for DOS. It means the applications cannot be ported to
other O/S easily.

The Clipper guy was kind enough to lend me some of his documentations and
asked me to look into the possibility of interfacing his Clipper programs with
my Chinese functions which will be written in C. After some preliminary
investigations, I concluded that can be done without much trouble. The idea is
not to use Clippers own User Interface, because I will have to rewrite my own
anyway. My User Interface agent then communicates with the rest of his
programs by passing the essential variables. e.g. I capture the key sequence
and translate into Chinese character code, store it in some global variable,
then his clipper program picks up the characters. I retrieve data stored in
the global variable from his clipper program and translate them into screen
image.


Yours,
Liangsheng Wu


--
Ng Liang Shing            |   This is an Internet node host inside
Sungai Petani, Malaysia   |   an old 286.  A few years back, this place
liang@hsng.pl.my          |   was not more than a small town.

From @UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU Fri Jul 22 14:28:22 1994
Return-Path: <@UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU>
Received: from uga.cc.uga.edu by ifcss.org (4.1/IFCSS-Mailer)
	id AA04259; Fri, 22 Jul 94 14:28:14 CDT
Message-Id: <9407221928.AA04259@ifcss.org>
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 8931; Fri, 22 Jul 94 15:25:54 EDT
Received: from UGA.CC.UGA.EDU (NJE origin LISTSERV@UGA) by UGA.CC.UGA.EDU (LMail V1.1d/1.7f) with BSMTP id 3838; Fri, 22 Jul 1994 13:56:14 -0400
Date:         Fri, 22 Jul 1994 10:47:54 -0700
Reply-To: Bo Yang <eric@PALLAS.UCSD.EDU>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: Bo Yang <eric@PALLAS.UCSD.EDU>
Subject:      Re: Will CSTAR publish its DLL
Comments: To: ccnet-l@uga.cc.uga.edu
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
Status: R

>The main point is to distinguish CSTAR/TB services from existing English
>character services. If CSTAR/TB services override the existing ones, it will
>cause system instability. My only objection of CSTAR/TB is that they are
>INVASIVE. I hope they provide COMPLEMENTARY character services rather than
>OVERRIDING the existing ones.

But CSTAR is supposed to overrid the existing API calls. no more, no less.

It's not the interest of CSTAR to provide any API for developers. not
at all. the very point of patching is to make the patcher itself insivible,
so exsisting English applications will be handling Chinese, with exactly
the same calls to exising API.

For example, most word processors uses TextOut() call to put text on
screen and printer. now, this is what I think CSTAR does:

1. intercept all TextOut calls.
2. search for GB codes ( (unsigned) c > 0xA0 )
3. for parts (or all) of the string that contains non-GB calls, pass the
   call to exisiting TextOut().
4. for parts (or all) of the string coded with GB, using internal routines
   of CStar to translate the codes into indexes, look up the bitmaps,
   and disply the chinese characters with BitBlt() call (the existing
   bitmap displaying routine of Windows API)

the whole process is totally transparent to the applications (it has to be!
tell me how CStar is gona function without FORCING every application to
use the patched API calls? there's no way to patch every application!).

Now, CStar team COULD put together part 4 and export the function to other
applications, maybe call it HZTextOut(). but why should they bother? it won't
help CStar to compete.

I list the exported functions of CStar.exe and chinese.dll following this
article. as you can see there're only few exported calls that have
clear functional identites. If you try hard to search for a set of
useable APIs from these scattered P?? calls, I wish you good luck.:)

I don't expect CStar team to publish a set of chinese APIs, unless lots
of developers started to write applications for it. This contradicts
with very reason of the existence and evolving of Cstar, which is to make
existing English applications happy with hanzi so no one needs to write
new chinese applications.

regards

-- Bo
________________________________________________

windows excutables and DLLs are different from DOS applications in one
aspect. They contain a list of the NAMES of exported functions that
windows could link with dynamically at run time. The list has to be
at the beginning of the binaries so windows could search for the offset
tags for linking. This makes it easy to extract the names of the exports.
all you need is a small utility (I used Borland's EXEMAP.EXE). Note for
DLLs used as developer's libraries, the names of these functions should be
made reasonably readable.

CSTAR.EXE:
......
 Address         Publics by Value^M
^M
 0001:0000       CSTAR.245^M
 0001:00CC       CSTAR.248^M
 0001:010E       CSTAR.243^M
 0001:051F       CSTAR.247^M
 0001:0ADD       CSTAR.246^M
 0001:0C9F       CSTAR.244^M
 0001:0D0E       CONFIRMPROC^M
 0001:0DD1       CONFIRMEXITPROC^M
 0001:0E88       CSTAR.250^M
 0002:0000       CSTAR.241^M
 0002:02D1       ABOUTPROC^M
 0002:04C0       SETMODEPROC^M
 0002:058D       CSTAR.251^M
 0002:0A58       KBMAPPROC^M
 0002:0E7F       CSTAR.249^M
 0003:0000       CSTAR.242^M
 0003:00E6       REDRAWWNDPROC^M
 0003:013F       CSTAR.252^M
 0003:0B2F       DESKTOPPROC^M
 0003:0B78       SHELLWNDPROC^M
 0003:0BD9       CSTARWNDPROC^M
^M
chinese.dll:
...
 Address         Publics by Value^M
^M
 0001:0000       Chinese.10003^M
 0001:0010       PB^M
 0001:0075       PA^M
 0001:01E8       WEP^M
 0001:020E       Chinese.10000^M
 0001:08BD       Chinese.10001^M
 0001:0902       FCINSTALLFONTS^M
 0001:0F18       ENUMCFNTPROC^M
 0001:0FD0       FCUNINSTALLFONTS^M
 0001:1603       EDITPROC^M
 0001:1E43       WORDBREAKPROC^M
 0001:1E93       Chinese.10002^M
 0002:023E       CKBCONTROL^M
 0002:0437       PC^M
 0002:04DE       P31^M
 0002:0A85       CSISLEADCHAR^M
 0002:0AAC       CSCHARNEXT^M
 0002:0BAC       P21^M
 0002:0BE7       P22^M
 0002:0D80       P25^M
 0002:0D9F       P26^M
 0002:0E31       P23^M
 0002:0EB1       P24^M
 0002:0F3D       P32^M
 0002:0F73       P51^M
 0002:0FA8       P52^M
 0002:0FEA       P90^M
 0002:1030       P15^M
 0002:10F4       P16^M
 0002:11B0       P17^M
 0002:120F       P18^M
 0002:127E       P43^M
 0002:137A       P44^M
 0002:13DE       P41^M
 0002:148B       P42^M
 0002:155E       P19^M
 0002:16A8       FCREADFONT^M
 0002:20FD       P11^M
 0002:2D93       P13^M
 0002:2E2A       P14^M
 0002:2ED3       P12^M
 0002:30AF       P33^M
 0003:0000       SETCHINESE^M
 0003:005A       ENUMEFONTSPROC^M
 0003:01BA       SETMODEPROC^M
 0003:039E       SETFONTPROC^M
 0003:05CD       INSTFONTPROC^M
 0003:0639       TREEMAPPROC^M

From @UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU Fri Jul 22 15:13:46 1994
Return-Path: <@UGA.CC.UGA.EDU:owner-ccnet-l@UGA.CC.UGA.EDU>
Received: from uga.cc.uga.edu by ifcss.org (4.1/IFCSS-Mailer)
	id AA06238; Fri, 22 Jul 94 15:13:41 CDT
Message-Id: <9407222013.AA06238@ifcss.org>
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 9264; Fri, 22 Jul 94 15:57:28 EDT
Received: from UGA.CC.UGA.EDU (NJE origin LISTSERV@UGA) by UGA.CC.UGA.EDU (LMail V1.1d/1.7f) with BSMTP id 3719; Fri, 22 Jul 1994 14:59:22 -0400
Date:         Sat, 23 Jul 1994 02:44:03 MYT
Reply-To: Ng Liang Shing <liang@HSNG.PL.MY>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: Ng Liang Shing <liang@HSNG.PL.MY>
Organization: Your Organization
Subject:      Re: Five-stroke input methods
Comments: To: David Porter <dporter@leland.Stanford.EDU>
Comments: cc: Chinese Computing Network <ccnet-l@uga.cc.uga.edu>
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
Status: R

Dave & Netters,

On Fri, 22 Jul 1994 11:03:48 -0700 (PDT), "David Porter" <dporter@leland.Stanford.EDU> wrote:
> Hello,
>
> I'm working on a chinese language reference program, and I'm trying
> to learn something about character input methods.  Do you know of

My understanding is that Chinese Character processing consists of Chinese
character input system and Chinese character output system. Diagrammatically:

  key sequence ---( Chinese character input system )---> character code
   (keyboard)                                                   or
                                                      string of character code

   (other devices may be used: e.g. mouse, pen, etc. But keyboard is the most
common and popular, or most practical at the momoent.)

Chinese character output system:

   character code ---( Chinese character output system )---> character glyph

Glyph is the definition about how a character is drawn. The glyph table is a
part of a 'font'.


The general problem involved in input methods is that given an input, we need
to process or search a database for its corresponding character code or string
of character code.

For keyboard input, the problem is straight forward. We capture a sequence of
keystrokes. Then search an 'input dictionary' to find its corresponding
character code or string of character code.

A collection of input dictionary call the CXTERM-dictionary can be found by
anonymous ftp at ifcss.org:/software/x-win/cxterm-dictionary. They are
readable text files.

This is a table lookup problem. This class of problem dedicates to finding
efficient algorithms for searching database.

Another aspect of the input methods is about the logic and principles about
HOW to relate a particular key sequence to the character code.  This problem
is more on to the liguistic side.  e.g.  How can we use Pinyin as an input
method.  How can we break down all Chinese characters into a definite set of
radicals and how to assign the keyboard to the radicals.  How to build a
phrase dictionary.  etc...

> Do you have any ideas about topics which may be suitable for an

Besides the ftp information, Youngguang Zhang (the author of CXTERM) published
an article in the journal Software:Princple and Practice, Octorber 1992 (???)
Try to write to him at <ygz@cs.purdue.edu>. A large portion of this article is
dedicated to input method. But my comment is that his algorithm is
unneccessarily complicated. It can be simplified using binary search on a
sorted dictionary file.

Besides Chinese characeter I/O problems, related problems are are software
development for Chinese system software and application software e.g.  how to
choose a suitable platform, what are the easiest vs.  safest way of writing
applications, how to design portable Chinese system software/application
software etc...

Some other problems could be how to design Chinese system on non-computer
platform e.g. teletext, large LCD display, sign board at train stations or
airport, designing pager with Chinese text,...

Sincerely,
Liangsheng Wu

From owner-ccnet-l@UGA.CC.UGA.EDU Thu Aug 25 14:52:30 1994
Return-Path: <owner-ccnet-l@UGA.CC.UGA.EDU>
Received: from uga.cc.uga.edu by ifcss.org (4.1/IFCSS-Mailer)
	id AA07005; Thu, 25 Aug 94 14:52:09 CDT
Message-Id: <9408251952.AA07005@ifcss.org>
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 5478; Thu, 25 Aug 94 15:48:47 EDT
Received: from UGA.CC.UGA.EDU (NJE origin LISTSERV@UGA) by UGA.CC.UGA.EDU (LMail V1.2a/1.8a) with BSMTP id 2726; Thu, 25 Aug 1994 13:58:47 -0400
Date:         Wed, 24 Aug 1994 21:05:17 MYT
Reply-To: Ng Liang Shing <liang@HSNG.PL.MY>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: Ng Liang Shing <liang@HSNG.PL.MY>
Subject:      Parameters for Chinese scanf()
Comments: To: Chinese Computing Network <ccnet-l@uga.cc.uga.edu>
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
Status: R

Parameters for Chinese gets()

In C standard function library, gets() is a function for getting a string from
the standard input. It requires only one paramter, that is the address of an
array of characters.

Chinese input mechanism is more complex. So the Chinese gets() function must
accomodate more parameters. I think the minimal parameters required for a
Chinese gets() would be three:

1. the address of an array of characters, to which the input Chinese character
shall be returned.
2. a handle to the client window
3. a handle to the choice window

The first parameter is self-explanatory.

During the input of a Chinese character, there must exist a choice window. In
the choice window, a list of Chinese characters matching a certain key
sequence is presented to the user.

The client window is the window in which the chosen characters are displayed.

In English input, there is only one window presented to the user, that is the
client window.

The strucuture of a client window may contain components such as height,
width, current cursor position, orientation of string (in Chinese, a string
may be listed left to right, right to left, top to bottom, etc...), and many
others.

The choice window will have a certain size, the number of characters of
choice and so on.


In order to develop Chinese applications, we need to have a standard function
library for Chinese.  To this end, we must design a set of powerful Chinese
functions, equiped with elegant parameter passing mechanism.  It is hoped that
the proposed format for Chinese gets() as discussed above will be useful.


--
Ng Liang Shing            |   This is an Internet node host inside
Sungai Petani, Malaysia   |   an old 286.  A few years back, this place
liang@hsng.pl.my          |   was not more than a small town.

From owner-ccnet-l@UGA.CC.UGA.EDU Tue Sep 13 13:09:36 1994
Return-Path: <owner-ccnet-l@UGA.CC.UGA.EDU>
Received: from uga.cc.uga.edu by ifcss.org (4.1/IFCSS-Mailer)
	id AA07117; Tue, 13 Sep 94 13:09:30 CDT
Message-Id: <9409131809.AA07117@ifcss.org>
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 0475; Tue, 13 Sep 94 14:05:59 EDT
Received: from UGA.CC.UGA.EDU (NJE origin LISTSERV@UGA) by UGA.CC.UGA.EDU (LMail V1.2a/1.8a) with BSMTP id 9855; Tue, 13 Sep 1994 13:37:07 -0400
Date:         Tue, 13 Sep 1994 13:37:01 -0400
Reply-To: "Andresen Lab,PC,Physiology" <labandr@OHSU.EDU>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
Comments:     <Parser> W: TO field duplicated. Last occurrence was retained.
Comments:     <Parser> W: TO field duplicated. Last occurrence was retained.
Comments:     <Parser> W: TO field duplicated. Last occurrence was retained.
Comments:     <Parser> W: TO field duplicated. Last occurrence was retained.
Comments:     <Parser> W: TO field duplicated. Last occurrence was retained.
From: "Andresen Lab,PC,Physiology" <labandr@OHSU.EDU>
Subject:      Re: Chinese Char Programming Tip Needed
Comments: To: !CCNET-L <CCNET-L@uga.cc.uga.edu>
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
In-Reply-To:  your message  of Tue Sep 13 09:48:25 -0700 1994
Status: RO

...

<  m using a 24x24 bitmap font for the characters.  I've got an
< algorithm that reads the bitmap from the font file and displays it
< one pixel at a time on the screen.  It works fine for displaying
< individual characters, but to display a screenful of characters takes
< about 15 seconds (even if it is a screenful of the same character
< repeated, eliminating the disk read time!).  Obviously plotting
< characters a pixel at a time is going to be too slow.

< I find that if I plot the entire image at a time (using GetImage and
< PutImage in PASCAL), filling the entire screen with the same character
< takes less than one second--this is clearly the way to go.  The
< problem is, I don't understand how these two procedures store the
< bitmap image.  If I knew that, perhaps I could find some way to
< translate the 24x24 font data directly into this pascal image format,
< load it into memory, and then PutImage it to the screen.  Does any
< body have any ideas?

< I'm using Turbo Pascal 5.5, by the way, and am in hires graphics mode.
< If there is some other technique I am overlooking for getting these
< characters on the screen QUICKLY I would love to hear about it.

< (By the way, each 24x24 character is represented by 72 bytes of data,
< each byte representing eight pixels in a single character row)

< Many thanks for any suggestions you can offer,

< Dave Porter

Dear Dave:

These technique may solve your problem:

1) Put as much bitmap file as you can in RAM. You may even consider 16-bit DOS
   or 32-bit DOS.

2) Do not use something like putpixel to display bitmap on the screen. This
   kind of coocked function is very slow. You need write your bits or bytes
   directly onto video RAM.

3) I do not know Pascal, but in C/C++, there are also something like
   GetImage and PutImage, where getimage loads graphics to RAM and putimage
   copies graphics from memory to video RAM. Thus, PutImage functions fast.


Mingyong Yang
<LABANDR@OHSU.EDU>

From owner-ccnet-l@UGA.CC.UGA.EDU Sat Sep 17 12:38:11 1994
Return-Path: <owner-ccnet-l@UGA.CC.UGA.EDU>
Received: from uga.cc.uga.edu by ifcss.org (4.1/IFCSS-Mailer)
	id AA10273; Sat, 17 Sep 94 12:38:09 CDT
Message-Id: <9409171738.AA10273@ifcss.org>
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 2953; Sat, 17 Sep 94 13:36:17 EDT
Received: from UGA.CC.UGA.EDU (NJE origin LISTSERV@UGA) by UGA.CC.UGA.EDU (LMail V1.2a/1.8a) with BSMTP id 7176; Sat, 17 Sep 1994 13:36:16 -0400
Date:         Tue, 13 Sep 1994 02:38:50 MYT
Reply-To: Ng Liang Shing <liang@HSNG.PL.MY>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: Ng Liang Shing <liang@HSNG.PL.MY>
Subject:      Re: Architecture of Chinese Character Input Output System
Comments: To: HU Bo <ucc02au@sunmail.lrz-muenchen.de>
Comments: cc: Chinese Computing Network <ccnet-l@uga.cc.uga.edu>
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
Status: RO

I wrote:
> > The invasive approach enjoys (?) the benefits of information hiding. Here, the
> > running application need not be aware of the presence of the Chinese systems.
> > Therefore, in DOS and other operating systems, some (but not all) existing
> > programs can be ported for Chinese use at binaries level. The safe approach,
>                   ^^^^^^                 ^^^^^^^^^^^^^^^^^

Hu Bo replied:
> Why don't you say straight forward: No portation needed at all?
> As a user, it is much betterto have choice to test existing programs together
> with an existing Chinese system than to wait some applications ported for
> Chinese use in your "save" manner.
>
> A peer-to-peer comparison between C-Win and CStar shows that the "save"
> manner has often got many serious problems: For example, you have to
> have two different versions of Windows, of WinWord, of... It is often a
> very hard decision "what shall I do today, Chinese or non-Chinese?",
> since it is not a quick job to exit from one and then go into anthoer.

This is a good point.  I omitted it earlier for I could not possibly talk
about all aspects of the Chinese software.

My contrary point to the your argument above would be:

Your argument is good from the point of view of the users, but not the
programmers. When buying a natively non-Chinese apps, the user is effectively
paying the non-Chinese programmers and they are earning our money. (Pardon me
for sounding a little chauvinistic.) Then Chinese programmers loses many jobs.
If Chinese programmers make our own programs, and the Chinese users buys them,
then the Chinese programmers are earning money, not the non-Chinese.

This is what we said Don't let the fertilizer flow into the farm of others.
(Fei Shui Bu Liu Wai Ren Tian).


Another point that may be a better idea than using CStar, is to have a Chinese
Wordprocessor, for example, running in Standard Windows. (e.g. NJSTAR). Of
course, this is not as good as using CSTAR in the sense that CStar make all
other applications including Paintbrush etc Chinese. But a Chinese WP may be
easier to use (genuine Chinese interface) and is indeed safer than a patcher
like CStar.

Again, to have to buy separate Chinese software for separate applications may
be difficult for the users. But again, this gives the programmers oppotunity
to write more Chinese softwares and earn more money. This is of course better
than letting CSTar monopolises the revenue.

Third point:

Here, it may or may not be viable for a Chinese to write a heavy duty software
like Corel Draw. If it is not viable at the moment, to make Corel Draw
Chinese-compatible without overriding the system area, we can use many
features offered by Windows such as Clipboard, DDE and OLE! We edit Chinese
text using another small program, written by Chinese programmer, then cut and
paste it into Corel Draw. But I believe one day Chinese programmers will be
able to compete head to head with Corel Draw. And again, I think it is better
not to let the fertilizer flow into the farms of others.

Another approach would be to have Corel Draw Chinese-Compatible natively - let
the Corel's programmer add Chinese functions into Corel Draw at source level.
But to do this they need to employ Chinese programmers too.  So in this way,
the Chinese programmers also earn the money.

Microsoft need not sell two versions of Windows, Winword technically. They can
put Chinese functions into their Windows, Winword natively, without producing
a Chinese version, which also preserves all the English functions. I think
they only do this for business sake - so that the users have to buy two
versions of Windows, two versions of Winword. This is purely a business
stategy.


My definition of Chinese programmers is: programmers who write programs that
is able to process Chinese, it does not matter if the programmers themselves
are Chinese in the ethnic sense.


I wrote:
> > systems. Modern operating systems are towards this end. Hence invasive Chinese
> > system may dwindle with the end of the DOS era.

Hu Bo replied:
> But you have just shown that CStar is available on Windows.

This depends on your definition about Windows. I only Windows as a graphical
user interface for DOS. The reason that Cstar can survive in Windows is
because this version of Windows runs on DOS, which in turn is not robust - no
stringent memory protection - so CStar or any body can easily modify its
system area.

The newer Windows may be different. If as claimed, they are a proper Operating
System at its own right. Then, perhaps it would not be so easy for CStar to
override the system area, though we do not know if it is possible or
impossible as yet. But if it is possible to patch OS/2 at binaries level to
enable Chinese, then it should be possible for the newer Windows. But have any
one heard of patching OS/2 for Chinese?

--
Ng Liang Shing            |   This is an Internet node host inside
Sungai Petani, Malaysia   |   an old 286.  A few years back, this place
liang@hsng.pl.my          |   was not more than a small town.

From owner-ccnet-l@UGA.CC.UGA.EDU Sun Sep 25 02:02:35 1994
Return-Path: <owner-ccnet-l@UGA.CC.UGA.EDU>
Received: from uga.cc.uga.edu by ifcss.org (4.1/IFCSS-Mailer)
	id AA15303; Sun, 25 Sep 94 02:02:33 CDT
Message-Id: <9409250702.AA15303@ifcss.org>
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 5478; Sun, 25 Sep 94 03:00:54 EDT
Received: from UGA.CC.UGA.EDU (NJE origin LISTSERV@UGA) by UGA.CC.UGA.EDU (LMail V1.2a/1.8a) with BSMTP id 8463; Sun, 25 Sep 1994 03:00:53 -0400
Date:         Sat, 24 Sep 1994 22:43:17 MYT
Reply-To: Ng Liang Shing <liang@HSNG.PL.MY>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: Ng Liang Shing <liang@HSNG.PL.MY>
Subject:      Building blocks of Chinese programs
Comments: To: Chinese Computing Network <ccnet-l@uga.cc.uga.edu>
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
Status: RO

Bulding Blocks of Chinese programs


For those who wish to write their own Chinese system to replace C-Star or
Eten, and those who simply wish to know how Chinese system works, and those
who wish to write some good Chinese application programs,

A friend of mine who recently join Internet (Mr. Ooi <ooi@eden.pl.my>) told me
some problems he faced when writing customised database programs for his
Chinese customers. One is that most users (here in Malaysia) does not have a
Chinese system like Eten preinstalled on their PC. So they would have to
install Eten/ZhenHan system just to run his database programs. This cost is
added to the cost of his programs. If the program can run without a Chinese
system like Eten/Zhenhan, then it would be easier to sell his program because
it is cheaper. The other problem is that users have different version of
Chinese system that uses different character set. This causes severe
compatibility problem. To suit the needs of the customer, he would need to
write different version of the same program because his programs must run on
the users' Chinese system. We thinks that if the Chinese functions can be
compiled into his programs, then his program will not need to run on top of
any Chinese system, thus eliminating the compatibility problem altogether.

The second problem reminded me of a newspaper article several weeks ago in a
local newspaper (XingZhouRiBao). It is about the announcement of People's
Republic of China National Standard for Chinese System. (CNSCS, or whatever it
is called on the net.) In conjunction with this is the launch of Chinese
version of MS-DOS 6.22, which is the first Chinese System to comply with
CNSCS. The aim of CNSCS is to establish a standard for Chinese System, such
that to eliminate compatibility problems between Chinese systems.
Consequently, application development will be much easier. Details about the
CNSCS was not available here. (Any where?)

My first impression is that this standard should be there ten years ago. It is
ten years late now.

My second impression is that the majority (represented by the National
Standard organisation) is still stuck with the conventional architecture of
Chinese systems - Chinese applications must run on top of a Chinese system.
There are two biases of the conventional architecture - first, the Chinese
system is a third party system program (Eten,CStar); second, the Chinese
system is built in the operating system (Chinese MS-DOS 6.22, Chinese
MS-Windows).

An alternative to the conventional architecture consitutes of Chinese
applications running without a Chinese system. This is a universal solution.
Because the applications is independent of the Chinese system, the
applications will run if a Chinese system is not present, or even if the
Chinese system is present, and because of its independence, the applications
will also run. This type of application programs will be suitable outside
China. It is also suitable in China, because it could run on top of a Chinese
system though it does not need to access it. An example is NJSTAR, my
favourite word processing program.

The alternative architecture is still a minor stream at the moment. But it
should have very large potential to grow. Programs like Mosaic should adopt
this architecture to enable Chinese processing. Mosaic is an Internet browser.
On the Internet there are many languages. To process multiple languages,
Mosaic should be equiped with functions that process multiple languages.
Mosaic must be portable across all platform.  If Mosaic depends on an external
Chinese system for Chinese processing, then it won't be portable across all
platform. The same argument applies to other application programs.

To implement the alternative architecture, there should be a Chinese function
library that can be used when compiling or running the program. So the Chinese
functions will become part of the program. Then the program will be able to
process Chinese characters when it is run. The aim of the alternative
architecture are firstly to cut cost and secondly to eliminate dependency and
incompatibility.

The important building blocks in a Chinese function library are character
input and output functions. Imagine, to process ASCII, we need to have
printf() and scanf(). So to process Chinese characters, we need to have the
Chinese equivalent of printf() and scanf() too.

Because Chinese character processing is more complicated, we can imagine that
the Chinese scanf() and printf() is more complicated than its ASCII
counterpart.

Next, we shall see how complicated the Chinese scanf() is such that it
requires object oriented programming techniques so as to implement it
efficiently.

part I ... to be continued .....

--
Ng Liang Shing            |   This is an Internet node host inside
Sungai Petani, Malaysia   |   an old 286.  A few years back, this place
liang@hsng.pl.my          |   was not more than a small town.

From owner-ccnet-l@UGA.CC.UGA.EDU Sun Sep 25 02:04:45 1994
Return-Path: <owner-ccnet-l@UGA.CC.UGA.EDU>
Received: from uga.cc.uga.edu by ifcss.org (4.1/IFCSS-Mailer)
	id AA15329; Sun, 25 Sep 94 02:04:43 CDT
Message-Id: <9409250704.AA15329@ifcss.org>
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
   with BSMTP id 5479; Sun, 25 Sep 94 03:01:21 EDT
Received: from UGA.CC.UGA.EDU (NJE origin LISTSERV@UGA) by UGA.CC.UGA.EDU (LMail V1.2a/1.8a) with BSMTP id 8480; Sun, 25 Sep 1994 03:00:58 -0400
Date:         Sun, 25 Sep 1994 14:45:08 MYT
Reply-To: Ng Liang Shing <liang@HSNG.PL.MY>
Sender: Chinese Computing Network <CCNET-L@uga.cc.uga.edu>
From: Ng Liang Shing <liang@HSNG.PL.MY>
Subject:      Building blocks of Chinese system, part II
Comments: To: Chinese Computing Network <ccnet-l@uga.cc.uga.edu>
To: Multiple recipients of list CCNET-L <CCNET-L@uga.cc.uga.edu>
Status: RO

Building Blocks of Chinese Systems

part II


Chinese programs are examples of 'Two-window Model'. ASCII programs are
examples of 'One-window Model'. This argument applies to all Chinese programs
of both conventional and alternative architecture.

To illustrate what is meant by one-window model and two-window model, consider
an example of ASCII program and a Chinese program.

A Chinese program would have two windows presented to the users when it is
running. One is the main window. The other is the input window. For example,
when Eten is loaded, the input window appears at the bottom of the screen. The
remaining part of the screen is the main window. DOS prompt appears in the
main window, or when an application program like PE2 is run, PE2 occupies the
main window. In the input window, the current input method is indicated, e.g.
[Cangjie] or [ZhuYin] etc.

As constrast to a Chinese program, a ASCII program would only have one window,
which correspond to the main window of the Chinese program. ASCII programs do
not require an input window because input method in ASCII is trivial.

The same sort of windows appear in Chinese word processor like NJSTAR. At the
bottom of the screen is the input window, and the remaining part of the screen
is the main window, in which the text are displayed.

The same sort of windows also appears in Microsoft Windows environment. For
example, when Chinese Star is loaded, the input window appear at the bottom of
the screen, although in MS-Win, this windows can be moved around. In Chinese
MS-Windows, the input windows appear when Chinese input method is activated.
Although in MS-Win environment, there are many windows, but our terminology
'two-window model' refers to the current active main window and the input
window.

The two-window model also applies to non-keyboard input such as pen input. In
Eten, when the pen input is activated, the pen input window appears on the
screen.

We have shown that Chinese input mechanism is essentially more complicated
than ASCII input mechanism, which is indeed trivial. And we conclude that at
when input from an device is required for Chinese system, we need to have two
windows - the main window and the input window.


If we look at the history of object-oriented programming, we can say that the
development of OOP is indeed driven by the needs of windows environment.  The
structured programming techniques proved to be insufficient or inefficient for
windows environment, in which we need to deal with many windows of the same or
different types.  Each windows can be regarded as an object.  Types of windows
are pull down menu, dialog box, or the main window itself.

Although the original C language can be used for programming in a windows
environment, it is more efficient to use C++. It is possible to use structured
programming techniques to deal with two-window model, but it is more efficient
to use OOP to deal with two-window model. Hence for Chinese functions, it
would be more efficient to use OOP.

We shall consider three types of character input functions: getchar(),
getstring() and getpage(). getchar() gets a character. getstring() gets a
string of characters in one dimension or one direction (from left to right or
from top to bottom or from right to left), while getpage() gets a page of
characters in two directions. getstring() is built upon getchar() and
getpage() is built upon getstring().

Three parameters are required for getchar() in Chinese. They are a variable of
type Chinese character (16-bit wide or 32-bit wide) to hold the return value,
a handle to the main window, and a handle to the input window. For getstring()
and getpage(), sufficient storage space must be allocated for the returned
characters.

When the function getchar() is called, the input window is activated. Device
input (e.g. key stroke or pen input) is translated into Chinese character
code. The results are displayed in the input window, and the user is allowed
to decide or choose from a list of characters. e.g. If the input window is in
ZhuYin mode, usually a list of characters are listed and the user shall pick
one character. The result is stored in the allocated space, and the main
window is activated and the result is also displayed in the main window.

The size of the input window can vary depending on the input mode. In an Apple
Mac system for example, the input window is very large, consisting of up to
hundreds of characters when Pinyin method is used. Or for pen input, the input
window must be large enough to hold the bitmap. On the usual DOS or MS-Win
system, the input window is usually one long bar.

The psuedo code for getchar() would be,

getchar(char c, MainWin mw, InputWin iw)
{
....
iw.activate()
....
mw.activate()
....
return c
....
}

The properties of InputWin is hidden from getchar(), so is the properties of
MainWin. Programmers are free to write their own functions or methods for the
input windows and main windows, then 'plug' it into the getchar() functions.
This is only possible in OOP.

getstring() would consist of a loop while not end of line of getchar().
getpage() would consit of a loop while not end of page of getstring().


I hope I have given you some ideas of writing the Chinese input functions. I
have omitted the discussion of putchar() here, which is at a lower level. Also
omitted is the Chinese input dictionary look up algorithm. Any comments or
requests are welcome.


--
Ng Liang Shing            |   This is an Internet node host inside
Sungai Petani, Malaysia   |   an old 286.  A few years back, this place
liang@hsng.pl.my          |   was not more than a small town.

From owner-ccnet-l@UGA.CC.UGA.EDU Fri Mar 29 04:14:08 1996
Received: from uga.cc.uga.edu (uga.cc.uga.edu [128.192.1.5]) by ccic.ifcss.org (8.6.11/8.6.11) with SMTP id EAA09335 for <yjj@IFCSS.ORG>; Fri, 29 Mar 1996 04:14:03 -0500
Message-Id: <199603290914.EAA09335@ccic.ifcss.org>
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R3)
   with BSMTP id 6668; Fri, 29 Mar 96 04:06:43 EST
Received: from UGA.CC.UGA.EDU (NJE origin LISTSERV@UGA) by UGA.CC.UGA.EDU (LMail V1.2a/1.8a) with BSMTP id 3031; Fri, 29 Mar 1996 04:06:42 -0500
Date:         Fri, 29 Mar 1996 09:58:08 +0100
Reply-To: POUILLES Albin <Albin.Pouilles@ANSF.ALCATEL.FR>
Sender: Chinese Computing Network <CCNET-L@UGA.CC.UGA.EDU>
From: POUILLES Albin <Albin.Pouilles@ANSF.ALCATEL.FR>
Subject:      Re: Displaying Chinese Characters in Smaltalk
To: Multiple recipients of list CCNET-L <CCNET-L@UGA.CC.UGA.EDU>
Status: R

Manyi Lu wrote:
>
> On Thu, 28 Mar 1996, ZUCKER Jean-Daniel 45.55.63.38 wrote:
>
> > Dear Netters,
> >
> > I would like to know if anyonne has had the experience of
> > displaying chinese characters in smaltalk (in GB). If so what fonts
> > do I need to download.
>
>  I have the same problem, but in c/c++. I have never done any chinese
> programming before, but found it very interesting, where should I start?
>
>   Thanks in advance.
>
>    Manyi Lu
Hello,

Displaying chinese characters is not a problem specifically due to the
programming language you use. One chinese character is encoded in 2
bytes. You need to be able, through the programming language, to send
these two bytes to the display interface. For example, you can have
a two character character-string containing the character you want to display.

All you need then, is when you "print" this 2 byte character string :

- The programming language does not filter the left-most bit, nor add
a carriage return

- the display environnement is able to display the character, i.e.
have the corresponding chinese font.

For example, under X-Window, the XDrawText function prints a character
string, but to print double byte encoded characters, you have to use
XDrawText16.

So, if the language does not provide functions for 2-byte encoded characters,
you have to check if you display environement provides it,
find the function in the display lobrary that enables you to do it
and interface it with your program.

Well, this is just a rough idea to get you started.

Best regards

Albin Pouilles

--
Albin.Pouilles@ansf.alcatel.fr

                      _\\|//-
                      ( 0-0 )
-------------------o00--(_)--00o------------------

                   .oooO
                   (   )   Oooo.
--------------------\ (----(   )------------------
                     \_)    ) /
                           (_/

From apng-sec@apng.org Tue Apr  9 00:21:40 1996
Received: from ins.apng.org (ins.apng.org [130.69.251.150]) by jolt.eng.umd.edu (8.7.5/8.7.3) with SMTP id AAA03204 for <yjj@Glue.umd.edu>; Tue, 9 Apr 1996 00:21:33 -0400 (EDT)
Received: from hermes.ee.nthu.edu.tw ([140.114.28.27]) by ins.apng.org (8.6.12+2.4W/3.4W-1.0) with SMTP id MAA03860 for <apng-cc@apng.org>; Tue, 9 Apr 1996 12:30:31 +0900
Received: by hermes.ee.nthu.edu.tw (4.1/SMI-4.0/shin-1.0)
	id AA17615; Tue, 9 Apr 96 09:22:39 CST
Date: Tue, 9 Apr 96 09:22:39 CST
From: shin@hermes.ee.nthu.edu.tw (Jing-Shin Chang)
Message-Id: <9604090122.AA17615@hermes.ee.nthu.edu.tw>
To: apng-cc@apng.org, thmail@net.tsinghua.edu.cn
Subject: Re:  X Windows Text Widget
Status: R

| Hi,
|     I'm from Tsinghua University.  I have a friend asking me the 
| following question.  Does anyone know the answer ?  Thank you very much !
| 
| Liang Qiming
| ---------- Forwarded message ----------
| Do you know any Chinese X Windows Text Widget avialable in mainland or 
| Taiwan?

I don't think there is any such Widget publicly available in Taiwan,
in particular, in source form. The Chinese supports in X are really bad.
However, there is a publicly available Chinese/English bilingual DeskTop
publishing software which were implemented on X (Motif && Openwin).
You can search the package in (??):

ftp.ifcss.org:/pub/software/linux/X11R6/dtop1.4/

or its mirrow sites in Honkong, Singapore, USA. This is probably
the best high-end X/Chinese application currently available in
Taiwan.

In addition to the Chinese/English text area, all menu items in Dtop
can be configured as either Chinese/English items using external
resource files. For more technical information, you can contact:

	dtop14@bdc.com.tw, dtop-service@bdc.com.tw, or webmaster@bdc.com.tw

I guess they must have something like "Chinese X Windows Text Widget"
in their private source code libraries.

The free package is large because it was ported from a commercialized
Workstation version: it is about 25M, uncompressed. Therefore, you
must allocate a large disk space before downloading. Furthermore, the
free package is a Linux version. You should have a Linux machine
which runs Openwin or Motif window manager.

Shin -^^-


From owner-ccnet-l@UGA.CC.UGA.EDU Sat Apr 13 16:26:06 1996
Received: from uga.cc.uga.edu (uga.cc.uga.edu [128.192.1.5]) by ccic.ifcss.org (8.6.11/8.6.11) with SMTP id QAA19687 for <yjj@IFCSS.ORG>; Sat, 13 Apr 1996 16:26:04 -0400
Message-Id: <199604132026.QAA19687@ccic.ifcss.org>
Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R3)
   with BSMTP id 0475; Sat, 13 Apr 96 16:19:18 EDT
Received: from UGA.CC.UGA.EDU (NJE origin LISTSERV@UGA) by UGA.CC.UGA.EDU (LMail V1.2a/1.8a) with BSMTP id 9398; Sat, 13 Apr 1996 16:19:17 -0400
Date:         Sat, 13 Apr 1996 16:19:28 -0400
Reply-To: Jian-Yun Nie <nie@IRO.UMONTREAL.CA>
Sender: Chinese Computing Network <CCNET-L@UGA.CC.UGA.EDU>
From: Jian-Yun Nie <nie@IRO.UMONTREAL.CA>
Subject:      A stop list of Chinese words
To: Multiple recipients of list CCNET-L <CCNET-L@UGA.CC.UGA.EDU>
Status: R

>
> could you post the list here or upload to ftp;//ftp.ifcss.org
> to be shared with others?  Thanx.
>
> BTW, a simple alternative we're using is to treat all words with
> part-of-speech other than Noun, Verb, Adj. and Adv. as stop words.
>
> GuoJin
Here is the stop list we used for our experiments. Note that a stop list is often
corpus-dependent.
Jian-Yun Nie
---------
,
~{!"~}
~{!#~}
~{!$~}
~{!-~}
~{!.~}
~{!/~}
~{!0~}
~{!1~}
~{!C~}
~{#!~}
~{#"~}
~{##~}
~{#$~}
~{#&~}
~{#'~}
~{#(~}
~{#)~}
~{#*~}
~{#+~}
~{#,~}
~{#.~}
~{#:~}
~{#;~}
~{#?~}
~{04~}
~{04UU~}
~{0Q~}
~{1;~}
~{1H~}
~{1H=O~}
~{2"~}
~{2"2;~}
~{2"GR~}
~{2;~}
~{2;B[~}
~{2;D\~}
~{2E~}
~{3#;a~}
~{3}7G~}
~{4KMb~}
~{4KVV~}
~{4S~}
~{4S6x~}
~{4o~}
~{4sT<~}
~{5+~}
~{5+JG~}
~{51~}
~{51J1~}
~{51VP~}
~{5=~}
~{5=AK~}
~{5C~}
~{5CRT~}
~{5D~}
~{5DH7~}
~{5H~}
~{5X~}
~{6<~}
~{6<;a~}
~{6T~}
~{6TSZ~}
~{6`IY~}
~{6`IY4N~}
~{6`IYHK~}
~{6x~}
~{6xGR~}
~{8C~}
~{8w~}
~{8w5X~}
~{8w8v~}
~{8wVV~}
~{8x~}
~{8|~}
~{8|N*~}
~{9)~}
~{9XSZ~}
~{9}~}
~{:M~}
~{:\~}
~{:s~}
~{:s@4~}
~{;9~}
~{;9JG~}
~{;9SP~}
~{;a~}
~{;n6/~}
~{;r~}
~{;rJG~}
~{<+Fd~}
~{<0~}
~{<0Fd~}
~{<4~}
~{<4J9~}
~{<88v~}
~{<8:u~}
~{<H~}
~{<SRT~}
~{<d~}
~{=+~}
~{=O~}
~{=v~}
~{=xR;2=~}
~{>!9\~}
~{>-~}
~{>-9}~}
~{>M~}
~{>MJG~}
~{>]~}
~{>y~}
~{?I~}
~{?ID\~}
~{?IJG~}
~{?IRT~}
~{@4~}
~{@4K5~}
~{@o~}
~{AK~}
~{AmMb~}
~{AnHK~}
~{C?~}
~{C?8v~}
~{C?R;8v~}
~{CfG0~}
~{D3P)~}
~{D3R;~}
~{D?G0~}
~{DD~}
~{DD6y~}
~{DD7=Cf~}
~{DDP)~}
~{DDR;<~~}
~{DGC4~}
~{DGP)~}
~{DGQy~}
~{DZ~}
~{D\~}
~{Dj~}
~{FZ<d~}
~{Fd~}
~{Fd:s~}
~{FdK|~}
~{FdVP~}
~{Fp~}
~{Fy=q~}
~{Fy=qN*V9~}
~{G0~}
~{Gi?v~}
~{Gk~}
~{H%~}
~{H4~}
~{H7J5~}
~{H;6x~}
~{H;:s~}
~{HC~}
~{HK~}
~{HKHK~}
~{HN:N~}
~{HT~}
~{HTH;~}
~{HTSP~}
~{Hg~}
~{Hg4K~}
~{Hg9{~}
~{Hg:N~}
~{IO~}
~{IuVA~}
~{J1~}
~{J1:r~}
~{J2C4~}
~{J2C4Qy~}
~{J9~}
~{JBJ5IO~}
~{JG~}
~{JG7q~}
~{J\~}
~{K5~}
~{KF:u~}
~{KdH;~}
~{Ky~}
~{KyRT~}
~{KySP~}
~{K{~}
~{K{CG~}
~{K|~}
~{K|CG~}
~{K}~}
~{K}CG~}
~{LX1pJG~}
~{M,~}
~{M,J1~}
~{M,R;~}
~{Mb~}
~{MyMy~}
~{N*~}
~{N*4K~}
~{N*:N~}
~{N*AK~}
~{NJLb~}
~{NR~}
~{N^B[~}
~{OB~}
~{OB@4~}
~{OBH%~}
~{OV~}
~{OVTZ~}
~{Oq~}
~{Or~}
~{Os~}
~{Ph~}
~{Pk~}
~{R*~}
~{R2~}
~{R;~}
~{R;0c~}
~{R;4N~}
~{R;5)~}
~{R;5@~}
~{R;6(~}
~{R;7=~}
~{R;7]~}
~{R;8v~}
~{R;Dj~}
~{R;LW~}
~{R;N;~}
~{R;On~}
~{R;P)~}
~{R;V'~}
~{R;VV~}
~{RQ~}
~{RQ>-~}
~{RT~}
~{RT1c~}
~{RT4K~}
~{RT9)~}
~{RT<0~}
~{RTFZ~}
~{RTGs~}
~{RTMy~}
~{Rr~}
~{Rr4K~}
~{Rr6x~}
~{RrN*~}
~{S&~}
~{S&51~}
~{S&8C~}
~{S&SP~}
~{S&Sh~}
~{SC~}
~{SC@4~}
~{SHFd~}
~{SI~}
~{SISZ~}
~{SP~}
~{SP9X~}
~{SPKy~}
~{SPP)~}
~{SV~}
~{SZ~}
~{ShRT~}
~{Sk~}
~{Sk4KM,J1~}
~{T<~}
~{T<SP~}
~{T=@4T=~}
~{TY~}
~{TZ~}
~{TZSZ~}
~{Tr~}
~{TuQy~}
~{U<~}
~{Ub~}
~{Ub7=Cf~}
~{Ub8v~}
~{Ub@`~}
~{UbJG~}
~{UbOn~}
~{UbP)~}
~{UbQy~}
~{UbR;~}
~{UbR;5c~}
~{UbVV~}
~{U}~}
~{U}TZ~}
~{V.<d~}
~{V.DZ~}
~{V.OB~}
~{V.VP~}
~{V;~}
~{V;D\~}
~{V;JG~}
~{V;R*~}
~{V;SP~}
~{VA~}
~{VP~}
~{VVVV~}
~{WE~}
~{WT~}
~{WT<:~}
~{Wn~}
~{WnVU~}
~{WsSR~}
~{Wv~}
~{Ww~}
~{WwN*~}

