| <!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="blob"> |
| <meta name="GENERATOR" content="Mozilla/4.5 [fr] (Win98; I) [Netscape]"> |
| <title>FreeType Glyph Conventions</title> |
| </head> |
| <body> |
| |
| <body text="#000000" |
| bgcolor="#FFFFFF" |
| link="#0000EF" |
| vlink="#51188E" |
| alink="#FF0000"> |
| |
| <center><h1> |
| FreeType Glyph Conventions |
| </h1></center> |
| |
| <center><h2> |
| version 2.1 |
| </h2></center> |
| |
| <center><h3> |
| Copyright 1998-2000 David Turner (<a href="mailto:david@freetype.org">david@freetype.org</a>)<br> |
| Copyright 2000 The FreeType Development Team (<a href="devel@freetype.org">devel@freetype.org</a>) |
| </h3></center> |
| |
| <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> |
| |
| <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> |
| |
| <h3><a name="section-1"> |
| 1. FreeType outline description and structure : |
| </h3><blockquote> |
| |
| <h4> |
| a. Outline curve decomposition : |
| </h4> |
| |
| <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>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> |
| |
| <center><table CELLSPACING=5 CELLPADDING=5 WIDTH="80%"> |
| <tr VALIGN=TOP><td> |
| <p><b>FT_Curve_Tag_On </b></p> |
| </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. one which isn't located on the contour itself, |
| but serves as a control point for a bezier arc.</p> |
| </td> |
| </tr> |
| |
| <tr> |
| <td> |
| <p><b>FT_Curve_Tag_Conic</b></p> |
| </td> |
| |
| <td> |
| <p>Used for an "off" point used to control a conic bezier arc.</p> |
| </td> |
| </tr> |
| |
| <tr> |
| <td> |
| <p><b>FT_Curve_Tag_Cubic</b></p> |
| </td> |
| |
| <td> |
| <p>Used for an "off" point used to control a cubic bezier arc.</p> |
| </td> |
| </tr> |
| </table></center> |
| |
| |
| <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 bezier |
| 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 |
| 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> |
| |
| <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> |
| |
| <center><table> |
| <tr> |
| <td> |
| <blockquote><img SRC="points_segment.png" height=166 width=221></blockquote> |
| </td> |
| |
| <td> |
| <blockquote><img SRC="points_conic.png" height=183 width=236></blockquote> |
| </td> |
| </tr> |
| |
| <tr> |
| <td> |
| <blockquote><img SRC="points_cubic.png" height=162 width=214></blockquote> |
| </td> |
| |
| <td> |
| <blockquote><img SRC="points_conic2.png" height=204 width=225></blockquote> |
| </td> |
| </tr> |
| </table></center> |
| |
| <h4> |
| b. Outline descriptor :</h4> |
| |
| <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> |
| |
| <td> |
| <p>the number of points in the outline</p> |
| </td> |
| </tr> |
| |
| <tr> |
| <td> |
| <p><b><tt>n_contours</tt></b></p> |
| </td> |
| |
| <td> |
| <p>the number of contours in the outline</p> |
| </td> |
| </tr> |
| |
| <tr> |
| <td> |
| <p><b><tt>points</tt></b></p> |
| </td> |
| |
| <td> |
| <p>array of point coordinates</p> |
| </td> |
| </tr> |
| |
| <tr> |
| <td> |
| <p><b><tt>contours</tt></b></p> |
| </td> |
| |
| <td> |
| <p>array of contour end indices</p> |
| </td> |
| </tr> |
| |
| <tr> |
| <td> |
| <p><b><tt>tags</tt></b></p> |
| </td> |
| |
| <td> |
| <p>array of point flags</p> |
| </td> |
| </tr> |
| </table></center> |
| |
| <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><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>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>Finally, <b><tt>tags</tt></b> is an array of bytes, used to store each |
| outline point's tag. |
| </p> |
| |
| |
| </blockquote><h3><a name="section-2"> |
| 2. Bounding and control box computations : |
| </h3><blockquote> |
| |
| <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 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> |
| |
| <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> |
| |
| <p>Unlike the bbox, the cbox is also much faster to compute.</p> |
| |
| <center><table> |
| <tr> |
| <td><img SRC="bbox1.png" height=264 width=228></td> |
| |
| <td><img SRC="bbox2.png" height=229 width=217></td> |
| </tr> |
| </table></center> |
| |
| <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> |
| |
| </blockquote><h3><a name="section-3"> |
| 3. Coordinates, scaling and grid-fitting : |
| </h3><blockquote> |
| |
| <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>The following operations can be used to round vectorial distances in |
| the 26.6 format to the grid : |
| </p> |
| |
| <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> |
| |
| </body> |
| </html> |