kmx git

Commit 0901f653dbc5d121501168a9248dc95660b96a16

2000-11-09T08:01:18
Revised.
diff --git a/docs/glyphs/glyphs-1.html b/docs/glyphs/glyphs-1.html
index df4bee7..4b409af 100644
--- a/docs/glyphs/glyphs-1.html
+++ b/docs/glyphs/glyphs-1.html
@@ -56,6 +56,8 @@
   </table>
   </center>
 
+  <p><hr></p>
+
   <table width="100%">
   <tr bgcolor="#CCCCFF"
       valign=center><td>
@@ -166,6 +168,8 @@
     they are usually expressed in pixels then.</p>
 
 
+  <p><hr></p>
+
   <center>
   <table width="100%"
          border=0
diff --git a/docs/glyphs/glyphs-2.html b/docs/glyphs/glyphs-2.html
index ba84e9d..70ece64 100644
--- a/docs/glyphs/glyphs-2.html
+++ b/docs/glyphs/glyphs-2.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,354 +15,381 @@
       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-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>
-
-<table width="100%" cellpadding=4><tr bgcolor="#CCCCFF" valign=center><td><h2>
-II. Glyph Outlines
-</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>
-
-<h3><a name="section-1">
-1. Pixels, Points and Device Resolutions :
-</h3><blockquote>
-
-<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 the horizontal and vertical
-directions, 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 <b>dpi</b> (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 (a 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 <b>points</b>,
-rather than device-specific pixels. Points are a simple <i>physical</i>
-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 through the following computation :</p>
+<h1 align=center>
+  FreeType Glyph Conventions
+</h1>
 
-<center>
-<p><tt>pixel_size = point_size * resolution / 72</tt></center>
-
-<p>Where resolution is expressed in <em>dpi</em>. Note that because the
-horizontal and vertical resolutions may differ, a single point size
-usually defines different text width and height in pixels.</p>
-
-<p><b>IMPORTANT NOTE:</b>
-<br><i>Unlike what is often thought, the "size of text in pixels" is not
-directly related to the real dimensions of characters when they're displayed
-or printed. The relationship between these two concepts is a bit more complex
-and relate to some design choice made by the font designer. This is described
-in more details the next sub-section (see the explanations on the EM square).
-</i></p>
-
-
-
-</blockquote><h3><a name="section-2">
-2. Vectorial representation :
-</h3><blockquote>
-
-
-
-<p>The source format of outlines is a collection of closed paths
-called <b>contours</b>. Each contour delimits an outer or inner <i>region</i>
-of the glyph, and can be made of either <b>line segments</b> or <b>bezier
-arcs</b>.</p>
-
-<p>The arcs are defined through <b>control points</b>, and can be either
-second-order (these are "conic" beziers) or third-order ("cubic" beziers) polynomials, depending on
-the font format. Note that conic beziers are usually called "quadratic"
-beziers in the literature. Hence, each point of the outline has an
-associated <b>flag</b> 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'll restrict our analysis to integer ones, driven
-by the need for simplicity..).
-</p>
-
-<p><b>IMPORTANT NOTE:</b>
-<br><i>The grid is always oriented like the traditional mathematical 2D
-plane, i.e. the X axis from the left to the right, and the Y axis from
-bottom to top.</i></p>
-
-<p>In creating the glyph outlines, a type designer uses an imaginary square
-called the "EM square". 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_coordinate = grid_coordinate * pixel_size / EM_size</tt>
-</center></p>
-
-
-<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 (note: with Type 1 PostScript fonts, the EM size is
-fixed to 1000 grid units. However, point coordinates can be expressed in
-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>
+<h2 align=center>
+  Version&nbsp;2.1
+</h2>
 
-<center>
-<p><b>Note : Grid units are very often called "font units" or "EM units".</b></center>
-
-<p><b>NOTE:</b>
-<br><i>As said before, the pixel_size computed in&nbsp; 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 directly. 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're displayed at the same point size with distinct fonts
-:</i>
-<center>
-<p><img SRC="body_comparison.png" height=40 width=580></center>
-
-<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&nbsp; at a size of
-16 points. This only reflect design choices.
-</p>
-
-
-
-</blockquote><h3><a name="section-3">
-3. Hinting and Bitmap rendering
-</h3><blockquote>
-
-<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 transform, 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
-"grid-fitting", and often "hinting". One of its main purpose 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 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, for example
-most scalable formats associate some control data or programs with each
-glyph outline. Here is an overview :</p>
-
-<blockquote>
-<blockquote><b>explicit grid-fitting :</b>
-<blockquote>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, its purpose being to perform
-the actual grid-fitting in the way defined by the font designer.</blockquote>
-
-<p><br><b>implicit grid-fitting (also called hinting) :</b>
-<blockquote>The Type 1 format takes a much simpler approach : each glyph
-is made of an outline as well as several pieces called "hints" 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's up to the final renderer to interpret the hints in
-order to produce a fitted outline.</blockquote>
-
-<p><br><b>automatic grid-fitting :</b>
-<blockquote>Some formats simply include no control information with each
-glyph outline, apart metrics like the advance width and height. It's then
-up to the renderer to "guess" the more interesting features of the outline
-in order to perform some decent grid-fitting.</blockquote>
-</blockquote>
-</blockquote>
+<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>
-<p><br>The following table summarises the pros and cons of each scheme
-:</center>
-</blockquote>
-
-<center><table BORDER=0 WIDTH="80%" BGCOLOR="#CCCCCC" >
-<tr BGCOLOR="#999999">
-<td>
-<blockquote>
-<center><b><font color="#000000">Grid-fitting scheme</font></b></center>
-</blockquote>
-</td>
-
-<td>
-<blockquote>
-<center><b><font color="#000000">Pros</font></b></center>
-</blockquote>
-</td>
-
-<td>
-<blockquote>
-<center><b><font color="#000000">Cons</font></b></center>
-</blockquote>
-</td>
-</tr>
-
-<tr>
-<td>
-<blockquote>
-<center><b><font color="#000000">Explicit</font></b></center>
-</blockquote>
-</td>
-
-<td>
-<blockquote>
-<center><b><font color="#000000">Quality</font></b>
-<br><font color="#000000">excellence at small sizes is possible. This is
-very important for screen display.</font>
-<p><b><font color="#000000">Consistency</font></b>
-<br><font color="#000000">all renderers produce the same glyph bitmaps.</font></center>
-</blockquote>
-</td>
-
-<td>
-<blockquote>
-<center><b><font color="#000000">Speed</font></b>
-<br><font color="#000000">intepreting bytecode can be slow if the glyph
-programs are complex.</font>
-<p><b><font color="#000000">Size</font></b>
-<br><font color="#000000">glyph programs can be long</font>
-<p><b><font color="#000000">Technicity</font></b>
-<br><font color="#000000">it is extremely difficult to write good hinting
-programs. Very few tools available.</font></center>
-</blockquote>
-</td>
-</tr>
-
-<tr>
-<td>
-<blockquote>
-<center><b><font color="#000000">Implicit</font></b></center>
-</blockquote>
-</td>
-
-<td>
-<blockquote>
-<center><b><font color="#000000">Size</font></b>
-<br><font color="#000000">hints are usually much smaller than explicit
-glyph programs.</font>
-<p><b><font color="#000000">Speed</font></b>
-<br><font color="#000000">grid-fitting is usually a fast process</font></center>
-</blockquote>
-</td>
-
-<td>
-<blockquote>
-<center><b><font color="#000000">Quality</font></b>
-<br><font color="#000000">often questionable at small sizes. Better with
-anti-aliasing though.</font>
-<p><b><font color="#000000">Inconsistency</font></b>
-<br><font color="#000000">results can vary between different renderers,
-or even distinct versions of the same engine.</font></center>
-</blockquote>
-</td>
-</tr>
-
-<tr>
-<td>
-<blockquote>
-<center><b><font color="#000000">Automatic</font></b></center>
-</blockquote>
-</td>
-
-<td>
-<blockquote>
-<center><b><font color="#000000">Size</font></b>
-<br><font color="#000000">no need for control information, resulting in
-smaller font files.</font>
-<p><b><font color="#000000">Speed</font></b>
-<br><font color="#000000">depends on the grid-fitting algo.Usually faster
-than explicit grid-fitting.</font></center>
-</blockquote>
-</td>
-
-<td>
-<blockquote>
-<center><b><font color="#000000">Quality</font></b>
-<br><font color="#000000">often questionable at small sizes. Better with
-anti-aliasing though</font>
-<p><b><font color="#000000">Speed</font></b>
-<br><font color="#000000">depends on the grid-fitting algo.</font>
-<p><b><font color="#000000">Inconsistency</font></b>
-<br><font color="#000000">results can vary between different renderers,
-or even distinct versions of the same engine.</font></center>
-</blockquote>
-</td>
-</tr>
-</table></center>
-</blockquote>
-
-<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>
+<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 Outlines
+    </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>
kc3-lang/freetype

Commit 0901f653dbc5d121501168a9248dc95660b96a16
