Welcome to the PaulOS3 Font Engine White Paper.
This document attempts to describe the specification of PaulOS3's font rendering engine, including the relevent file formats used for storing the font data.
The core of the PaulOS3 font engine uses a set of interlinked data structures to store information about fonts. The root of this data structure for any given font is defined by the C-struct:
struct PaulFont {
char FontName[100];
int fontType;
bitmapFontSize *bitmap[256];
vectorFont *vf;
} ;
This structure has support for both bitmap and vector fonts in one go. This is partly for performane reasons to avoid unnecessary casting, and partly to allow for a future merging of font types, with both vector data, and bitmaps at certain sizes for optimized viewing. In most cases, however, one of the font pointers will be null.
The FontName string stores the name of the font. Currently, this is the filename of the font file, since the font formats do not store any data other than the font itself.
fontType specifies which type of font it is, and therefore whether to use the bitmapFontSize data or the vectorFont data. 0 indicates bitmap font, and 1 indicates vector.
The bitmapFontSize structure is defined as follows:
struct bitmapFontSize {
int size;
int glyphwidth[256];
char *glyph[256];
};
The size field defines the height of this particlar set of glyphs in pixels. This is partly irrelevent and is used as a verification check, since each font-size is stored in the appropriate array offset in the root structure. There are a number of special cases. A size of 0 means that this size has not been defined. Is this value is larger than 255 it is invalid, since 255 is the largest font size supported by PaulOS3. If the value of size does not match the value expected according to the array offset in the root structure, the data is also considered to be invalid.
The glyphwidth array contains the width, in pixels, of each glyph at this size. All the glyphs have the same height, as defined in size.
The glyph array is an array of pointers to blocks of data defining each glyph. So, glyph[34] should refer to a speech mark, since PaulOS3 uses ASCII to represent characters. The data block is a set of chars used to store the intensisty in a bitmapped fasion. Entire chars are used instead of single bits for each pixel of the glyph to allow the font to be pre-anti-aliased.
Because of the large amount of data involved, not all font sizes from 1 - 255 are stored in the font file for bitmap fonts (although there is nothing to stop them being). Instead, "common" sizes are stored, and the rest are interporlated from them by simple resizing. To improve performance, when a font size that is not already existing is accessed for the first time, that size is generated in it's entirity (all glyphs) and stored in the structure. It does not get saves to the file, only cached in memory.
The vectorFont structure is not yet defined, as the vector font engine has not yet been implimented. However, it does NOT use TrueType.
NOTE: PaulFont files are compressed with a basic RLE compression algorithm. PaulOS3 does not support loading uncompressed fonts. However, for ease of notation, this document refers to them in uncompressed form. Also, owing to the type of compression used, font files are strictly sequential. They are read from beginning to end, with no seeking involved.
The Primary Header is what identifies the file as a PaulFont file. This consists of eight bytes: PaulFont - that is, upper case P, lower caser A, lower case U, lower case L, upper case F, lower case O, lower case N and lower case T, stored in ASCII.
Following this is a single byte which identifies the type of font stored in this file. 0 = bitmapped font.
Font data for each size is stored one after the other, so the following data layout is repeated.
First, there is a single byte, which defines what pixel size this font is. This is the height of the font. A value of zero means that there is no more data. If this occurs first then the font file has been corrupted as there is no valid sizes stored in it.
Following this are the 256 glyphs that make up the font at this size, stored as follows:
A single byte, specifying the width of this glyph.
A linear bitmap of widthxsize bytes, defining the bitmap of this glyph at this resolution. Each byte defines the intensity of the pixel at that location when rendered.
By the way, it is because of the large amount of data involved here that the files are compressed. As an example, the basic default bitmap font, which is based on Arial, was 14MB before compression was added. After compression is comes down to about 1MB.