Official mirror of https://gitlab.freedesktop.org/freetype/freetype
You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
216 lines
7.3 KiB
216 lines
7.3 KiB
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 |
|
|
|
|