Subject: Segmented model for Font Buffer

From: "L.S.Ng" <[email-masked]>
Date: Fri, 18 Mar 1994 23:13:29 GMT

Having talked about a few points on merit of using font buffer, here is
some points on implementation.

Memory needs to be allocated for font data (converted to bitmap). A
table of pointers needs to be maintained. Each pointers points to the
address of the bitmap of a character. The table of pointers is indexed
according to the code of a character. (e.g. Guobiao code)

Using the simple memory model, the table size required is Code Space
(94*94= 8836 for Guobiao) times the pointer size. i.e. 32 bits. =  35344
bytes. (Since we would normally need to access more than 64K of bitmap
equivalent of bitmap font data, we need 32 bits pointer. A 24x24 bitmap
(decent by today's standard), is 72 byte big. A 64K block can only
contain 910 of them.)

The size of the table can be reduced from 35K to 9K by using segmented
memory model. In this scheme, two tables are maintained. The first table
consists of a total of 94 32-bits pointer. The second table consists of
a total of 8836 8-bits offset. So the bitmap address of a character can
be calculated as follows:

bitmap address =
       32-bits_pointer[HIbyte of GB code]
       +  (8-bits_offset[GBcode])*sizeof(bitmap)

Where sizeof(bitmap)=72 for 24x24 bitmap.

The tables are now 94*4=376 bytes and 8836 bytes big respectively,
making a total of 9212 bytes.

Bitmap is important if you are working with bitmap device. Nowadays most
device are bitmap. Vectored device are rare. Regardless the original
format of a font, e.g. TTF, it must be converted to bitmap before
displayed. Font buffer exists to overcome the bottlneck of disk read and
rasterizing, trading off for memory usage, which is nowadays cheap &
plentiful.

Segmented memory model provides a efficient way of handling font buffer.
Although the memory saving achieved is 35-9=26K (only!), it is very much
needed for writing 'very small Chinese programs', especially in some
archaic 16 bits environment (read DOS!!).

Sincerely,
Liangsheng WU