docs/design/design-2.html - third_party/freetype2 - Git at Google

 <!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&nbsp;2
 </h1>

 <center>
 <table width="650">
 <tr><td>

 <center><table width="100%" border=0 cellpadding=5><tr bgcolor="#CCFFCC" valign=center>
 <td align=center width="30%">
 <a href="design-1.html">Previous</a>
 </td>
 <td align=center width="30%">
 <a href="index.html">Contents</a>
 </td>
 <td align=center width="30%">
 <a href="design-3.html">Next</a>
 </td>
 </tr></table></center>

   <table width="100%">
   <tr bgcolor="#ccccee"><td>
     <h1>
       I. Components and APIs
     </h1>
   </td></tr>
   </table>

   <p>It's better to describe FreeType&nbsp;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&nbsp;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&nbsp;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&nbsp;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&nbsp;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>

 <center><table width="100%" border=0 cellpadding=5><tr bgcolor="#CCFFCC" valign=center>
 <td align=center width="30%">
 <a href="design-1.html">Previous</a>
 </td>
 <td align=center width="30%">
 <a href="index.html">Contents</a>
 </td>
 <td align=center width="30%">
 <a href="design-3.html">Next</a>
 </td>
 </tr></table></center>

 </td></tr>
 </table>
 </center>
 </body>
 </html>
	<!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="650">
	<tr><td>

	<center><table width="100%" border=0 cellpadding=5><tr bgcolor="#CCFFCC" valign=center>
	<td align=center width="30%">
	<a href="design-1.html">Previous</a>
	</td>
	<td align=center width="30%">
	<a href="index.html">Contents</a>
	</td>
	<td align=center width="30%">
	<a href="design-3.html">Next</a>
	</td>
	</tr></table></center>

	<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>

	<center><table width="100%" border=0 cellpadding=5><tr bgcolor="#CCFFCC" valign=center>
	<td align=center width="30%">
	<a href="design-1.html">Previous</a>
	</td>
	<td align=center width="30%">
	<a href="index.html">Contents</a>
	</td>
	<td align=center width="30%">
	<a href="design-3.html">Next</a>
	</td>
	</tr></table></center>

	</td></tr>
	</table>
	</center>
	</body>
	</html>