217 lines
7.3 KiB
Plaintext
217 lines
7.3 KiB
Plaintext
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
|
|
|