Subject: Dynamic Font Buffer

From: "L.S.Ng" <[email-masked]>
Date: Sat, 22 Jan 1994 13:03:23 GMT

Dynamic Font Buffer
===================

Introduction
------------
I have discussed briefly the concept of Font Buffer (or ZIKU Buffer) in
a posting to CCNET-L earlier.

Just to refresh our memory, consider implementing a prototypical
'chprintf()' (Chinese Print Function).

The parameter in this function is a string of Chinese character code.
These codes directly map to a position of the font data residing either
in a disk file or a memory block. Such a disk file would be a Chinese
font file e.g. CCLIB.16. If we fetch font data intensively, it would be
much faster if the font data resides in a memory block instead of a disk
file. Such a memory block is called Font Buffer.

Dynamic Font Buffer
-------------------
How much memory should we allocate for Font Buffer? With Dynamic Font
Buffer (DFB), the size of memory required is dependent on the number of
character code used. e.g. In a typical Chinese article, statistics shows
that only about 500-1000 character codes are used. So the required DFB
is 1000x32 = 32000 bytes (assuming we use 16x16 font).

We maintain a table of pointers that points to the actual position of
the font data.  The index of this table of pointers is none other than
the character code itself.  So for GB coding scheme, we require about
8000 character code.  The size of the table is then 8000x2 = 16000 bytes
if we use 16 bit pointers, which can address up to 64K of memory.  So we
can hold 64K of font data, equivalent to 2000 characters of 16x16
bitmap.  This should be sufficient for normal application.  Using 32 bit
pointer will be slower and should only be used if we need to handle
large and very special document, such as dictionary.

On intialisation, all pointers in the table are reset to null.  We then
fetch font data from Font File and store them in the Font Buffer and set
the pointers accordingly.  We may fetch as many character as
anticipated.

When the function chprinf() is called, it translate the each character
code into the index to the table of pointers of the DFB.  If the pointer
is null, then we call another routine that fetch Font Data from File and
store it in the DFB.  If it is not null, then we fetch the font data
from the DFB.

Note that, the Font Data of each character would need only ONE fetch.
After the first fetch the pointer is set.

If the pointer is set (not null), then we fetch the font data from the
DFB directly.

Extensions
----------
The most basic implementation of DFB, as described above, use 16 bit
pointers with 64K addressable space for Font Data.

To extend this, we can either use 32 bit pointers or Segmented memory
with 16 bit offset.

In segmented memory with 16 bit offset, we can allocate one or more
segments of 64K space for Font Data.

With 32 bit pointers, we can address up to 2^32 bytes of memory space.
The trade off is speed.

So segmented memory with 16 bit offset would be a practical choice.

Applications
------------
As can be seen from some figures above, the memory required for DFB is
as little as 16K minimum for the table of pointers, with variable size
of Font Data space up to 64K. This is a practical approach to small
applications like 'type' command in DOS or 'cat' command in Unix or a
simple file viewer.

The extended implementation would be useful for larger application such
as word processing systems.

Isolating Font File Format
--------------------------
Font Buffer also serve as a medium between Font Files and the display
function (e.g. chprintf()). Hence, when implementing chprintf(), we can
forget about the format of the font files. As cited above, we could call
a separate function for fetching font data from font file.

Routines for fetching font data of particular file format (e.g. HBF,
Feicangguizi) should be available from various sources. As we move into
MS-Windows programming or X-Windows programming, we would need to deal
with new file formats. So isolating font file format from the
implementation of display function using Font Buffer should be
practically useful.

Liangsheng WU
21 Jan 1994
Department of Electronics and Computer Science,
Southampton University.
email: [email-masked] (Southampton)
       [email-masked] (Sungai Petani)

References
----------
File formats :

1. HBF Hanzi Bitmap File, by Dr. Man-chi Pong,
                ftp ifcss.org:/software/fonts/HBF
2. Feicangguizi, by myself, email for details.

A utility for counting number of character codes in a document,
   COUNT.BAS, by myself, email me for a copy.

Font file: CCLIB.16, ftp ifcss.org:/software/fonts

ZIKU Buffer part I, by myself, email for details.

CCNET-L, Chinese Computing Network List, email [email-masked] for
    details.

A Q&A on Guobiao Coding and CCLIB.16, compiled by Zhang Jin,
    email me for details

A Chinese PRINT and LPRINT for QBASIC, by myself,
    ftp ifcss.org:/software/misc/yinzi.zip