Subject: ZIKU Buffer - part I

From: "L.S.Ng" <[email-masked]>
Date: Fri, 24 Dec 1993 14:08:01 GMT

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.