TL_hzinput.so (Turbo Linux Hon Zi Input Method)
===============================================
Document by Jacky Lau (zenithlau@sniic.com)

This is a document describing the details of TL_hzinput module.
Files:

General Description:
The modules provide a convertor program to convert ascii type input table (*.cin) into binary file (*.tab). Thus the binary file can be used by the input module.
The main product of this package is TL_hzinput.so, a shared library used by unicon.

File format of '*.tab' file
/***************************************************************************
 *		The File format of Turbo Linux Input Method
 *
 *	symbol		len				meaning
 *	cur_table	sizeof (hz_input_table)		the same as CCE
 *	n		sizeof (long)			total phrase
 *	pItem		n * sizeof (ITEM)		read Item
 *
 **************************************************************************/

Compiled Binaries:
TL_hzinput.so
cin2tab

Source Files:
TL_hzinput.c
xl_hzinput.c
xl_phrase.c
xl_sysphrase.c
xl_mfile.c

Header Files:
xl_hzinput.h
xl_sysphrase.h
xl_phrase.h
xl_mfile.h

Data Structure:

API:


Algorithm for cin2tab.c (For TL_hzinput.so module only)
=======================================================
Document by Jacky Lau <zenithlau@sniic.com>

Dependence:
To a certain extent cin2tab in TL_hzinput.so mostly depends on the functions
inside xl_phrase.c and xl_sysphrase.c, which in turns require functions from
xl_mfile.c.

Though cin2tab is originally a tools for converting xcin table to binary table
format for TL_hzinput.so, it is a excellent starting point to learn about the
bolts of TL_hzinput.so. It the most fundamental strunctures will be introduced
here. You can also noticed, the functions of the different fields inside
different data structures.

Algorithm:
Parse Header Information
++ Header information from .cin is capture, parsed and stored inside the .tab

Processing the KeyMap and KeyName array.
++ KeyMap has 128 element, 1:1 mapping against the ascii 7bit latin1 charset.
++ As more than 50% of the 128 char is not usable for input.
++ For e.g. Upper case letter and lower case is the same, control and
++ invisible characters are also useless.
++ Hence, for any input key, we can use KeyMap to map a decimal digit which
++ is 0 <= i < 64,
++ Among various Chinese Input Method, 'input key' is usually defined as some
++ chinese characters. For example, all 26 alphabets has been mapped to a 
++ chinese characters, which is so called "Char Root". It is useful, if input
++ module can echo back these "Char Root" when user is inputting.
++ The mapping of the alphabets and the "Char Root" is done via KeyName array.
++ Hence, KeyName [64][3], for each element, KeyName [i] == "CharRoot"
++ Each KeyName element is a 3 char array, hence, the implementation is
++ assumed each KeyName is at most 2 most chinese character.

For each chardef record, 
++ From the point of TL_hzinput.so (possibly a few other input module), 
++ Chinese Input is just a business of translating a Input Key Sequence to a
++ defined Chinese Character, where the mapping is define in a table.
++ In TL_hzinput.so, Input Key Seq has at most 10 chars.
++ As each Input Key is mapped to a int range from 0 ~ 63 (ref: KeyMap array),
++ We can use some method to store the total 10 Input Key Sequence into 2
++ unsigned int variable (key1, and key2).
++ The method we are used to achieve this, is just seperate the 10 Input Key
++ Sequence into two parts, for each one, we can shift each Key into one 
++ unsigned int.
++ For each Key (0~63), only 6 bits is enough to store the key, hence, one 32
++ bit int can store at most 5 key.
