The design of FreeType 2
Copyright 1998-2000 David Turner (
mailto:david@freetype.org
david@freetype.org
)
Copyright 2000 The FreeType Development Team (
mailto:devel@freetype.org
devel@freetype.org
)
design-4.html
Previous
index.html
Contents
design-6.html
Next
IV. Module Classes
We will now try to explain more precisely the
types
of modules
that FreeType 2 is capable of managing.  Note that each one of them
is decribed with more details in the following chapters of this
document.
Renderer
modules are used to manage scalable glyph images.
This means
transforming
them, computing their
bounding
box
, and
converting
them to either
monochrome
or
anti-aliased
bitmaps
.
Note that FreeType 2 is capable of dealing with
any
kind of glyph images, as long as a renderer module is provided for it.
The library comes by default with two renderers:
raster
Supports the conversion of vectorial outlines (described by a
FT_Outline
object) to
monochrome
bitmaps.
smooth
Supports the conversion of the same outlines to high-quality
anti-aliased
pixmaps (using 256 levels of gray).  Note
that this renderer also supports direct span generation.
Font driver
modules are used to support one or more
specific font format.  By default, FreeType 2 comes with the
following font drivers:
truetype
supports TrueType font files
type1
supports Postscript Type 1 fonts, both in binary
(
.pfb
) or ASCII (
.pfa
) formats, including
Multiple Master fonts.
cid
supports Postscript CID-keyed fonts
cff
supports OpenType, CFF as well as CEF fonts (CEF is a
derivative of CFF used by Adobe in its SVG viewer)
winfonts
supports Windows bitmap fonts (i.e.
.fon
and
.fnt
)
Note that font drivers can support bitmapped or scalable glyph
images.  A given font driver that supports Bézier outlines
through
FT_Outline
can also provide its own hinter, or rely
on FreeType's
autohinter
module.
Helper
modules are used to hold shared code that is often
used by several font drivers, or even other modules.  Here are the
default helpers:
sfnt
used to support font formats based on the
SFNT
storage
scheme: TrueType & OpenType fonts as well as other variants (like
TrueType fonts that only contain embedded bitmaps)
psnames
used to provide various useful functions related to glyph names
ordering and Postscript encodings/charsets.  For example, this
module is capable of automatically synthetizing a Unicode charmap
from a Type 1 glyph name dictionary.
psaux
used to provide various useful functions related to Type 1
charstring decoding, as this "feature" is needed by the
type1
,
cid
, and
cff
drivers.
Finally, the
autohinter
module has a specific role in
FreeType 2, as it can be used automatically during glyph loading
to process individual glyph outlines when a font driver doesn't
provide it's own hinting engine.
This module's purpose and design is also heavily described on the
FreeType web site.
We will now study how modules are described, then managed by the
library.
1. The
FT_Module_Class
structure
As described later in this document, library initialization is
performed by calling the
FT_Init_FreeType()
function.  The
latter is in charge of creating a new "empty"
FT_Library
object, then register each "default" module by repeatedly calling the
FT_Add_Module()
function.
Similarly, client applications can call
FT_Add_Module()
any
time they wish in order to register a new module in the library.  Let us
take a look at this function's declaration:
extern FT_Error  FT_Add_Module(
FT_Library              library,
const FT_Module_Class*  clazz );
As one can see, this function expects a handle to a library object,
as well as a pointer to a
FT_Module_Class
structure.  It
returns an error code.  In case of success, a new module object is
created and added to the library.  Note by the way that the module isn't
returned directly by the call!
Here the definition of
FT_Module_Class
, with some
explanation.  The following code is taken from
<freetype/ftmodule.h>
:
typedef struct  FT_Module_Class_
{
FT_ULong               module_flags;
FT_Int                 module_size;
const FT_String*       module_name;
FT_Fixed               module_version;
FT_Fixed               module_requires;
const void*            module_interface;
FT_Module_Constructor  module_init;
FT_Module_Destructor   module_done;
FT_Module_Requester    get_interface;
} FT_Module_Class;
A description of its fields:
module_flags
A set of bit flags used to describe the module's category.  Valid
values are:
ft_module_font_driver
if the module is a font driver
ft_module_renderer
if the module is a renderer
ft_module_hinter
if the module is an auto-hinter
ft_module_driver_scalable
if the module is a font
driver supporting scalable glyph formats
ft_module_driver_no_outlines
if the module is a font
driver supporting scalable glyph formats that
cannot
be
described by an
FT_Outline
object
ft_module_driver_has_hinter
if the module is a font
driver that provides its own hinting scheme/algorithm
module_size
An integer that gives the size in
bytes
of a given
module object.  This should
never
be less than
sizeof(FT_ModuleRec)
, but can be more if the module needs
to sub-class the base
FT_ModuleRec
class.
module_name
The module's internal name, coded as a simple ASCII
C string.  There can't be two modules with the same name
registered in a given
FT_Library
object.  However,
FT_Add_Module()
uses the
module_version
field to
detect module upgrades and perform them cleanly, even at
run-time.
module_version
A 16.16 fixed float number giving the module's major and minor
version numbers.  It is used to determine whether a module needs to
be upgraded when calling
FT_Add_Module()
.
module_requires
A 16.16 fixed float number giving the version of FreeType 2
that is required to install this module.  The default value is
0x20000 for FreeType version  2.0
module_requires
Most modules support one or more "interfaces", i.e. tables of
function pointers.  This field is used to point to the module's main
interface, if there is one.  It is a short-cut that prevents users
of the module to call "get_interface()" each time they need to
access one of the object's common entry points.
Note that is is optional, and can be set to NULL.  Other
interfaces can also be accessed through the
get_interface()
field.
module_init
A pointer to a function used to initialize the fields of a fresh
new
FT_Module
object.  It is called
after
the
module's base fields have been set by the library, and is generally
used to initialize the fields of
FT_ModuleRec
subclasses.
Most module classes set it to NULL to indicate that no extra
initialization is necessary.
module_done
A pointer to a function used to finalize the fields of a given
FT_Module
object.  Note that it is called
before
the library unsets the module's base fields, and is generally used
to finalize the fields of
FT_ModuleRec
subclasses.
Most module classes set it to NULL to indicate that no extra
finalization is necessary
get_interface
A pointer to a function used to request the address of a given
module interface.  Set it to NULL if you don't need to support
additional interfaces but the main one.
2. The
FT_Module
type
The
FT_Module
type is a handle (i.e. a pointer) to a given
module object/instance, whose base structure is given by the internal
FT_ModuleRec
type.  We will intentionally
not
describe
this structure here, as there is no point to look so far into the
library's design.
When
FT_Add_Module
is called, it first allocates a new
module instance, using the
module_size
class field to determine
its byte size.  The function initializes the root
FT_ModuleRec
field, then calls the class-specific initializer
module_init
when this field is not set to NULL.
Note that the library defines several sub-classes of
FT_ModuleRec
, which are, as you could have guessed:
FT_Renderer
for renderer modules
FT_Driver
for font driver modules
FT_AutoHinter
for the auto-hinter
Helper modules use the base
FT_ModuleRec
type.  We will
describe these classes in the next chapters.
design-4.html
Previous
index.html
Contents
design-6.html
Next
