Subject: Re: HBF Std v1.0

From: ~{QG9p~} <[email-masked]>
Date: Wed, 7 Apr 1993 23:42:38 -0500

So I guess the HBF business is done for now.  Hope you guys
are ready for something different.

The following proposal is for a HZ-like spec for mixing
ASCII, GB, Big-5, and possibly others in the same documents.

An example of the mixed text would look like,

    aaa~{gbgbgbgb~(b5b5b5b5~+B5~(b5b5b5b5b5b5~}aaaaaa

I am hoping that big-5 can be cleanly divided into two sections,
where the most frequently used characters are in one section
and the less frequently used ones in the other.  This is quite
important.  (The "B5" in the above example represents the less
frequently used section, switching to it requires two sets of
2-byte escapes, requiring a total of 6 bytes for the character.)

More detail follows.

  Ya-Gui

--

      A Proposal To Extend the Current "HZ" Specification
   To Accommodate Other East Asian Coding Standards (Draft 1.0a)

                         Ya-Gui Wei
                       April 07, 1993

The "HZ" representation (Fung Fung Lee, 1990) of GB2312 Chinese text
has been implemented in various software packages under different
platforms, and tested in the usenet newsgroup "alt.chinese.text" and
various other forums with considerable success. This proposal seeks
to expand the specification to _simultaneously_ accommodate other
East Asian coding standards under an umbrella scheme that is
analogous to the original "HZ" scheme.

This proposal is first posted to [email-masked] to solicit
comments, and may be posted to other forums at a later time.

  * ESSENSE of "HZ"

The "HZ" standard defines a way of integrating ASCII characters with
GB2312 Chinese characters (represented as two printable ASCII
characters). The following ASCII sequences are defined as special:

   ~{    --  escape from ASCII to GB2312
   ~}    --  escape from GB2312 to ASCII
   ~~    --  the ASCII character ~
   ~\n   --  line continuation

"HZ" further stipulates that an ASCII new line sequence serves
as an automatic escape back to ASCII. Furthermore, the ~\n line
continuation sequence is permitted in the ASCII context only.

  * CONSOLIDATION OF CODES

I hereby propose to extend the "HZ" specification to create a
Consolidated Collection of East Asian Coding Standards (CCEACODE,
hereafter), to allow for the simultaneous transport of text of the
different languages or coding standards.

Briefly, all the remaining tilde- sequences of "HZ" will be defined as
special under CCEACODE, which will be used as escape signals for
transition among East Asian Language (EAL, hereafter) code blocks,
as well as between EAL code blocks and ASCII.

CODE BLOCKS: Code Blocks of 93 rows-by-94 columns will be defined
by CCEACODE, with each character within an code block represented
by two printable ASCII characters. 

If two consecutive characters are from the same code block, no
special attention is needed. If two adjacent characters are
from different code blocks, a special tilde- sequence is inserted in
between to signal the transition between code blocks.

For example, if ~{ is used for transition into GB (Chinese) text,
and ~[ is used for transition into Japanese JIDOS text, and ~} is
used for transition into ASCII text, then examples of mixed ASCII,
GB and JIDOS text may look like:

      aaaa~{gbgbgbgb~[jijijiji~}aaaa
      aaaa~[jijijiji~{gbgbgbgb~}aaaa

  * PROPERTIES

- Large Code Space. CCEACODE can accommodate 92 code blocks, with
each block having 93 rows, and each row having 94 characters. This
results in a code space of up to 804,000 characters, or 19.6 bit
equivalence, while each character takes up only about 14 bits in the
data stream. (Contrast this to 16-bit schemes, which would have a
mere 65,000 character code space, with each character taking up 16
bits in the data stream.)

- CCEACODE will be a superset of ASCII. Under CCEACODE, ASCII text
will remain as 7-bit (single-byte) characters, with no need to widen
them into multiple byte sequences. The only exception being that an
ASCII "~" character will be represented by the two byte "~~" sequence.
(Contrast this to 16-bit uniform width schemes, which would widen each
ASCII character to 16 bits.)

- CCEACODE will be a superset or partial superset of all the East Asian
coding standards it seeks to accommodate.

- CCEACODE will be a superset of the original "HZ" Specification.

- CCEACODE encoded multilingual text will be indistinguishable from
ASCII text at the byte level, thus ensuring compatibility with existing
software and hardware.

  * SUPPORTED CODING STANDARDS

CCEACODE does not attempt to define any of the characters within its
code space. Instead, its code space will be allocated to the various
national or industrial coding standards in blocks, and individual
characters will be defined by these national or industrial coding
standards. CCEACODE will also standardize the tilde- escape
sequences and the exact positioning of national/industrial standard
character sets within the CCEACODE code space.

Only standards of wide-spread recognition and/or prominence will
be accommodated in CCEACODE.

Code blocks, each 93x94 in size, are allocated to accommodated
standards by assigning a tilde- special sequence to the standard,
indicating that text following the sequence will be interpreted
using the said standard.

Proposed CCEACODE tilde- special sequence assignments (undefined
tilde- sequences are reserved for future expansion):

   ~}    --  escape to ASCII
   ~{    --  escape to Chinese GB2312
   ~(    --  escape to Chinese Big-5 primary 
   ~+    --  escape to Chinese Big-5 secondary
   ~[    --  escape to Japanese (JIDOS?)
   ~]    --  escape to Korean (standard?)
   ~~    --  the ASCII character ~
   ~\n   --  line continuation (in ASCII context only)
   \n    --  new line, with implied escape to ASCII
	     (\n = new line sequence, may be platform-specific.)

  * NAME OF THE GAME

This proposed specification is tentatively named "Consolidated
Collection of East Asian Coding Standards", with acronym CCEACODE
(pronounced "see code").

I have intentionally avoided the term "Unified" in the name so as
to avoid discussions of "Han Unification". I am not against "Han
Unification" per se, but I believe it has its weekness and it is 
incompatible with the spirit of accommodating existing standards.

[End of Document]