The Design of FreeType 2.0
==========================
Introduction:
This short document presents the design of version 2 of the FreeType
library. It is a must read for anyone willing to port, debug or hack
the FreeType sources.
I. Goals :
FreeType 2 was designed to provide a unified and universal API to
manage (i.e. read) the content of font files.
Its main features are :
- A FORMAT-INDEPENDENT HIGH-LEVEL API
Used to open, read and manage font files.
- THE USE OF PLUGGABLE "FONT DRIVERS"
Each font driver is used to support a given font format. For
example, the default build of FreeType 2 comes with drivers for the
TrueType and Type 1 font formats.
Font drivers can also be added, removed or upgraded at *runtime*,
in order to support more font formats, or improve the current ones.
Each font driver also provides its own "public interface" to client
applications who would like to use format-specific features.
- THE USE OF PLUGGABLE "RASTERS"
A raster is a tiny module used to render a glyph image
into a bitmap or anti-aliased pixmap. Rasters differ in their
output quality (especially with regards to anti-aliasing), speed
and memory usage.
An application can also provide its own raster if it needs to.
- HIGH PORTABILITY AND PERFORMANCE
The FreeType source code is written in industry-standard ANSI C.
Moreover, it abstracts memory management and i/o operations within
a single module, called "ftsystem". The FreeType build system tries
to auto-detect the host platform in order to select its most
efficient implementation. It defaults otherwise to using the
standard ANSI C Library.
Note that, independently of the host platform and build, an
application is able to provide its own memory and i/o routines.
This make FreeType suitable for use in any kind of environment,
from embedded to distributed systems.
II. Components Layout :
FreeType 2 is made of distinct components which relate directly to the
design described previously:
1. THE BASE LAYER:
The base layer implements the high-level API, as well as provide
generic font services that can be used by each font driver.
2. THE FONT DRIVERS:
Each font driver can be registered in the base layer by providing
an "interface", which really is a table of function pointers.
At build time, the set of default font drivers is selected. These
drivers are then compiled and statically linked to the library.
They will then be available after the library initialisation.
3. THE RASTERS:
FreeType 2 provides the ability to hook various raster modules into
its base layer. This provides several advantages :
- different systems mean different requirements, hence the need for
flexibility.
- for now, FreeType 2 only supports glyph images stored in the
following formats :
* bitmaps
* gray-level pixmaps
* monochrome vectorial outlines (using bezier control points)
should a new "technology" come for glyph images, it is possible
to write a new raster for it, without altering the rest of the
engine. Some examples could be :
* multi-colored vectorial outlines
* on-the-fly rendering of TeX's MetaFonts !!
4. THE SYSTEM MODULE "FTSYSTEM":
The system module is used to implement basic memory and i/o management
services. By default, it uses the ANSI C library, but some replacements
are also provided (and automatically selected by the build system) when
available.
As a simple example, the unix build uses memory-mapped files to read
font files, instead of the slow ANSI "fopen/fseek/fread". This results
in tremendous performance enhancements.
Note that, even if the build system chooses an implementation for
"ftsystem" at compile time, an application is still able to provide
its own memory or i/o routines to the library at runtime.
5. THE "INIT" LAYER:
A tiny module used to implement the function FT_Init_FreeType.
As its name suggests, it is responsible for initialising the library,
which really means the following :
- bind the implementation of "ftsystem" that best matches the
host platform to the library. This choice can be overriden
later by client applications however.
- register the set of default font drivers within the base layer.
these drivers are statically linked to the library. Other drivers
can be added at runtime later through FT_Add_Driver though..
- register the set of default rasters. Client applications are
able to add their own rasters at runtime though.
The details regarding these operations is given in the document
named "FreeType Build Internals"
III. Objects Layout :
Even though it is written in ANSI C, the desing of FreeType 2 is object
oriented, as it's the best way to implement the flexible font format
support that we wanted.
Indeed, the base layer defines a set of base classes that can be derived
by each font driver in order to support a given format. The base layer
also includes many book-keeping routines that need not be included in the
drivers.
The base classes are the following:
1. FACE OBJECTS:
As in FreeType 1.x, a face object models the content of a given font
that isn't dependent on a given size, transformation or glyph index.
This includes, for example, the font name, font style(s), available
charmaps and encodings, and all other kinds of data and tables that
help describe the font as a whole.
2. SIZE OBJECTS: (previously known as INSTANCE OBJECTS in 1.x)
A face object can have one or more associated size objects. A Size
object is used to stored the font data that is dependent on the current
character size or transform used to load glyphs.
Typical data in a size object include scaled metrics, factors, and
various kind of control data related to grid-fitting. The size object
is changed each time the character size is modified.
3. GLYPH SLOT OBJECTS:
Each face object has one "glyph slot", which is a simple container
where individual glyph images can be loaded and processed.
The glyph image can be stored in the following formats in the glyph
slot :
- monochrome bitmaps
- gray-level pixmaps
- vectorial glyph outlines (defined with bezier control points)
Note that a module, called the "raster" is provided to convert vector
outlines into either monochrome or anti-aliased bitmaps. The outline
is also directly accessible and can be walked or processed freely by
client applications.
more glyph images formats can be defined, but they will require
a specific raster module if one wants to display them on a typical
display surface.
4. CHARMAP OBJECTS:
A charmap is used to convert character codes, for a given encoding,
into glyph indices. A given face might contain several charmaps, for
example, most TrueType fonts contain both the "Windows Unicode" and
"
it is not rare to see TrueType fonts with both the
"Windows Unicode" and "Apple Roman" charmap
