index.html

Branch :
Show log
Commit
Author : David Turner
Date : 2000-06-30 01:31:22
Hash : 5ae831c1
Message : changes used to implement the auto-hinting support
docs/design/index.html
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<head>
   <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
   <meta name="Author" content="David Turner">
   <meta name="GENERATOR" content="Mozilla/4.5 [fr] (Win98; I) [Netscape]">
   <title>FreeType 2 Internals</title>
</head>
<body>

<body text="#000000"
      bgcolor="#FFFFFF"
      link="#0000EF"
      vlink="#51188E"
      alink="#FF0000">

<center>
<h1>
FreeType 2.0 Internals</h1></center>

<center>
<h2>
Version 1.2</h2></center>

<center>
<h3>
&copy; 1999-2000 David Turner (<a href="fichier :///david@freetype.org">david@freetype.org</a>)<br>
&copy; 1999-2000 The FreeType Development Team (<a href="fichier :///devel@freetype.org">devel@freetype.org</a>)</h3></center>

<p><br>
<hr WIDTH="100%">
<br>&nbsp;
<h2>Introduction:</h2>

<p>This document describes in great deatils the internals of FreeType 2.
   It is a must read for porters and developers alike. Its purpose is to
   
   present the
<blockquote>This document describes in great details the internals of the
FreeType 2.0 library. It is a must read for porters and developers alike.
Its purpose is to present the engine's objects, their roles and interactions.
It is assumed that the <b><i>FreeType Glyph Conventions</i></b> document
has been read.
<p>We advise porters to also read the <b><i>FreeType Porting Guide</i></b>
after this document. Would-be hackers and maintainers are of course encouraged
to read the <b><i>FreeType Coding Conventions</i></b> document too. The
development of a new driver is described in more details in the <b><i>FreeType
Driver HowTo</i></b> document.</blockquote>

<p><br>
<hr WIDTH="100%">
<h2>
I. Overview :</h2>

<blockquote>
<h3>
1. Features (and what's new) :</h3>

<blockquote>FreeType 2.0 has a number of important new features that were
not found in the 1.x releases :
<br>&nbsp;
<blockquote><b>font-format independent API</b>
<br>FreeType 2.0 is able to support any kind of font format, be it fixed
or scalable, through the use of pluggable "font drivers". These drivers
can be added or replaced at run time, while applications use a new font
format-independent API.
<p><b>advanced stream caching</b>
<br>2.0 is able to control the number of concurrently opened streams when
using fonts. It is thus possible to open dozens or hundreds of font faces
without running out of system resources.
<p><b>real reentrancy support</b>
<br>It is now possible to use FreeType as a shared library with no static
data in a multi-threaded environment. The synchronization model has also
been simplified in order to make font driver writing easier. Of course,
you can build FreeType with no thread support to get a smaller library.
<p><b>support for cubic beziers and 17-levels anti-aliasing</b>
<br>The FreeType scan-line converter (a.k.a. raster) now supports cubic
bezier arcs seamlessly. It also provides a new anti-aliasing mode which
uses a palette of 17 levels of grays.
<br>&nbsp;</blockquote>
It also features the following :
<blockquote><b>performance improvements :</b>
<br>The FreeType raster has been optimized, and the generation of anti-aliased
pixmaps is now 60% faster than in the 1.x release. Moreover, the TrueType
bytecode interpreter has been profiled and greatly optimised.
<p><b>easier portability</b>
<br>Porting and configuring FreeType is now much easier. A single file
must be provided for system-specific operations (like memory, i/o, thread
management), and a single configuration header is used to select the build
you need.
<br>&nbsp;</blockquote>
</blockquote>

<h3>
2. Architecture :</h3>

<blockquote>The engine is now split in several parts, which are :
<h4>
a. The base layer :</h4>

<blockquote>This part contains all the font-format independent features
of the engine which are :
<ul>
<li>
computations/scaling</li>

<li>
list processing</li>

<li>
outline processing</li>

<li>
scan-line converter</li>

<li>
stream manager</li>

<li>
base object classes</li>

<li>
debugging &amp; traces</li>

<li>
high-level API functions</li>

<li>
low-level system object (memory, i/o, threads)</li>
</ul>
</blockquote>

<h4>
b. The font drivers :</h4>

<blockquote>Each font format is managed with the use of a single font driver
object. The base layer is able to manage several drivers, and these can
be easily added, removed or upgraded at runtime. Each driver has the following
features and functions :
<ul>
<li>
auto-check font format when opening a font resource (i.e. file)</li>

<li>
access, load and/or extract all tables and data from the font file</li>

<li>
grid-fit/hint the glyph outlines (in the case of scalable formats like
TrueType or Type1)</li>

<li>
provide extensions to access font format-specific data and tables from
the font file</li>
</ul>
Note that FreeType 2.0 is a font service. Its purpose is to provide a unified
API for all kinds of fonts and extract individual glyph images and metrics.
However, it does not render text itself, as this operation is left to the
developer, or to higher-level libraries built on top of FreeType. Here
are a few features that are thus not implemented :
<blockquote>1) Text string rendering
<br>2) Glyph bitmap/outline caching for improved performance
<br>3) Synthetic fonts (i.e. italicising, emboldening, underlining)
<br>4) Contextual glyph substitution and other advanced layout processes</blockquote>
Note that features 1 through 3 should be provided by the SemTex library,
which may soon become part of the standard FreeType distribution.</blockquote>
</blockquote>
</blockquote>

<p><br>
<hr WIDTH="100%">
<h2>
II. Design :</h2>

<blockquote>
<h3>
1. Objects :</h3>

<blockquote>They are several kinds of objects in FreeType, which can be
described as follows :
<blockquote><b>Base objects</b>
<br>These objects do not relate directly to font data, but to the way it
is organised and managed. It is the basic core and provides functions that
are heavily used by each font driver. Examples are the resource objects,
used to describe font files, the system object used to manage low-level
system operations, or the raster object, used to convert vector outlines
into bitmaps or anti-aliased pixmaps. Most of the base objects are not
directly visible for client applications of FreeType.
<p><b>Font objects</b>
<br>The font objects directly model the data as it is found in font files.
The root classes implemented in the base layer like <tt>FT_Face</tt>, <tt>FT_Size</tt>,
<tt>FT_GlyphSlot</tt>,
must be derived in each font driver.</blockquote>
Objects are defined in the files "<tt>base/freetype.h</tt>" and "<tt>base/ftobjs.h</tt>".
The former contains all the public object definitions usable by client
applications. The latter contains private definitions used by the rest
of the base layer and each font driver.</blockquote>

<h3>
2. List management</h3>

<blockquote>The "<tt>base/ftlist.c</tt>" component a very simple doubly-linked
list facility which is used by the rest of the engine to create and process
lists, including iteration and finalisation. The definition of the list
node and functions are placed in the "<tt>base/freetype.h</tt>" to let
client applications access listed objects as they like.
<p>The base list type is <tt>FT_List</tt>, which links nodes of type <tt>FT_ListNode</tt>
together.
<br>&nbsp;</blockquote>

<h3>
3. Limited encapsulation</h3>

<blockquote>Unlike what happened in the 1.x releases, the <tt>FT_Face</tt>,
<tt>FT_Size</tt>,
<tt>FT_GlyphSlot</tt> and <tt>FT_CharMap</tt> types are no longer blind
pointers to opaque types. Rather, the corresponding structures are now
public (and defined in "<tt>base/freetype.h</tt>", see <tt>FT_FaceRec</tt>,
<tt>FT_SizeRec</tt>,
etc..) in order to let client applications read directly the various object
attributes they're interested in.
<p>This breaks encapsulation of implementation, famed by OOP, but was chosen
because:
<br>&nbsp;
<ul>
<li>
it simplifies a lot the work of client applications and libraries which
don't need to perform a function call everytime they want to read one important
object attribute (nor does it force them to cache these attributes in their
own structures).</li>
</ul>

<ul>
<li>
It reduces greatly the API, as many <tt>FT_Get_XXX</tt> functions are avoided.</li>
</ul>

<ul>
<li>
Higher-level libraries are able to&nbsp; access data directly. When it
is used frequently, they don't need to cache it in their own structures.</li>
</ul>

<ul>
<li>
It is possible to tightly link FreeType objects with higher-level ones,
in a clearer and more efficient way. This is very important when one wants
to write a C++ wrapper or a text rendering library on top of FreeType (actually,
both projects were performed in an earlier version of FreeType 2.0 which
featured classic encapsulation through get/set methods. The resulting code
was ugly and slow. Moving to a limited encapsulation approach simplified
so many things that the compiled code size was reduced by a factor of two
!).</li>
</ul>

<ul>
<li>
Finally, the API and font object structures were designed after the creation
of two scalable font drivers and one bitmap font driver. They are now very
stable and the public (visible) attributes are not going to change.</li>
</ul>
</blockquote>
</blockquote>

<p><br>
<hr WIDTH="100%">
<h2>
III. Base objects :</h2>

<blockquote>This section describes the FreeType base object classes :
<br>&nbsp;
<h3>
1. System objects :</h3>

<blockquote>The system class is in charge of managing all low-level and
system-specific operations. This means simply memory management, i/o access
and thread synchronisation. It is implemented by the "<tt>ftsys.c</tt>"
component, whose source must be located in the configuration directory
when building FreeType. (e.g. "<tt>lib/arch/ansi/ftsys.c</tt>" for an ANSI
build, "<tt>lib/arch/unix/ftsys.c</tt>" for a Unix one, etc..).
<p>Porting FreeType 2.0 really means providing a new implementation of
<tt>ftsys</tt>
(along with a few configuration file changes). Note however that its interface
is common to all ports, and located in "<tt>base/ftsys.h</tt>".</blockquote>

<h3>
2. Resources and Streams:</h3>

<blockquote>The concepts of files as storages, and files as streams has
been separated for FreeType 2.0. The "<b><i>resource</i></b>" concept was
introduced while the "<b><i>stream</i></b>" one has been redefined. Here
is how they work together :
<ul>
<li>
a "<b>resource</b>" is an object which models a file, seen as a storage.
There are several classes of resources, which differ usually in two ways
: the way their data is accessed by applications, and the way they're named
within the system.</li>
</ul>

<ul>For example, when parsing files with the ANSI C library, data has to
be read (through fseek/fread) into intermediate buffers before it can be
decoded. This scheme is highly portable, but rather inefficient; when using
it, we'll describe the file as a disk-based resource.
<p>As most modern operating systems now provide memory-mapped files, which
allow direct access while improving performance and reducing memory usage.
Because data can be read directly in memory, we'll speak of a memory-based
resource in this case. For embedded systems (like printers, PDAs, etc..),
ROM-fonts fit into this category as well.
<p>Regarding naming, most systems use a string to name files in their storage
hierarchy. Though a typical pathname is an ASCII string (<tt>'c:\windows\fonts\times.ttf'</tt>
on Windows, <tt>'/home/fonts/times.ttf'</tt> on Unix), some OSes use different
schemes, varying from Unicode character strings to file i-node numbers.
These details are platform-specific and must be hidden to the rest of the
library in resource objects.
<p>A resource encapsulates the lowest details regarding a file, though
it should have NO STATE. Note that the nature or type of a resource (i.e.
disk or memory based) is important to the "stream" component only. The
rest of the library and font drivers work transparently from their implementation.
<p>Note also that it is perfectly possible to mix resources of distinct
natures in a single build</ul>

<ul>
<li>
a "<b>stream</b>" is an object which is used to extract bytes from a resource.
Only resource objects can create streams, through its <i><tt>Open_Stream()</tt></i>
method. A stream has state, which typically consist of a file "cursor",
some intermediate buffers, a "current frame" and, of course, methods used
to extract the data from streams, resolving endianess and alignement issues.</li>
</ul>
Data can be extracted from streams through direct reads, or through the
use of <b>frames</b>. A frame models <i>a run of contiguous bytes</i> starting
from the current stream position, and of liberal size.
<p>Methods exist to extract successive integers of any sizes, while resolving
endianess and alignement issues. Rather than a long rethorical explanation,
here's how frames are typically used :
<blockquote><tt>{</tt>
<br><tt>&nbsp;
kc3-lang/freetype/docs/design/index.html

Commit

kc3-lang/freetype /docs/design/index.html
