docs/glyphs/glyphs-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>FreeType Glyph Conventions</title>
 </head>

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

 <h1 align=center>
   FreeType Glyph Conventions
 </h1>

 <h2 align=center>
   Version&nbsp;2.1
 </h2>

 <h3 align=center>
   Copyright&nbsp;1998-2000 David Turner (<a
   href="mailto:david@freetype.org">david@freetype.org</a>)<br>
   Copyright&nbsp;2000 The FreeType Development Team (<a
   href="mailto:devel@freetype.org">devel@freetype.org</a>)
 </h3>

 <center>
 <table width="65%">
 <tr><td>

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

   <p><hr></p>

   <table width="100%">
   <tr bgcolor="#CCCCFF"
       valign=center><td>
     <h2>
       II. Glyph mutlines
     </h2>
   </td></tr>
   </table>

   <p>This section describes the way scalable representation of glyph images,
   called outlines, are used by FreeType as well as client applications.</p>

     <a name="section-1">
     <h3>
       1. Pixels, points and device resolutions
     </h3>

     <p>Though it is a very common assumption when dealing with computer
     graphics programs, the physical dimensions of a given pixel (be it for
     screens or printers) are not squared.  Often, the output device, be it a
     screen or printer, exhibits varying resolutions in both horizontal and
     vertical direction, and this must be taken care of when rendering
     text.</p>

     <p>It is thus common to define a device's characteristics through two
     numbers expressed in <em>dpi</em> (dots per inch).  For example, a
     printer with a resolution of 300x600&nbsp;dpi has 300&nbsp;pixels per
     inch in the horizontal direction, and 600 in the vertical one.  The
     resolution of a typical computer monitor varies with its size
     (15"&nbsp;and 17"&nbsp;monitors don't have the same pixel sizes at
     640x480), and of course the graphics mode resolution.</p>

     <p>As a consequence, the size of text is usually given in
     <em>points</em>, rather than device-specific pixels.  Points are a
     simple <em>physical</em> unit, where 1&nbsp;point&nbsp;=&nbsp;1/72th of
     an inch, in digital typography.  As an example, most Roman books are
     printed with a body text which size is chosen between 10 and
     14&nbsp;points.</p>

     <p>It is thus possible to compute the size of text in pixels from the
     size in points with the following formula:</p>

     <center>
       <tt>pixel_size = point_size * resolution / 72</tt>
     </center>

     <p>The resolution is expressed in <em>dpi</em>.  Since horizontal and
     vertical resolutions may differ, a single point size usually defines a
     different text width and height in pixels.</p>

     <p><em>Unlike what is often thought, the "size of text in pixels" is not
     directly related to the real dimensions of characters when they are
     displayed or printed.  The relationship between these two concepts is a
     bit more complex and relate to some design choices made by the font
     designer.  This is described in more detail in the next sub-section (see
     the explanations on the EM square).</em></p>


     <a name="section-2">
     <h3>
       2. Vectorial representation
     </h3>

     <p>The source format of outlines is a collection of closed paths called
     <em>contours</em>.  Each contour delimits an outer or inner
     <em>region</em> of the glyph, and can be made of either <em>line
     segments</em> or <em>B&eacute;zier arcs</em>.</p>

     <p>The arcs are defined through <em>control points</em>, and can be
     either second-order (these are <em>conic</em> B&eacute;ziers) or
     third-order (<em>cubic</em> B&eacute;ziers) polynomials, depending on
     the font format.  Note that conic B&eacute;ziers are usually called
     <em>quadratic</em> B&eacute;ziers in the literature.  Hence, each point
     of the outline has an associated flag indicating its type (normal or
     control point).  And scaling the points will scale the whole
     outline.</p>

     <p>Each glyph's original outline points are located on a grid of
     indivisible units.  The points are usually stored in a font file as
     16-bit integer grid coordinates, with the grid origin's being at (0,0);
     they thus range from -16384 to&nbsp;16383.  (Even though point
     coordinates can be floats in other formats such as Type&nbsp;1, we will
     restrict our analysis to integer values for simplicity).</p>

     <p><em>The grid is always oriented like the traditional mathematical
     two-dimensional plane, i.e., the <i>X</i>&nbsp;axis from the left to the
     right, and the <i>Y</i>&nbsp;axis from bottom to top.</em></p>

     <p>In creating the glyph outlines, a type designer uses an imaginary
     square called the <em>EM square</em>.  Typically, the EM square can be
     thought of as a tablet on which the character are drawn.  The square's
     size, i.e., the number of grid units on its sides, is very important for
     two reasons:</p>

     <ul>
       <li>
         <p>It is the reference used to scale the outlines to a given text
         dimension.  For example, a size of 12pt at 300x300&nbsp;dpi
         corresponds to 12*300/72&nbsp;=&nbsp;50&nbsp;pixels.  This is the
         size the EM square would appear on the output device if it was
         rendered directly.  In other words, scaling from grid units to
         pixels uses the formula:</p>

         <p><center>
           <tt>pixel_size = point_size * resolution / 72</tt><br>
           <tt>pixel_coord = grid_coord * pixel_size / EM_size</tt>
         </center></p>
       </li>
       <li>
         <p>The greater the EM size is, the larger resolution the designer
         can use when digitizing outlines.  For example, in the extreme
         example of an EM size of 4&nbsp;units, there are only 25&nbsp;point
         positions available within the EM square which is clearly not
         enough.  Typical TrueType fonts use an EM size of 2048&nbsp;units;
         Type&nbsp;1 PostScript fonts have a fixed EM size of 1000&nbsp;grid
         units but point coordinates can be expressed as floating values.</p>
       </li>
     </ul>

     <p>Note that glyphs can freely extend beyond the EM square if the font
     designer wants so.  The EM is used as a convenience, and is a valuable
     convenience from traditional typography.</p>

     <p>Grid units are very often called <em>font units</em> or <em>EM
     units</em>.</p>

     <p><em>As said before, <tt>pixel_size</tt> computed in the above formula
     does not relate directly to the size of characters on the screen.  It
     simply is the size of the EM square if it was to be displayed.  Each
     font designer is free to place its glyphs as it pleases him within the
     square.  This explains why the letters of the following text have not
     the same height, even though they are displayed at the same point size
     with distinct fonts:</em>

     <p><center>
       <img src="body_comparison.png"
            height=40 width=580
            alt="Comparison of font heights">
     </center></p>

     <p>As one can see, the glyphs of the Courier family are smaller than
     those of Times New Roman, which themselves are slightly smaller than
     those of Arial, even though everything is displayed or printed at a size
     of 16&nbsp;points.  This only reflects design choices.</p>


     <a name="section-3">
     <h3>
       3. Hinting and Bitmap rendering
     </h3>

     <p>The outline as stored in a font file is called the "master" outline,
     as its points coordinates are expressed in font units.  Before it can be
     converted into a bitmap, it must be scaled to a given size/resolution.
     This is done through a very simple transformation, but always creates
     undesirable artifacts, e.g. stems of different widths or heights in
     letters like "E" or "H".</p>

     <p>As a consequence, proper glyph rendering needs the scaled points to
     be aligned along the target device pixel grid, through an operation
     called <em>grid-fitting</em>, and often <em>hinting</em>.  One of its
     main purposes is to ensure that important widths and heights are
     respected throughout the whole font (for example, it is very often
     desirable that the "I" and the "T" have their central vertical line of
     the same pixel width), as well as to manage features like stems and
     overshoots, which can cause problems at small pixel sizes.</p>

     <p>There are several ways to perform grid-fitting properly; most
     scalable formats associate some control data or programs with each glyph
     outline.  Here is an overview:</p>

     <ul>
       <li>
         <p><em>explicit grid-fitting</em></p>

         <p>The TrueType format defines a stack-based virtual machine, for
         which programs can be written with the help of more than
         200&nbsp;opcodes (most of these relating to geometrical operations).
         Each glyph is thus made of both an outline and a control program to
         perform the actual grid-fitting in the way defined by the font
         designer.</p>
       </li>
       <li>
         <p><em>implicit grid-fitting (also called hinting)</em></p>

         <p>The Type&nbsp;1 format takes a much simpler approach: Each glyph
         is made of an outline as well as several pieces called
         <em>hints</em> which are used to describe some important features of
         the glyph, like the presence of stems, some width regularities, and
         the like.  There aren't a lot of hint types, and it is up to the
         final renderer to interpret the hints in order to produce a fitted
         outline.</p>
       </li>
       <li>
         <p><em>automatic grid-fitting</em></p>

         <p>Some formats simply include no control information with each
         glyph outline, apart metrics like the advance width and height.  It
         is then up to the renderer to "guess" the more interesting features
         of the outline in order to perform some decent grid-fitting.</p>
       </li>
     </ul>

     <p>The following table summarises the pros and cons of each scheme.</p>

     <center>
       <table width="90%"
              bgcolor="#CCCCCC"
              cellpadding=5>
       <tr bgcolor="#999999">
         <td>
           <center>
             <b>grid-fitting scheme</b>
           </center>
         </td>
         <td>
           <center>
             <b>advantages</b>
           </center>
         </td>
         <td>
           <center>
             <b>disadvantages</b>
           </center>
         </td>
       </tr>

       <tr>
         <td valign=top>
           <center>
             <b>explicit</b>
           </center>
         </td>

         <td valign=top>
           <p><b>Quality.</b> Excellent results at small sizes are possible.
           This is very important for screen display.</p>

           <p><b>Consistency.</b> All renderers produce the same glyph
           bitmaps.</p>
         </td>

         <td valign=top>
           <p><b>Speed.</b> Intepreting bytecode can be slow if the glyph
           programs are complex.</p>

           <p><b>Size.</b> Glyph programs can be long.</p>

           <p><b>Technicity.</b>
           It is extremely difficult to write good hinting
           programs.  Very few tools available.</p>
         </td>
       </tr>
       <tr>
         <td valign=top>
           <center>
             <b>implicit</b>
           </center>
         </td>

         <td valign=top>
           <p><b>Size.</b> Hints are usually much smaller than explicit glyph
           programs.</p>

           <p><b>Speed.</b>
           Grid-fitting is usually a fast process.</p>
         </td>

         <td valign=top>
           <p><b>Quality.</b> Often questionable at small sizes.  Better with
           anti-aliasing though.</p>

           <p><b>Inconsistency.</b> Results can vary between different
           renderers, or even distinct versions of the same engine.</p>
         </td>
       </tr>

       <tr>
         <td valign=top>
           <center>
             <b>automatic</b>
           </center>
         </td>

         <td valign=top>
           <p><b>Size.</b> No need for control information, resulting in
           smaller font files.</p>

           <p><b>Speed.</b> Depends on the grid-fitting algorithm.  Usually
           faster than explicit grid-fitting.</p>
         </td>

         <td valign=top>
           <p><b>Quality.</b> Often questionable at small sizes.  Better with
           anti-aliasing though.</p>

           <p><b>Speed.</b> Depends on the grid-fitting algorithm.</p>

           <p><b>Inconsistency.</b> Results can vary between different
           renderers, or even distinct versions of the same engine.</p>
         </td>
       </tr>
       </table>
     </center>

   <p><hr></p>

   <center>
   <table width="100%"
          border=0
          cellpadding=5>
   <tr bgcolor="#CCFFCC"
       valign=center>
     <td align=center
         width="30%">
       <a href="glyphs-1.html">Previous</a>
     </td>
     <td align=center
         width="30%">
       <a href="index.html">Contents</a>
     </td>
     <td align=center
         width="30%">
       <a href="glyphs-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>FreeType Glyph Conventions</title>
	</head>

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

	<h1 align=center>
	FreeType Glyph Conventions
	</h1>

	<h2 align=center>
	Version 2.1
	</h2>

	<h3 align=center>
	Copyright 1998-2000 David Turner (<a
	href="mailto:david@freetype.org">david@freetype.org</a>)<br>
	Copyright 2000 The FreeType Development Team (<a
	href="mailto:devel@freetype.org">devel@freetype.org</a>)
	</h3>

	<center>
	<table width="65%">
	<tr><td>

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

	<p><hr></p>

	<table width="100%">
	<tr bgcolor="#CCCCFF"
	valign=center><td>
	<h2>
	II. Glyph mutlines
	</h2>
	</td></tr>
	</table>

	<p>This section describes the way scalable representation of glyph images,
	called outlines, are used by FreeType as well as client applications.</p>

	<a name="section-1">
	<h3>
	1. Pixels, points and device resolutions
	</h3>

	<p>Though it is a very common assumption when dealing with computer
	graphics programs, the physical dimensions of a given pixel (be it for
	screens or printers) are not squared. Often, the output device, be it a
	screen or printer, exhibits varying resolutions in both horizontal and
	vertical direction, and this must be taken care of when rendering
	text.</p>

	<p>It is thus common to define a device's characteristics through two
	numbers expressed in <em>dpi</em> (dots per inch). For example, a
	printer with a resolution of 300x600 dpi has 300 pixels per
	inch in the horizontal direction, and 600 in the vertical one. The
	resolution of a typical computer monitor varies with its size
	(15" and 17" monitors don't have the same pixel sizes at
	640x480), and of course the graphics mode resolution.</p>

	<p>As a consequence, the size of text is usually given in
	<em>points</em>, rather than device-specific pixels. Points are a
	simple <em>physical</em> unit, where 1 point = 1/72th of
	an inch, in digital typography. As an example, most Roman books are
	printed with a body text which size is chosen between 10 and
	14 points.</p>

	<p>It is thus possible to compute the size of text in pixels from the
	size in points with the following formula:</p>

	<center>
	<tt>pixel_size = point_size * resolution / 72</tt>
	</center>

	<p>The resolution is expressed in <em>dpi</em>. Since horizontal and
	vertical resolutions may differ, a single point size usually defines a
	different text width and height in pixels.</p>

	<p><em>Unlike what is often thought, the "size of text in pixels" is not
	directly related to the real dimensions of characters when they are
	displayed or printed. The relationship between these two concepts is a
	bit more complex and relate to some design choices made by the font
	designer. This is described in more detail in the next sub-section (see
	the explanations on the EM square).</em></p>


	<a name="section-2">
	<h3>
	2. Vectorial representation
	</h3>

	<p>The source format of outlines is a collection of closed paths called
	<em>contours</em>. Each contour delimits an outer or inner
	<em>region</em> of the glyph, and can be made of either <em>line
	segments</em> or <em>Bézier arcs</em>.</p>

	<p>The arcs are defined through <em>control points</em>, and can be
	either second-order (these are <em>conic</em> Béziers) or
	third-order (<em>cubic</em> Béziers) polynomials, depending on
	the font format. Note that conic Béziers are usually called
	<em>quadratic</em> Béziers in the literature. Hence, each point
	of the outline has an associated flag indicating its type (normal or
	control point). And scaling the points will scale the whole
	outline.</p>

	<p>Each glyph's original outline points are located on a grid of
	indivisible units. The points are usually stored in a font file as
	16-bit integer grid coordinates, with the grid origin's being at (0,0);
	they thus range from -16384 to 16383. (Even though point
	coordinates can be floats in other formats such as Type 1, we will
	restrict our analysis to integer values for simplicity).</p>

	<p><em>The grid is always oriented like the traditional mathematical
	two-dimensional plane, i.e., the <i>X</i> axis from the left to the
	right, and the <i>Y</i> axis from bottom to top.</em></p>

	<p>In creating the glyph outlines, a type designer uses an imaginary
	square called the <em>EM square</em>. Typically, the EM square can be
	thought of as a tablet on which the character are drawn. The square's
	size, i.e., the number of grid units on its sides, is very important for
	two reasons:</p>

	<ul>
	<li>
	<p>It is the reference used to scale the outlines to a given text
	dimension. For example, a size of 12pt at 300x300 dpi
	corresponds to 12*300/72 = 50 pixels. This is the
	size the EM square would appear on the output device if it was
	rendered directly. In other words, scaling from grid units to
	pixels uses the formula:</p>

	<p><center>
	<tt>pixel_size = point_size * resolution / 72</tt><br>
	<tt>pixel_coord = grid_coord * pixel_size / EM_size</tt>
	</center></p>
	</li>
	<li>
	<p>The greater the EM size is, the larger resolution the designer
	can use when digitizing outlines. For example, in the extreme
	example of an EM size of 4 units, there are only 25 point
	positions available within the EM square which is clearly not
	enough. Typical TrueType fonts use an EM size of 2048 units;
	Type 1 PostScript fonts have a fixed EM size of 1000 grid
	units but point coordinates can be expressed as floating values.</p>
	</li>
	</ul>

	<p>Note that glyphs can freely extend beyond the EM square if the font
	designer wants so. The EM is used as a convenience, and is a valuable
	convenience from traditional typography.</p>

	<p>Grid units are very often called <em>font units</em> or <em>EM
	units</em>.</p>

	<p><em>As said before, <tt>pixel_size</tt> computed in the above formula
	does not relate directly to the size of characters on the screen. It
	simply is the size of the EM square if it was to be displayed. Each
	font designer is free to place its glyphs as it pleases him within the
	square. This explains why the letters of the following text have not
	the same height, even though they are displayed at the same point size
	with distinct fonts:</em>

	<p><center>
	<img src="body_comparison.png"
	height=40 width=580
	alt="Comparison of font heights">
	</center></p>

	<p>As one can see, the glyphs of the Courier family are smaller than
	those of Times New Roman, which themselves are slightly smaller than
	those of Arial, even though everything is displayed or printed at a size
	of 16 points. This only reflects design choices.</p>


	<a name="section-3">
	<h3>
	3. Hinting and Bitmap rendering
	</h3>

	<p>The outline as stored in a font file is called the "master" outline,
	as its points coordinates are expressed in font units. Before it can be
	converted into a bitmap, it must be scaled to a given size/resolution.
	This is done through a very simple transformation, but always creates
	undesirable artifacts, e.g. stems of different widths or heights in
	letters like "E" or "H".</p>

	<p>As a consequence, proper glyph rendering needs the scaled points to
	be aligned along the target device pixel grid, through an operation
	called <em>grid-fitting</em>, and often <em>hinting</em>. One of its
	main purposes is to ensure that important widths and heights are
	respected throughout the whole font (for example, it is very often
	desirable that the "I" and the "T" have their central vertical line of
	the same pixel width), as well as to manage features like stems and
	overshoots, which can cause problems at small pixel sizes.</p>

	<p>There are several ways to perform grid-fitting properly; most
	scalable formats associate some control data or programs with each glyph
	outline. Here is an overview:</p>

	<ul>
	<li>
	<p><em>explicit grid-fitting</em></p>

	<p>The TrueType format defines a stack-based virtual machine, for
	which programs can be written with the help of more than
	200 opcodes (most of these relating to geometrical operations).
	Each glyph is thus made of both an outline and a control program to
	perform the actual grid-fitting in the way defined by the font
	designer.</p>
	</li>
	<li>
	<p><em>implicit grid-fitting (also called hinting)</em></p>

	<p>The Type 1 format takes a much simpler approach: Each glyph
	is made of an outline as well as several pieces called
	<em>hints</em> which are used to describe some important features of
	the glyph, like the presence of stems, some width regularities, and
	the like. There aren't a lot of hint types, and it is up to the
	final renderer to interpret the hints in order to produce a fitted
	outline.</p>
	</li>
	<li>
	<p><em>automatic grid-fitting</em></p>

	<p>Some formats simply include no control information with each
	glyph outline, apart metrics like the advance width and height. It
	is then up to the renderer to "guess" the more interesting features
	of the outline in order to perform some decent grid-fitting.</p>
	</li>
	</ul>

	<p>The following table summarises the pros and cons of each scheme.</p>

	<center>
	<table width="90%"
	bgcolor="#CCCCCC"
	cellpadding=5>
	<tr bgcolor="#999999">
	<td>
	<center>
	<b>grid-fitting scheme</b>
	</center>
	</td>
	<td>
	<center>
	<b>advantages</b>
	</center>
	</td>
	<td>
	<center>
	<b>disadvantages</b>
	</center>
	</td>
	</tr>

	<tr>
	<td valign=top>
	<center>
	<b>explicit</b>
	</center>
	</td>

	<td valign=top>
	<p><b>Quality.</b> Excellent results at small sizes are possible.
	This is very important for screen display.</p>

	<p><b>Consistency.</b> All renderers produce the same glyph
	bitmaps.</p>
	</td>

	<td valign=top>
	<p><b>Speed.</b> Intepreting bytecode can be slow if the glyph
	programs are complex.</p>

	<p><b>Size.</b> Glyph programs can be long.</p>

	<p><b>Technicity.</b>
	It is extremely difficult to write good hinting
	programs. Very few tools available.</p>
	</td>
	</tr>
	<tr>
	<td valign=top>
	<center>
	<b>implicit</b>
	</center>
	</td>

	<td valign=top>
	<p><b>Size.</b> Hints are usually much smaller than explicit glyph
	programs.</p>

	<p><b>Speed.</b>
	Grid-fitting is usually a fast process.</p>
	</td>

	<td valign=top>
	<p><b>Quality.</b> Often questionable at small sizes. Better with
	anti-aliasing though.</p>

	<p><b>Inconsistency.</b> Results can vary between different
	renderers, or even distinct versions of the same engine.</p>
	</td>
	</tr>

	<tr>
	<td valign=top>
	<center>
	<b>automatic</b>
	</center>
	</td>

	<td valign=top>
	<p><b>Size.</b> No need for control information, resulting in
	smaller font files.</p>

	<p><b>Speed.</b> Depends on the grid-fitting algorithm. Usually
	faster than explicit grid-fitting.</p>
	</td>

	<td valign=top>
	<p><b>Quality.</b> Often questionable at small sizes. Better with
	anti-aliasing though.</p>

	<p><b>Speed.</b> Depends on the grid-fitting algorithm.</p>

	<p><b>Inconsistency.</b> Results can vary between different
	renderers, or even distinct versions of the same engine.</p>
	</td>
	</tr>
	</table>
	</center>

	<p><hr></p>

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

	</td></tr>
	</table>
	</center>

	</body>
	</html>