Subject: improve GB (was Why I need Big5)

From: "L.S.Ng" <[email-masked]>
Date: Tue, 11 May 1993 17:20:03 BST

A PROPOSAL to encode Non-standard Chinese Characters
****************************************************

I suggest a solution to Non-standard Charaters:

Aim: To code and display non-standard Characters WHEN NECESSARY.

Method: Include the BITMAP INFORMATION of a non-standard characters WITHIN an
ordinary document. The decoder should read this info and be able to display it.

Assign to a non-standard character a TEMPORARY Guobiao/HZ code which can be any
place in the blank region (region 8 to 15). So as the temporary non-standard
character appear in the text, the decoder will use the BITMAP info to display
it.

Format: To comply with SMTP, use a string of hexadecimal numbers to represent
the bitmap.  For 16x16 bitmap we need 32 bytes, so the hex number equivalent
would be 64 character long. The bitmap info is preceeded by the temporary GB/HZ
code. And all this info can fit into one single line only which should begin
with an identifier. e.g.

zKA8011234ABCDEFAB12345678098374859283BEFA394DCB3948CBDE948503948ABCD..
  ˆ   ˆall this are bitmap info in Hex number, length=64 for 16x16 bitmap
ˆ A801 the temporary GB/HZ code
identifier zK

Extension: For larger bitmap, more lines can be used.

Software:
1. It requires easy to use/flexible font editor. The font editor should be able
to code the bitmap info in Hex number.
2. It requires a text editor which can cut and paste the bitmap info into a
document.
3. The decoder should handle standard GB/HZ coding and when it encounters a
non-standard character, it reads the bitmap info to display it.

Please send your comment to [email-masked]

--------------------
In reply to Shann:
> Sending Big-5 code is NOT such an achievement.  If you have "less", try to
> "setenv LESSCHARSET=latin1" then you can view Chinese, Big-5 or GB, in an
> cxterm.  (Hence you don't need "cless".)  Thus sending Big-5 or GB
> codes without encoding is an equivalent problem with sending latin1
> codes, which include most of the West European characters not defined
> in ASCII, like $\'e$, $\"u$, $\cc$ (these are TeX notations, you can
> guess what they are).

Thanks for these tips.

>
> The world is not going to update sendmail JUST for Big-5 code.  This update
> will be needed and appreciated by users of latin1 codes.  I tried some ftp
> programs and found they are already latin1 compatible.  I "set ascii"
> during an ftp session, then send Big-5 or GB codes.  Then I check, they
> are correct.  That means "ascii" already includes "latin1", hence GB and
> Big-5 are preserved.  Although I am not a computer scientist, but as
> a scientist in general, I can guess the technical difficulty to update
                                          ˆˆˆˆˆˆˆˆˆ
> sendmail to be compatible with latin1 cannot be too much more difficult
> then updating ftp.

ftp is different from SMTP. It has to be agreed by ALL institutions within the
Internet. The former can just be implemented separatly. It is a CULTURAL issue
rather than a TECHNICAL one.

>
> > ... Why use BIG5 at all? Do we need 12000
> > characters (in BIG5) if 7000 (in GB/HZ) is sufficient?

> Since you said you received 10 posting from me.  I guess you are on
> CHPOEM-L also.  Then you must know that, for instance, Dr. Deng and friends
> have input exerts from Hong Lou Meng.  They did it by GB code.  Some > > >
characters
  ˆˆˆˆˆˆˆˆˆˆ
> were missing and they have to describe a character by saying it is A on left,
  ˆˆˆˆˆˆˆˆˆˆˆˆ
> B on right but without C.  This is why I need Big-5, or even more, sometimes
> I need the standard Library code with 30K+ characters (but this code is
> definitely not necessary for usual use).  Big-5 has 5401 frequently used
> codes, it is sufficient for everyday use and can be somehow implemented
> similar to HZ (some good soul is doing that, I believe).  The rest of Big-5
> is sufficient for most ancient works that we may encounter from time to
> time, including Hong'Lou'Meng`, Shi_Jing, Gu^Shi_19, Tang'Shi_300, etc.
>

It seems that neither Big5 nor GB is sufficient for non-standard Chinese
Characters. Your 30K++ character library cannot be a universal solution. Say
a poor student wants to read your document using e-mail, how can that be done?
You have to send him the whole character library, don't you?

**Seriously and Important**

I suggest a solution to Non-standard Charaters:

Aim: To code and display non-standard Characters WHEN NECESSARY.

Method: Include the BITMAP INFORMATION of a non-standard characters WITHIN an
ordinary document.

The decoder should read this info and be able to display it. Assign to a non-
standard character a TEMPORARY Guobiao/HZ code which can be any place in the
blank region (region 8 to 15). So as the temporary non-standard character
appear in the text, the decoder will use the BITMAP info to display it.

Format: To comply with SMTP, use a string of hexadecimal numbers to represent
the bitmap.  For 16x16 bitmap we need 32 bytes, so the hex number equivalent
would be 64 character long. The bitmap info is preceeded by the temporary GB/HZ
code. And all this info can fit into one single line only which should begin
with an identifier. e.g.

zKA8011234ABCDEFAB12345678098374859283BEFA394DCB3948CBDE948503948ABCD..
  ˆ   ˆall this are bitmap info in Hex number, length=64 for 16x16 bitmap
ˆ A801 the temporary GB/HZ code
identifier zK

Extension: For larger bitmap, more lines can be used.

Software: Need easy to use font editor. The font editor should be able to code
the bitmap info in Hex number. The text editor can cut and paste the bitmap
info into a document.

> Now, do you have a feeling why I need Big-5?
>
> I can guess why you hate Big-5.  Because you were educated in simplified
> characters.  Why don't you change mode and thinking in my term.  On the
> contrary I was educated in traditional characters.  But I do want to
> communicate with my far-brothers like you.  I did my part, I installed
> programs to convert GB or HZ to Big-5, and sometimes I can just read
> simplified characters directly.  Why don't you also do it for me, if you
> care to communicate.  It won't be harder then to communicate in English,
> I guess.
> > I just hope that you Taiwanese will discard BIG5 and adopt GB/HZ for you
> > email posting.
>
> Let's do it democratically.  Time will resolve it.
>
> > We are all tired of uudecoding BIG5 documents unless someone will
> > create a SMTP-compliant-BIG5-variant coding scheme like HZ for GB.
>
> If you care to communicate, it is easy to write a C shell script to
> simplify the process of converting from Big-5 to HZ or GB.  I can
> write one for you if you are using UNIX.
>
> Cheers,
>
> -Shann
>

Thanks for your attention
liangsheng wu

---

From: "L.S.Ng" <[email-masked]>
Date: Tue, 23 Nov 1993 22:45:01 GMT

There is a little addenum to my previous posting on the Big 5 encoding.

13973 are the number of Chinese Character plus Symbols defined in Big5
scheme. i.e. From subgroup A1 to F9.

Where as for the Chinese character the subgroups are A4-C6 and C9-F9.
By simple math, the total Chinese Characters are 13488.

But this is not the case, as some subgroups are not fully filled.  To
determine the exact number of Chinese characters, I looked at the 24x24
fontfile STDFONT of Eten 3.0.  The size is 942768.  Each 24x24 character
is 72 byte, so there are only 13094.

> >
> > Bruce also asked:
> >
> > > BTW, how do you retrieve the bitmap from the font file?
> >
> Hey, the original post asked how to do it in CWin. Read it carefully. You
> did not answer my question. Why do you want to deal with the bitmap in CWin?

I don't understand your question. Could you please rephrase it?

> > Whereas to access a TTF, you need to know about the structure of it.
> > (Thanks for your tips, they are in ftp.microsoft.com:/drg)
> > After that, you call a rasterizer to convert it into bitmap and then
> > send it to a device.
> >
> Again. Why do you want to do that? Isn't there an easier way of doing it?

Here is the compromise: If you rely on CWIN, you are limited by CWIN. If
you do it hard, you gain the power. It is up to you.

> > > > (HEX)
> > > > 8E40 - A0FE    USER 1
> > > > A140 - A3FE    SPECIAL 1
> > > > A440 - C67E    COMMON
> > > > C4A1 - C8FE    SPECIAL 2   (JAPANESE & RUSSIAN ETC)
> > > > C940 - F9FE    RARE
> > > > FA40 - FEFE    USER 2
> > > >
> > > > HI BYTE = SUBGROUP NUMBER, RANGE FROM 0x8E TO 0xFA
>                                             ~~~~~~~~~~~~
> > > > LO BYTE = CHAR NO. IN EACH SUBGROUP, RANGE  (40-7E) AND (A1-FE)
> But I didn't get a good answer. According to your post, FA - 8E = 6C and
> 0x6C + 1 = 0x6D which is 109 decimal. Could you explain this elementary
> math to me? (I have to admit that I did learn hexdecimal arithmatic while I
> was in elementary school.)

You missed something, the last subgroup is FE not FA. So 113 = number of
first to last subgroup = last subgroup - first subgroup + 1.

> > ps. By the way, would you like to clip some pages from your MS FE SDK on
> > the Chinese TTF to the net?
>
> How? Type it in?

Yes, please. I guess in could not be more than a good few pages.

Thanks in advance.

Sincerely
Liangsheng WU