ref: 6f36900589509f324260c359d0ffac1349a8c90d
parent: 361d9b8a7c6826272184a88007b0c5b7a26c1cb7
author: Werner Lemberg <[email protected]>
date: Fri Nov 10 00:45:07 EST 2000
Revised.
--- a/docs/glyphs/glyphs-6.html
+++ b/docs/glyphs/glyphs-6.html
@@ -1,12 +1,13 @@
-<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
+<!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="blob">
- <meta name="GENERATOR" content="Mozilla/4.5 [fr] (Win98; I) [Netscape]">
- <title>FreeType Glyph Conventions</title>
+ <meta http-equiv="Content-Type"
+ content="text/html; charset=iso-8859-1">
+ <meta name="Author"
+ content="David Turner">
+ <title>FreeType Glyph Conventions</title>
</head>
-<body>
<body text="#000000"
bgcolor="#FFFFFF"
@@ -14,364 +15,415 @@
vlink="#51188E"
alink="#FF0000">
-<center><h1>
-FreeType Glyph Conventions
-</h1></center>
+<h1 align=center>
+ FreeType Glyph Conventions
+</h1>
-<center><h2>
-version 2.1
-</h2></center>
+<h2 align=center>
+ Version 2.1
+</h2>
-<center><h3>
-Copyright 1998-2000 David Turner (<a href="mailto:[email protected]">[email protected]</a>)<br>
-Copyright 2000 The FreeType Development Team (<a href="[email protected]">[email protected]</a>)
-</h3></center>
+<h3 align=center>
+ Copyright 1998-2000 David Turner (<a
+ href="mailto:[email protected]">[email protected]</a>)<br>
+ Copyright 2000 The FreeType Development Team (<a
+ href="mailto:[email protected]">[email protected]</a>)
+</h3>
-<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="glyphs-5.html">Previous</a>
-</td>
-<td align=center width="30%">
-<a href="index.html">Contents</a>
-</td>
-<td align=center width="30%">
-<a href="glyphs-7.html">Next</a>
-</td>
-</tr></table></center>
-
-
-<table width="100%"><tr valign=center bgcolor="#CCCCFF"><td><h2>
-VI. FreeType Outlines
-</h2></td></tr></table>
+<center>
+<table width="65%">
+<tr><td>
-<p>The purpose of this section is to present the way FreeType
-manages vectorial outlines, as well as the most common operations that
-can be applied on them.
-</p>
+ <center>
+ <table width="100%"
+ border=0
+ cellpadding=5>
+ <tr bgcolor="#CCFFCC"
+ valign=center>
+ <td align=center
+ width="30%">
+ <a href="glyphs-5.html">Previous</a>
+ </td>
+ <td align=center
+ width="30%">
+ <a href="index.html">Contents</a>
+ </td>
+ <td align=center
+ width="30%">
+ <a href="glyphs-7.html">Next</a>
+ </td>
+ </tr>
+ </table>
+ </center>
-<h3><a name="section-1">
-1. FreeType outline description and structure :
-</h3><blockquote>
+ <p><hr></p>
-<h4>
-a. Outline curve decomposition :
-</h4>
+ <table width="100%">
+ <tr bgcolor="#CCCCFF"
+ valign=center><td>
+ <h2>
+ VI. FreeType outlines
+ </h2>
+ </td></tr>
+ </table>
-<p>An outline is described as a series of closed contours in the
-2D plane. Each contour is made of a series of line segments and bezier
-arcs. Depending on the file format, these can be second-order or third-order
-polynomials. The former are also called quadratic or conic arcs, and they
-come from the TrueType format. The latter are called cubic arcs and mostly
-come from the Type1 format.
-</p>
+ <p>The purpose of this section is to present the way FreeType manages
+ vectorial outlines, as well as the most common operations that can be
+ applied on them.</p>
-<p>Each arc is described through a series of start, end and control points.
-Each point of the outline has a specific tag which indicates wether it
-is used to describe a line segment or an arc. The tags can take the
-following values :
-</p>
+ <a name="section-1">
+ <h3>
+ 1. FreeType outline description and structure
+ </h3>
-<center><table CELLSPACING=5 CELLPADDING=5 WIDTH="80%">
-<tr VALIGN=TOP><td>
-<p><b>FT_Curve_Tag_On </b></p>
-</td>
+ <h4>
+ a. Outline curve decomposition
+ </h4>
-<td VALIGN=TOP>
-<p>Used when the point is "on" the curve. This corresponds to
-start and end points of segments and arcs. The other tags specify what
-is called an "off" point, i.e. one which isn't located on the contour itself,
-but serves as a control point for a bezier arc.</p>
-</td>
-</tr>
+ <p>An outline is described as a series of closed contours in the 2D
+ plane. Each contour is made of a series of line segments and
+ Bézier arcs. Depending on the file format, these can be
+ second-order or third-order polynomials. The former are also called
+ quadratic or conic arcs, and they are used in the TrueType format.
+ The latter are called cubic arcs and are mostly used in the
+ Type 1 format.</p>
-<tr>
-<td>
-<p><b>FT_Curve_Tag_Conic</b></p>
-</td>
+ <p>Each arc is described through a series of start, end, and control
+ points. Each point of the outline has a specific tag which indicates
+ whether it is used to describe a line segment or an arc. The tags can
+ take the following values:</p>
-<td>
-<p>Used for an "off" point used to control a conic bezier arc.</p>
-</td>
-</tr>
+ <center>
+ <table cellspacing=5
+ cellpadding=5
+ width="80%">
+ <tr VALIGN=TOP>
+ <td valign=top>
+ <tt>FT_Curve_Tag_On</tt>
+ </td>
+ <td valign=top>
+ <p>Used when the point is "on" the curve. This corresponds to
+ start and end points of segments and arcs. The other tags specify
+ what is called an "off" point, i.e. a point which isn't located on
+ the contour itself, but serves as a control point for a
+ Bézier arc.</p>
+ </td>
+ </tr>
-<tr>
-<td>
-<p><b>FT_Curve_Tag_Cubic</b></p>
-</td>
+ <tr>
+ <td valign=top>
+ <tt>FT_Curve_Tag_Conic</tt>
+ </td>
+ <td valign=top>
+ <p>Used for an "off" point used to control a conic Bézier
+ arc.</p>
+ </td>
+ </tr>
-<td>
-<p>Used for an "off" point used to control a cubic bezier arc.</p>
-</td>
-</tr>
-</table></center>
+ <tr>
+ <td valign=top>
+ <tt>FT_Curve_Tag_Cubic</tt>
+ </td>
+ <td valign=top>
+ <p>Used for an "off" point used to control a cubic Bézier
+ arc.</p>
+ </td>
+ </tr>
+ </table>
+ </center>
+ <p>The following rules are applied to decompose the contour's points
+ into segments and arcs:</p>
-<p>The following rules are applied to decompose the contour's points into
-segments and arcs :
-</p>
+ <ul>
+ <li>
+ Two successive "on" points indicate a line segment joining them.
+ </li>
+ <li>
+ One conic "off" point amidst two "on" points indicates a conic
+ Bézier arc, the "off" point being the control point, and
+ the "on" ones the start and end points.
+ </li>
+ <li>
+ Two successive cubic "off" points amidst two "on" points indicate
+ a cubic Bézier arc. There must be exactly two cubic
+ control points and two "on" points for each cubic arc (using a
+ single cubic "off" point between two "on" points is forbidden, for
+ example).
+ </li>
+ <li>
+ Finally, two successive conic "off" points forces the rasterizer
+ to create (during the scan-line conversion process exclusively) a
+ virtual "on" point amidst them, at their exact middle. This
+ greatly facilitates the definition of successive conic
+ Bézier arcs. Moreover, it is the way outlines are
+ described in the TrueType specification.
+ </li>
+ </ul>
-<ul>
-<li>two successive "on" points indicate a line segment joining them.</li>
+ <p>Note that it is possible to mix conic and cubic arcs in a single
+ contour, even though no current font driver produces such
+ outlines.</p>
-<li>one conic "off" point amidst two "on" points indicates a conic bezier
-arc, the "off" point being the control point, and the "on" ones the
-start and end points.</li>
+ <center>
+ <table>
+ <tr>
+ <td>
+ <img src="points_segment.png"
+ height=166 width=221
+ alt="segment example">
+ </td>
+ <td>
+ <img src="points_conic.png"
+ height=183 width=236
+ alt="conic arc example">
+ </td>
+ </tr>
+ <tr>
+ <td>
+ <img src="points_cubic.png"
+ height=162 width=214
+ alt="cubic arc example">
+ </td>
+ <td>
+ <img src="points_conic2.png"
+ height=204 width=225
+ alt="cubic arc with virtual 'on' point">
+ </td>
+ </tr>
+ </table>
+ </center>
-<li>
-Two successive cubic "off" points amidst two "on" points indicate a cubic
-bezier arc. There must be exactly two cubic control points and two on
-points for each cubic arc (using a single cubic "off" point between two
-"on" points is forbidden, for example).
-</li>
-<li>
-finally, two successive conic "off" points forces the rasterizer to create
-(during the scan-line conversion process exclusively) a virtual "on" point
-amidst them, at their exact middle. This greatly facilitates the definition
-of successive conic bezier arcs. Moreover, it's the way outlines are
-described in the TrueType specification.
-</li>
-</ul>
+ <h4>
+ b. Outline descriptor
+ </h4>
-<p><br>Note that it is possible to mix conic and cubic arcs in a single
-contour, even though no current font driver produces such outlines.
-<br> </ul>
+ <p>A FreeType outline is described through a simple structure, called
+ <tt>FT_Outline</tt>, which fields are:</p>
-<center><table>
-<tr>
-<td>
-<blockquote><img SRC="points_segment.png" height=166 width=221></blockquote>
-</td>
+ <center>
+ <table cellspacing=3
+ cellpadding=3>
+ <tr>
+ <td>
+ <tt>n_points</tt>
+ </td>
+ <td>
+ the number of points in the outline
+ </td>
+ </tr>
+ <tr>
+ <td>
+ <tt>n_contours</tt>
+ </td>
+ <td>
+ the number of contours in the outline
+ </td>
+ </tr>
+ <tr>
+ <td>
+ <tt>points</tt>
+ </td>
+ <td>
+ array of point coordinates
+ </td>
+ </tr>
+ <tr>
+ <td>
+ <tt>contours</tt>
+ </td>
+ <td>
+ array of contour end indices
+ </td>
+ </tr>
+ <tr>
+ <td>
+ <tt>tags</tt>
+ </td>
+ <td>
+ array of point flags
+ </td>
+ </tr>
+ </table>
+ </center>
-<td>
-<blockquote><img SRC="points_conic.png" height=183 width=236></blockquote>
-</td>
-</tr>
+ <p>Here, <tt>points</tt> is a pointer to an array of
+ <tt>FT_Vector</tt> records, used to store the vectorial coordinates of
+ each outline point. These are expressed in 1/64th of a pixel, which
+ is also known as the <em>26.6 fixed float format</em>.</p>
-<tr>
-<td>
-<blockquote><img SRC="points_cubic.png" height=162 width=214></blockquote>
-</td>
+ <p><tt>contours</tt> is an array of point indices used to delimit
+ contours in the outline. For example, the first contour always starts
+ at point 0, and ends at point <tt>contours[0]</tt>. The second
+ contour starts at point <tt>contours[0]+1</tt> and ends at
+ <tt>contours[1]</tt>, etc.</p>
-<td>
-<blockquote><img SRC="points_conic2.png" height=204 width=225></blockquote>
-</td>
-</tr>
-</table></center>
+ <p>Note that each contour is closed, and that <tt>n_points</tt> should
+ be equal to <tt>contours[n_contours-1]+1</tt> for a valid outline.</p>
-<h4>
-b. Outline descriptor :</h4>
+ <p>Finally, <tt>tags</tt> is an array of bytes, used to store each
+ outline point's tag.</p>
-<p>A FreeType outline is described through a simple structure,
-called <tt>FT_Outline</tt>, which fields are :</p>
-<center><table CELLSPACING=3 CELLPADDING=3 BGCOLOR="#CCCCCC">
-<tr>
-<td>
-<p><b><tt>n_points</tt></b></p>
-</td>
+ <a name="section-2">
+ <hr3>
+ 2. Bounding and control box computations
+ </h3>
-<td>
-<p>the number of points in the outline</p>
-</td>
-</tr>
+ <p>A <em>bounding box</em> (also called <em>bbox</em>) is simply a
+ rectangle that completely encloses the shape of a given outline. The
+ interesting case is the smallest bounding box possible, and in the
+ following we subsume this under the term "bounding box". Because of the
+ way arcs are defined, Bézier control points are not necessarily
+ contained within an outline's (smallest) bounding box.</p>
-<tr>
-<td>
-<p><b><tt>n_contours</tt></b></p>
-</td>
+ <p>This situation happens when one Bézier arc is, for example,
+ the upper edge of an outline and an "off" point happens to be above the
+ bbox. However, it is very rare in the case of character outlines
+ because most font designers and creation tools always place "on" points
+ at the extrema of each curved edges, as it makes hinting much
+ easier.</p>
-<td>
-<p>the number of contours in the outline</p>
-</td>
-</tr>
+ <p>We thus define the <em>control box</em> (also called <em>cbox</em>)
+ as the smallest possible rectangle that encloses all points of a given
+ outline (including its "off" points). Clearly, it always includes the
+ bbox, and equates it in most cases.</p>
-<tr>
-<td>
-<p><b><tt>points</tt></b></p>
-</td>
+ <p>Unlike the bbox, the cbox is much faster to compute.</p>
-<td>
-<p>array of point coordinates</p>
-</td>
-</tr>
+ <center>
+ <table>
+ <tr>
+ <td>
+ <img src="bbox1.png"
+ height=264 width=228
+ alt="a glyph with different bbox and cbox">
+ </td>
+ <td>
+ <img src="bbox2.png"
+ height=229 width=217
+ alt="a glyph with identical bbox and cbox">
+ </td>
+ </tr>
+ </table>
+ </center>
-<tr>
-<td>
-<p><b><tt>contours</tt></b></p>
-</td>
+ <p>Control and bounding boxes can be computed automatically through the
+ functions <tt>FT_Get_Outline_CBox()</tt> and
+ <tt>FT_Get_Outline_BBox()</tt>. The former function is always very
+ fast, while the latter <em>may</em> be slow in the case of "outside"
+ control points (as it needs to find the extreme of conic and cubic arcs
+ for "perfect" computations). If this isn't the case, it is as fast as
+ computing the control box.
-<td>
-<p>array of contour end indices</p>
-</td>
-</tr>
+ <p>Note also that even though most glyph outlines have equal cbox and
+ bbox to ease hinting, this is not necessary the case anymore when a
+ transformation like rotation is applied to them.</p>
-<tr>
-<td>
-<p><b><tt>tags</tt></b></p>
-</td>
-<td>
-<p>array of point flags</p>
-</td>
-</tr>
-</table></center>
+ <a name="section-3">
+ <h3>
+ 3. Coordinates, scaling and grid-fitting
+ </h3>
-<p>Here, <b><tt>points</tt></b> is a pointer to an array of
-<tt>FT_Vector</tt> records, used to store the vectorial coordinates of each
-outline point. These are expressed in 1/64th of a pixel, which is also
-known as the <i>26.6 fixed float format</i>.
-</p>
+ <p>An outline point's vectorial coordinates are expressed in the
+ 26.6 format, i.e. in 1/64th of a pixel, hence coordinates
+ (1.0,-2.5) is stored as the integer pair (x:64,y:-192).</p>
-<p><b><tt>contours</tt></b> is an array of point indices used to delimit
-contours in the outline. For example, the first contour always starts at
-point 0, and ends a point <b><tt>contours[0]</tt></b>. The second contour
-starts at point "<b><tt>contours[0]+1</tt></b>" and ends at
-<b><tt>contours[1]</tt></b>, etc..
-</p>
+ <p>After a master glyph outline is scaled from the EM grid to the
+ current character dimensions, the hinter or grid-fitter is in charge of
+ aligning important outline points (mainly edge delimiters) to the pixel
+ grid. Even though this process is much too complex to be described in a
+ few lines, its purpose is mainly to round point positions, while trying
+ to preserve important properties like widths, stems, etc.</p>
-<p>Note that each contour is closed, and that <b><tt>n_points</tt></b>
-should be equal to "<b><tt>contours[n_contours-1]+1</tt></b>" for a valid
-outline.
-</p>
+ <p>The following operations can be used to round vectorial distances in
+ the 26.6 format to the grid:</p>
-<p>Finally, <b><tt>tags</tt></b> is an array of bytes, used to store each
-outline point's tag.
-</p>
+ <pre>
+ round( x ) == ( x + 32 ) & -64
+ floor( x ) == x & -64
+ ceiling( x ) == ( x + 63 ) & -64</pre>
+ <p>Once a glyph outline is grid-fitted or transformed, it often is
+ interesting to compute the glyph image's pixel dimensions before
+ rendering it. To do so, one has to consider the following:</p>
-</blockquote><h3><a name="section-2">
-2. Bounding and control box computations :
-</h3><blockquote>
+ <p>The scan-line converter draws all the pixels whose <em>centers</em>
+ fall inside the glyph shape. It can also detect <em>drop-outs</em>,
+ i.e. discontinuities coming from extremely thin shape fragments, in
+ order to draw the "missing" pixels. These new pixels are always located
+ at a distance less than half of a pixel but it is not easy to predict
+ where they will appear before rendering.</p>
-<p>A <b>bounding box</b> (also called "<b>bbox</b>") is simply
-the smallest possible rectangle that encloses the shape of a given outline.
-Because of the way arcs are defined, bezier control points are not
-necessarily contained within an outline's bounding box.
-</p>
+ <p>This leads to the following computations:</p>
-<p>This situation happens when one bezier arc is, for example, the upper
-edge of an outline and an off point happens to be above the bbox. However,
-it is very rare in the case of character outlines because most font designers
-and creation tools always place on points at the extrema of each curved
-edges, as it makes hinting much easier.
-</p>
+ <ul>
+ <li>
+ <p>compute the bbox</p>
+ </li>
+ <li>
+ <p>grid-fit the bounding box with the following:</p>
-<p>We thus define the <b>control box</b> (a.k.a. the "<b>cbox</b>") as
-the smallest possible rectangle that encloses all points of a given outline
-(including its off points). Clearly, it always includes the bbox, and equates
-it in most cases.
-</p>
+ <pre>
+ xmin = floor( bbox.xMin )
+ xmax = ceiling( bbox.xMax )
+ ymin = floor( bbox.yMin )
+ ymax = ceiling( bbox.yMax )</pre>
+ </li>
+ <li>
+ return pixel dimensions, i.e.
-<p>Unlike the bbox, the cbox is also much faster to compute.</p>
+ <pre>
+ width = (xmax - xmin)/64</pre>
-<center><table>
-<tr>
-<td><img SRC="bbox1.png" height=264 width=228></td>
+ and
-<td><img SRC="bbox2.png" height=229 width=217></td>
-</tr>
-</table></center>
+ <pre>
+ height = (ymax - ymin)/64</pre>
+ </li>
+ </ul>
-<p>Control and bounding boxes can be computed automatically through the
-functions <b><tt>FT_Get_Outline_CBox</tt></b> and <b><tt>FT_Get_Outline_BBox</tt></b>.
-The former function is always very fast, while the latter <i>may</i> be
-slow in the case of "outside" control points (as it needs to find the extreme
-of conic and cubic arcs for "perfect" computations). If this isn't the
-case, it's as fast as computing the control box.
-<p>Note also that even though most glyph outlines have equal cbox and bbox
-to ease hinting, this is not necessary the case anymore when a
-transform like rotation is applied to them.
-</p>
+ <p>By grid-fitting the bounding box, it is guaranteed that all the pixel
+ centers that are to be drawn, <em>including those coming from drop-out
+ control</em>, will be <em>within</em> the adjusted box. Then the box's
+ dimensions in pixels can be computed.</p>
-</blockquote><h3><a name="section-3">
- 3. Coordinates, scaling and grid-fitting :
-</h3><blockquote>
+ <p>Note also that, when translating a grid-fitted outline, one should
+ <em>always use integer distances</em> to move an outline in the 2D
+ plane. Otherwise, glyph edges won't be aligned on the pixel grid
+ anymore, and the hinter's work will be lost, producing <em>very low
+ quality </em>bitmaps and pixmaps.</p>
-<p>An outline point's vectorial coordinates are expressed in the
-26.6 format, i.e. in 1/64th of a pixel, hence coordinates (1.0, -2.5) is
-stored as the integer pair ( x:64, y: -192 ).
-</p>
-<p>After a master glyph outline is scaled from the EM grid to the current
-character dimensions, the hinter or grid-fitter is in charge of aligning
-important outline points (mainly edge delimiters) to the pixel grid. Even
-though this process is much too complex to be described in a few lines,
-its purpose is mainly to round point positions, while trying to preserve
-important properties like widths, stems, etc..
-</p>
+ <p><hr></p>
-<p>The following operations can be used to round vectorial distances in
-the 26.6 format to the grid :
-</p>
+ <center>
+ <table width="100%"
+ border=0
+ cellpadding=5>
+ <tr bgcolor="#CCFFCC"
+ valign=center>
+ <td align=center
+ width="30%">
+ <a href="glyphs-5.html">Previous</a>
+ </td>
+ <td align=center
+ width="30%">
+ <a href="index.html">Contents</a>
+ </td>
+ <td align=center
+ width="30%">
+ <a href="glyphs-7.html">Next</a>
+ </td>
+ </tr>
+ </table>
+ </center>
-<center>
-<p><tt>round(x) == (x+32) & -64</tt>
-<br><tt>floor(x) == x &
--64</tt>
-<br><tt>ceiling(x) == (x+63) & -64</tt></center>
-
-<p>Once a glyph outline is grid-fitted or transformed, it often is interesting
-to compute the glyph image's pixel dimensions before rendering it. To do
-so, one has to consider the following :
-<p>The scan-line converter draws all the pixels whose <i>centers</i> fall
-inside the glyph shape. It can also detect "<b><i>drop-outs</i></b>", i.e.
-discontinuities coming from extremely thin shape fragments, in order to
-draw the "missing" pixels. These new pixels are always located at a distance
-less than half of a pixel but one cannot predict easily where they'll appear
-before rendering.
-<p>This leads to the following computations :
-<br>
-<ul>
-<li>
-compute the bbox</li>
-</ul>
-
-<ul>
-<li>
-grid-fit the bounding box with the following :</li>
-</ul>
-
-<ul><p>
-<ul><tt>xmin = floor( bbox.xMin )</tt>
-<br><tt>xmax = ceiling( bbox.xMax )</tt>
-<br><tt>ymin = floor( bbox.yMin )</tt>
-<br><tt>ymax = ceiling( bbox.yMax )</tt>
-</p></ul>
-
-<li>
-return pixel dimensions, i.e.
-<tt>width = (xmax - xmin)/64</tt> and <tt>height = (ymax - ymin)/64</tt>
-</li>
-</ul>
-
-<p><br>By grid-fitting the bounding box, one guarantees that all the pixel
-centers that are to be drawn, <b><i>including those coming from drop-out
-control</i></b>, will be <b><i>within</i></b> the adjusted box. Then the
-box's dimensions in pixels can be computed.
-<p>Note also that, when <i>translating</i> a <i>grid-fitted outline</i>,
-one should <b><i>always</i></b> use <b><i>integer distances</i></b> to
-move an outline in the 2D plane. Otherwise, glyph edges won't be aligned
-on the pixel grid anymore, and the hinter's work will be lost, producing
-<b><i>very
-low quality </i></b>bitmaps and pixmaps..</blockquote>
-</blockquote>
-
-<center><table width="100%" border=0 cellpadding=5><tr bgcolor="#CCFFCC" valign=center>
-<td align=center width="30%">
-<a href="glyphs-5.html">Previous</a>
-</td>
-<td align=center width="30%">
-<a href="index.html">Contents</a>
-</td>
-<td align=center width="30%">
-<a href="glyphs-7.html">Next</a>
-</td>
-</tr></table></center>
-
-</td></tr></table></center>
+</td></tr>
+</table>
+</center>
</body>
</html>