<!doctype html public "-//w3c//dtd html 4.0 transitional//en"
"http://www.w3.org/TR/REC-html40/loose.dtd">
<html>
<head>
<meta http-equiv="Content-Type"
content="text/html; charset=iso-8859-1">
<meta name="Author"
content="David Turner">
<title>The Design of FreeType 2 - Basic Design</title>
</head>
<body text="#000000"
bgcolor="#ffffff">
<h1 align=center>
The Design of FreeType 2
</h1>
<center>
<table width="75%">
<tr><td>
<table width="100%">
<tr bgcolor="#ccccee"><td>
<h1>
I. Components and APIs
</h1>
</td></tr>
</table>
<p>It's better to describe FreeType 2 as a collection of
<em>components</em>. Each one of them is a more or less abstract part of
the library that is in charge of one specific task. We will now explicit
the connections and relationships between them.</p>
<p>A first brief description of this system of components could be:</p>
<ul>
<li>
<p>Client applications typically call the FreeType 2
<b>high-level API</b>, whose functions are implemented in a single
component called the <em>Base Layer</em>.</p>
</li>
<li>
<p>Depending on the context or the task, the base layer then calls one
or more <em>module</em> components to perform the work. In most
cases, the client application doesn't need to know which module was
called.</p>
</li>
<li>
<p>The base layer also contains a set of routines that are used for
generic things like memory allocation, list processing, i/o stream
parsing, fixed point computation, etc. these functions can also be
called by a module at any time, and they form what is called the
<b>low-level base API</b>.</p>
</li>
</ul>
<p>This is illustrated by the following graphics (note that component
entry points are represented as colored triangles):</p>
<center>
<img src="basic-design.png"
width="394" height="313"
alt="Basic FreeType design">
</center>
<p>Now, a few additional things must be added to complete this
picture:</p>
<ul>
<li>
<p>Some parts of the base layer can be replaced for specific builds of
the library, and can thus be considered as components themselves.
This is the case for the <tt>ftsystem</tt> component, which is in
charge of implementing memory management & input stream access, as
well as <tt>ftinit</tt>, which is in charge of library initialization
(i.e. implementing the <tt>FT_Init_FreeType()</tt> function).</p>
</li>
<li>
<p>FreeType 2 comes also with a set of <em>optional
components</em>, which can be used either as a convenience for client
applications (e.g. the <tt>ftglyph</tt> component, used to provide a
simple API to manage glyph images independently of their internal
representation), or to access format-specific features (e.g. the
<tt>ftmm</tt> component used to access and manage Multiple Masters
data in Type 1 fonts).</p>
</li>
<li>
<p>Finally, a module is capable of calling functions provided by
another module. This is very useful to share code and tables between
several font driver modules (for example, the <tt>truetype</tt> and
<tt>cff</tt> modules both use the routines provided by the
<tt>sfnt</tt> module).</p>
</li>
</ul>
<p>Hence, a more complete picture would be:</p>
<center>
<img src="detailed-design.png"
width="390" height="429"
alt="Detailed FreeType design">
</center>
<p>Please take note of the following important points:</p>
<ul>
<li>
<p>An optional component can use either the high-level or base API.
This is the case of <tt>ftglyph</tt> in the above picture.</p>
</li>
<li>
<p>Some optional components can use module-specific interfaces ignored
by the base layer. In the above example, <tt>ftmm</tt> directly
accesses the Type 1 module to set/query data.</p>
</li>
<li>
<p>A replacable component can provide a function of the high-level
API. For example, <tt>ftinit</tt> provides
<tt>FT_Init_FreeType()</tt> to client applications.</p>
</li>
</ul>
</td></tr>
</table>
</center>
</body>
</html>
