ReceiveTempSMS
/
Al-Qurtas-Islamic-bank-The-Best-Bank-in-Iraq
forked from minhngoc25a/freetype2
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

Formatting/correcting the first three parts of the design docs.

This commit is contained in:
Werner Lemberg 2000-10-30 20:46:41 +00:00
parent cf4398a6f5
commit 60784a2200
4 changed files with 424 additions and 356 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

152
docs/design/design-1.html
View File

@ -1,82 +1,102 @@
<!doctype html public "-//w3c//dtd html 4.0 transitional//en"
"http://www.w3.org/TR/REC-html40/loose.dtd">
<html> <html>
<head><title>The Design of FreeType 2 - Introduction</title> <head>
<basefont face="Georgia, Arial, Helvetica, Geneva"> <meta http-equiv="Content-Type"
<style content="text/css"> content="text/html; charset=iso-8859-1">
P { text-align=justify } <meta name="Author"
H1 { text-align=center } content="David Turner">
H2 { text-align=center } <title>The Design of FreeType 2 - Introduction</title>
LI { text-align=justify }
</style>
</head> </head>
<body text=#000000 bgcolor=#ffffff>
<center><table width="500"><tr><td> <body text="#000000"
bgcolor="#ffffff">
<center><h1>The Design of FreeType 2</h1></center> <h1 align=center>
The Design of FreeType&nbsp;2
</h1>
<table width="100%" cellpadding=5><tr bgcolor="#ccccee"><td> <center>
<h1>Introduction</h1> <table width="75%">
</td></tr></table> <tr><td>
<p>This document provides details on the design and implementation <table width="100%">
of the FreeType 2 library. Its goal is to allow developers to <tr bgcolor="#ccccee"><td>
better understand the way FT2 is organized, in order to let them <h1>
extend, customize and debug it.</p> Introduction
</h1>
</td></tr>
</table>
<p>Before anything else, it is important to understand the <em>purpose</em> <p>This document provides details on the design and implementation of the
of this library, i.e. why it has been written:</p> FreeType&nbsp;2 library. Its goal is to allow developers to better
understand the way how FreeType&nbsp;2 is organized, in order to let them
extend, customize, and debug it.</p>
<ul> <p>Before anything else, it is important to understand the
<li><p>first of all, to allow client applications to <em>access font files <em>purpose</em> of this library, i.e., why it has been written:</p>
easily</em>, wherever they could be stored, and as independently
of font format as possible.</p></li>
<li><p>to allow easy <em>retrieval of global font data</em> most commonly <ul>
found in normal font formats (i.e. global metrics, <li>
encoding/charmaps, etc..)</p></li> <p>It allows client applications to <em>access font files easily</em>,
wherever they could be stored, and as independently of the font format
as possible.</p>
</li>
<li>
<p>Easy <em>retrieval of global font data</em> most commonly found in
normal font formats (i.e. global metrics, encoding/charmaps,
etc.).</p>
</li>
<li>
<p>It allows easy <em>retrieval of individual glyph data</em>
(metrics, images, name, anything else).</p>
</li>
<li>
<p><em>Access to font format-specific "features"</em> whenever
possible (e.g. SFNT tables, Multiple Masters, OpenType Layout tables,
etc.).</p>
</li>
</ul>
<li><p>to allow easy <em>retrieval of individual glyph data</em> <p>Its design has also severely been influenced by the following
(metrics, images, name, anything else)</p></li> requirements:</p>
<li><p>to allow <em>access to font format-specific "features"</em> <ul>
whenever possible (e.g. SFNT tables, Multiple Masters, <li>
OpenType Layout tables, etc..)</p></li> <p><em>High portability</em>. The library must be able to run on any
</ul> kind of environment. This requirement introduces a few drastic
choices that are part of FreeType&nbsp;2's low-level system
interface.</p>
</li>
<li>
<p><em>Extendability</em>. New features should be added with the
least modifications in the library's code base. This requirement
induces an extremely simple design where nearly all operations are
provided by modules.</p>
</li>
<li>
<p><em>Customization</b>. It should be easy to build a version of the
library that only contains the features needed by a specific project.
This really is important when you need to integrate it in a font
server for embedded graphics libraries.</p>
</li>
<li>
<p><em>Compactness</em> and <em>efficiency</em>. The primary target
for this library are embedded systems with low cpu and memory
resources.</p>
</li>
</ul>
<p>its design has also severely been influenced by the following <p>The rest of this document is divided in several sections. First, a few
requirements:</p> chapters will present the library's basic design as well as the
objects/data managed internally by FreeType&nbsp;2.</p>
<ul> <p>A later section is then dedicated to library customization, relating
<li><p><b>high portability</b>, as the library must be able to run such topics as system-specific interfaces, how to write your own module
on any kind of environment. this requirement introduces a few and how to tailor library initialization & compilation to your needs.</p>
drastic choices that are part of FreeType 2's low-level system
interface.</p></li>
<li><p><b>extendibility</b>, as new features should be added with </td></tr>
the least modifications in the library's code base. this </table>
requirements induces an extremely simple design where nearly </center>
all operations are provided by modules.
</p></li>
<li><p><b>customization</b>, it should be easy to build a version
of the library that only contains the features needed by a
specific project. This really is important when you need to
integrate it in a font server for embedded graphics libraries.</p></li>
<li><p><b>compactness</b> and <b>efficiency</b>, given that the
primary target for this library is embedded systems with low
cpu and memory resources.</p></li>
</ul>
<p>The rest of this document is divided in several sections. First, a
few chapters will present the library's basic design as well as the
objects/data managed internally by FreeType 2.</p>
<p>A later section is then dedicated to library customization, relating
such topics as system-specific interfaces, how to write your own
module and how to tailor library initialisation & compilation
to your needs.</p>
</td></tr></table></center>
</body> </body>
</html> </html>

201
docs/design/design-2.html
View File

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

424
docs/design/design-3.html
View File

@ -1,263 +1,293 @@
<!doctype html public "-//w3c//dtd html 4.0 transitional//en"
"http://www.w3.org/TR/REC-html40/loose.dtd">
<html> <html>
<head><title>The Design of FreeType 2 - Public Objects</title> <head>
<basefont face="Georgia, Arial, Helvetica, Geneva"> <meta http-equiv="Content-Type"
<style content="text/css"> content="text/html; charset=iso-8859-1">
P { text-align=justify } <meta name="Author"
H1 { text-align=center } content="David Turner">
H2 { text-align=center } <title>The Design of FreeType 2 - Public Objects</title>
LI { text-align=justify }
</style>
</head> </head>
<body text=#000000 bgcolor=#ffffff>
<center><table width="500"><tr><td> <body text="#000000"
bgcolor="#ffffff">
<center><h1>The Design of FreeType 2</h1></center> <h1 align=center>
The Design of FreeType&nbsp;2
</h1>
<table width="100%" cellpadding=5><tr bgcolor="#ccccee"><td> <center>
<h1>II. Public Objects and Classes</h1> <table width="75%">
</td></tr></table> <tr><td>
<p>We will now detail the abstractions provided by FreeType 2 to <table width="100%">
client applications to manage font files and data. As you would <tr bgcolor="#ccccee"><td>
normally expect, these are implemented through objects/classes.</p> <h1>
II. Public Objects and Classes
</h1>
</td></tr>
</table>
<h2>1. Object Orientation in FreeType 2:</h2> <p>We will now explain the abstractions provided by FreeType&nbsp;2 to
client applications to manage font files and data. As you would normally
expect, these are implemented through objects/classes.</p>
<p>Though written in ANSI C, the library employs a few <h2>
techniques, inherited from object-oriented programming, to make 1. Object Orientation in FreeType&nbsp;2
it easy to extend. Hence, the following conventions apply in </h2>
the FT2 source code:</p>
<ol> <p>Though written in ANSI&nbsp;C, the library employs a few techniques,
<li><p> inherited from object-oriented programming, to make it easy to extend.
each object type/class has a corresponding <em>structure type</em> <b>and</b> Hence, the following conventions apply in the FreeType&nbsp;2 source
a corresponding <em>structure pointer type</em>. the latter is called the code:</p>
<em>handle type</em> for the type/class.</p>
<p>Consider that we need to manage objects of type "foo" in FT2. <ol>
We would define the following structure and handle types as <li>
follow:</p> <p>Each object type/class has a corresponding <em>structure
type</em> <b>and</b> a corresponding <em>structure pointer
type</em>. The latter is called the <em>handle type</em> for the
type/class.</p>
<pre><font color="blue"> <p>Consider that we need to manage objects of type "foo" in
typedef struct FT_FooRec_* FT_Foo; FreeType&nbsp;2. We would define the following structure and handle
types as follows:</p>
typedef struct FT_FooRec_ <font color="blue"><pre>
{ typedef struct FT_FooRec_* FT_Foo;
// fields for the "foo" class
...
} FT_FooRec; typedef struct FT_FooRec_
</font></pre> {
// fields for the "foo" class
...
<p>As a convention, handle types use simple but meaningful identifiers } FT_FooRec;</pre>
beginning with "FT_", as in "FT_Foo", while structures use the same </font>
name with a "Rec" suffix appended to it ('Rec' is short for "record").
<em>Note that each class type has a corresponding handle type</em>.
</p>
<p>As a convention, handle types use simple but meaningful
identifiers beginning with <tt>FT_</tt>, as in <tt>FT_Foo</tt>,
while structures use the same name with a <tt>Rec</tt> suffix
appended to it ("Rec" is short for "record"). <em>Note that each
class type has a corresponding handle type</em>.</p>
</li>
<li>
<p>Class derivation is achieved internally by wrapping base class
structures into new ones. As an example, we define a "foobar" class
that is derived from "foo". We would do something like:</p>
<li><p> <font color="blue"><pre>
class derivation is achieved internally by wrapping base class typedef struct FT_FooBarRec_* FT_FooBar;
structures into new ones. As an example, let's define a "foobar"
class that is derived from "foo". We would do something like:</p>
<pre><font color="blue"> typedef struct FT_FooBarRec_
typedef struct FT_FooBarRec_* FT_FooBar; {
// the base "foo" class fields
FT_FooRec root;
typedef struct FT_FooBarRec_ // fields proper to the "foobar" class
{ ...
// the base "foo" class fields } FT_FooBarRec;</pre>
FT_FooRec root; </font>
// fields proper to the "foobar" class <p>As you can see, we ensure that a "foobar" object is also a "foo"
... object by placing a <tt>FT_FooRec</tt> at the start of the
<tt>FT_FooBarRec</tt> definition. It is called <b>root</b> by
convention.</p>
} FT_FooBarRec; <p>Note that a <tt>FT_FooBar</tt> handle also points to a "foo"
</font></pre> object and can be typecasted to <tt>FT_Foo</tt>. Similarly, when
the library returns a <tt>FT_Foo</tt> handle to client applications,
the object can be really implemented as a <tt>FT_FooBar</tt> or any
derived class from "foo".</p>
</li>
</ol>
<p>As you can see, we ensure that a "foobar" object is also a "foo" <p>In the following sections of this chapter, we will refer to "the
object by placing a <tt>FT_FooRec</tt> at the start of the <tt>FT_Foo</tt> class" to indicate the type of objects handled through
<tt>FT_FooBarRec</tt> definition. It is called <b>root</b> <tt>FT_Foo</tt> pointers, be they implemented as "foo" or "foobar".</p>
by convention.</p>
<p>Note that a <tt>FT_FooBar</tt> handle also points to a "foo" object <hr>
and can be typecasted to <tt>FT_Foo</tt>. Similarly, when the
library handles a <tt>FT_Foo</tt> handle to client applications,
the object can be really implemented as a <tt>FT_FooBar</tt> or any
derived class from "foo".</p>
</p></li> <h2>
</ul> 2. The <tt>FT_Library</tt> class
</h2>
<p>Note that in the following sections of this chapter, we will refer <p>This type corresponds to a handle to a single instance of the
to "the <tt>FT_Foo</tt> class" to indicate the type of objects library. Note that the corresponding structure <tt>FT_LibraryRec</tt>
handled through <tt>FT_Foo</tt> pointers, be they implemented as is not defined in public header files, making client applications unable
"foo" or "foobar".</p> to access its internal fields.</p>
<hr> <p>The library object is the <em>parent</em> of all other objects in
FreeType&nbsp;2. You need to create a new library instance before doing
anything else with the library. Similarly, destroying it will
automatically destroy all its children (i.e. faces and modules).</p>
<h2>2. The <em><b>FT_Library</b></em> class:</h2> <p>Typical client applications should call <tt>FT_Init_FreeType()</tt>
in order to create a new library object, ready to be used for further
actions.</p>
<p>This type corresponds to a handle to a single instance of the <p>Another alternative is to create a fresh new library instance by
library. Note that the corresponding structure <tt>FT_LibraryRec</tt> calling the function <tt>FT_New_Library()</tt>, defined in the
is not defined in public header files, making client applications <tt>&lt;freetype/ftmodule.h&gt;</tt> public header file. This function
unable to access its internal fields.</p> will however return an "empty" library instance with no module
registered in it. You can "install" modules in the instance by calling
<tt>FT_Add_Module()</tt> manually.</p>
<p>The library object is the "parent" of all other objects in FreeType 2. <p>Calling <tt>FT_Init_FreeType()</tt> is a lot more convenient, because
You need to create a new library instance before doing anything else this function basically registers a set of default modules into each new
with the library. Similarly, destroying it will automatically library instance. The way this list is accessed and/or computed is
destroy all its children (i.e. faces and modules).</p> determined at build time, and depends on the content of the
<tt>ftinit</tt> component. This process is explained in details later
in this document.</p>
<p>Typical client applications should call <tt>FT_Init_FreeType</tt>, <p>For now, one should consider that library objects are created with
in order to create a new library object, ready to be used for <tt>FT_Init_FreeType()</tt>, and destroyed along with all children with
further action.</p> <tt>FT_Done_FreeType()</tt>.</p>
<p>Another alternative is to create a fresh new library instance <hr>
by calling the function <tt>FT_New_Library</tt>, defined in the
<tt>&lt;freetype/ftmodule.h&gt;</tt> public header file. This
function will however return an "empty" library instance with
no module registered in it. You can "install" modules in the
instance by calling <tt>FT_Add_Module</tt> manually.</p>
<p>Calling <tt>FT_Init_FreeType</tt> is a lot more convenient, because <h2>
this function basically registers a set of default modules into 3. The <tt>FT_Face</tt> class
each new library instance. The way this list is accessed and/or </h2>
computed is determined at build time, and depends on the content
of the <b>ftinit</b> component. This process is explained in
details later in this document.</p>
<p>For now, one should consider that library objects are created <p>A face object corresponds to a single <em>font face</em>, i.e., a
with <tt>FT_Init_FreeType</tt>, and destroyed along with all specific typeface with a specific style. For example, "Arial" and
children with <tt>FT_Done_FreeType</tt>.</p> "Arial Italic" correspond to two distinct faces.</p>
<hr>
<h2>3. The <em><b>FT_Face</b></em> class:</h2> <p>A face object is normally created through <tt>FT_New_Face()</tt>.
This function takes the following parameters: an <tt>FT_Library</tt>
handle, a C file pathname used to indicate which font file to open, an
index used to decide which face to load from the file (a single file may
contain several faces in certain cases), and the address of a
<tt>FT_Face</tt> handle. It returns an error code:</p>
<p>A face object corresponds to a single <em>font face</em>, i.e. <font color="blue"><pre>
a specific typeface with a specific style. For example, "Arial" FT_Error FT_New_Face( FT_Library library,
and "Arial Italic" correspond to two distinct faces.</p> const char* filepathname,
FT_Long face_index,
FT_Face* face );</pre>
</font>
<p>A face object is normally created through <tt>FT_New_Face</tt>. <p>In case of success, the function will return&nbsp;0, and the handle
This function takes the following parameters: a <tt>FT_Library</tt> pointed to by the <tt>face</tt> parameter will be set to a non-NULL
handle, a C file pathname used to indicate which font file to value.</p>
open, an index used to decide which face to load from the file
(a single file may contain several faces in certain cases),
as well as the address of a <tt>FT_Face</tt> handle. It returns
an error code:</p>
<pre><font color="blue"> <p>Note that the face object contains several fields used to describe
FT_Error FT_New_Face( FT_Library library, global font data that can be accessed directly by client applications.
const char* filepathname, For example, the total number of glyphs in the face, the face's family
FT_Long face_index, name, style name, the EM size for scalable formats, etc. For more
FT_Face *face ); details, look at the <tt>FT_FaceRec</tt> definition in the
</font></pre> FreeType&nbsp;2 API Reference.</p>
<p>in case of success, the function will return 0, and the handle <hr>
pointed to by the "face" parameter will be set to a non-NULL value.</p>
<p>Note that the face object contains several fields used to <h2>
describe global font data that can be accessed directly by 4. The <tt>FT_Size</tt> class
client applications. For example, the total number of glyphs </h2>
in the face, the face's family name, style name, the EM size
for scalable formats, etc.. For more details, look at the
<tt>FT_FaceRec</tt> definition in the FT2 API Reference.</p>
<hr> <p>Each <tt>FT_Face</tt> object <em>has</em> one or more
<tt>FT_Size</tt> objects. A <em>size object</em> is used to store data
specific to a given character width and height. Each newly created face
object has one size, which is directly accessible as
<tt>face-&gt;size</tt>.</p>
<h2>4. The <em><b>FT_Size</b></em> class:</h2> <p>The contents of a size object can be changed by calling either
<tt>FT_Set_Pixel_Sizes()</tt> or <tt>FT_Set_Char_Size()</tt>.</p>
<p>Each <tt>FT_Face</tt> object <em>has</em> one or more <tt>FT_Size</tt> <p>A new size object can be created with <tt>FT_New_Size()</tt>, and
objects. A <em>size object</em> is used to store data specific to a destroyed manually with </tt>FT_Done_Size()</tt>. Note that typical
given character width and height. Each newly created face object applications don't need to do this normally: they tend to use the
has one size, which is directly accessible as <tt>face-&gt;size</tt>.</p> default size object provided with each <tt>FT_Face</tt>.</p>
<p>The content of a size object can be changed by calling either <p>The public fields of <tt>FT_Size</tt> objects are defined in a very
<tt>FT_Set_Pixel_Sizes</tt> or <tt>FT_Set_Char_Size</tt>.</p> small structure named <tt>FT_SizeRec</tt>. However, it is important to
understand that some font drivers define their own derivatives of
<tt>FT_Size</tt> to store important internal data that is re-computed
each time the character size changes. Most of the time, these are
size-specific <em>font hints</em>./p>
<p>A new size object can be created with <tt>FT_New_Size</tt>, and <p>For example, the TrueType driver stores the scaled CVT table that
destroyed manually with </tt>FT_Done_Size</tt>. Note that typical results from the execution of the "cvt" program in a <tt>TT_Size</tt>
applications don't need to do this normally: they tend to use structure, while the Type&nbsp;1 driver stores scaled global metrics
the default size object provided with each <tt>FT_Face</tt>.</p> (like blue zones) in a <tt>T1_Size</tt> object. Don't worry if you
don't understand the current paragraph; most of this stuff is highly
font format specific and doesn't need to be explained to client
developers&nbsp;:-)</p>
<p>The public fields of <tt>FT_Size</tt> objects are defined in <hr>
a very small structure named <tt>FT_SizeRec</tt>. However, it is
important to understand that some font drivers define their own
derivatives of <tt>FT_Size</tt> to store important internal data
that is re-computed each time the character size changes. Most of
the time, these are size-specific <em>font hints</em>./p>
<p>For example, the TrueType driver stores the scaled CVT table that <h2>
results from the execution of the "cvt" program in a <tt>TT_Size</tt>, 5. The <tt>FT_GlyphSlot</tt> class
while the Type 1 driver stores scaled global metrics (like blue zones) </h2>
in a <tt>T1_Size</tt> object. Don't worry if you don't understand
the current paragraph, most of this stuff is highly font format
specific and doesn't need to be explained to client developers :-)</p>
<hr> <p>The purpose of a glyph slot is to provide a place where glyph images
can be loaded one by one easily, independently of the glyph image format
(bitmap, vector outline, or anything else).</p>
<h2>5. The <em><b>FT_GlyphSlot</b></em> class:</h2> <p>Ideally, once a glyph slot is created, any glyph image can be loaded
into it without additional memory allocation. In practice, this is only
possible with certain formats like TrueType which explicitly provide
data to compute a slot's maximum size.</p>
<p>The purpose of a glyph slot is to provide a place where glyph <p>Another reason for glyph slots is that they are also used to hold
images can be loaded one by one easily, independently of the format-specific hints for a given glyphs as well as all other data
glyph image format (bitmap, vector outline, or anything else).</p> necessary to correctly load the glyph.</p>
<p>Ideally, once a glyph slot is created, any glyph image can <p>The base <tt>FT_GlyphSlotRec</tt> structure only presents glyph
be loaded into it without additional memory allocation. In practice, metrics and images to client applications, while actual implementation
this is only possible with certain formats like TrueType which may contain more sophisticated data.</p>
explicitely provide data to compute a slot's maximum size.</p>
<p>Another reason for glyph slots is that they're also used to hold <p>As an example, the TrueType-specific <tt>TT_GlyphSlotRec</tt>
format-specific hints for a given glyphs has well as all other structure contains additional fields to hold glyph-specific bytecode,
data necessary to correctly load the glyph.</p> transient outlines used during the hinting process, and a few other
things.
<p>The base <tt>FT_GlyphSlotRec</tt> structure only presents glyph The Type&nbsp;1-specific <tt>T1_GlyphSlotRec</tt> structure holds glyph
metrics and images to client applications, while actual implementation hints during glyph loading, as well as additional logic used to properly
may contain more sophisticated data.</p> hint the glyphs when a native Type&nbsp;1 hinter is used.</p>
<p>As an example, the TrueType-specific <tt>TT_GlyphSlotRec</tt> <p>Finally, each face object has a single glyph slot that is directly
structure contains additional fields to hold glyph-specific bytecode, accessible as <tt>face-&gt;glyph</tt>.</p>
transient outlines used during the hinting process, and a few other
things.
the Type1-specific <tt>T1_GlyphSlotRec</tt> structure holds <hr>
glyph hints during glyph loading, as well as additional logic used
to properly hint the glyphs when a native T1 hinter is used.</p>
<p>Finally, each face object has a single glyph slot, that is directly <h2>
accessible as <tt>face-&gt;glyph</tt>.</p> 6. The <tt>FT_CharMap</tt> class
</h2>
<hr> <p>The <tt>FT_CharMap</tt> type is used as a handle to character map
objects, or <em>charmaps</em>. A charmap is simply some sort of table
or dictionary which is used to translate character codes in a given
encoding into glyph indices for the font.</p>
<h2>6. The <em><b>FT_CharMap</b></em> class:</h2> <p>A single face may contain several charmaps. Each one of them
corresponds to a given character repertoire, like Unicode, Apple Roman,
Windows codepages, and other encodings.</p>
<p>Finally, the <tt>FT_CharMap</tt> type is used as a handle to <p>Each <tt>FT_CharMap</tt> object contains a "platform" and an
character map objects, or "charmaps" to be brief. A charmap is "encoding" field used to identify precisely the character repertoire
simply some sort of table or dictionary which is used to translate corresponding to it.</p>
character codes in a given encoding into glyph indices for the
font.</p>
<p>A single face may contain several charmaps. Each one of them <p>Each font format provides its own derivative of
corresponds to a given character repertoire, like Unicode, Apple Roman, <tt>FT_CharMapRec</tt> and thus needs to implement these objects.</p>
Windows codepages, and other ugly "standards".</p>
<p>Each <tt>FT_CharMap</tt> object contains a "platform" and an "encoding" <hr>
field used to identify precisely the character repertoire corresponding
to it.</p>
<p>Each font format provides its own derivative of <tt>FT_CharMapRec</tt> <h2>
and thus needs to implement these objects.</p> 7. Objects relationships
</h2>
<hr> <p>The following diagram summarizes what we have just said regarding the
<h2>7. Objects relationships:</h2> public objects managed by the library, as well as explicitely describes
their relationships</p>
<p>The following diagram summarizes what we just said regarding the <center>
public objects managed by the library, as well as explicitely <image alt="to be added">
describes their relationships:</p> </center>
<p>Note that this picture will be updated at the end of the next <p>Note that this picture will be updated at the end of the next
chapter, related to <em>internal objects</em>.</p> chapter, related to <em>internal objects</em>.</p>
</td></tr></table></center> </td></tr>
</table>
</center>
</body> </body>
</html> </html>

3
docs/ft2faq.html
View File

@ -119,7 +119,8 @@
<table width="100%"> <table width="100%">
<tr bgcolor="#CCCCEE"><td> <tr bgcolor="#CCCCEE"><td>
<h2 align=center> <h2 align=center>
<a name="general">General questions & answers</h2> <a name="general">General questions & answers
</h2>
</td></tr> </td></tr>
<tr><td> <tr><td>