Chiebot-Mirror
/
freetype
mirror of https://github.com/freetype/freetype.git
8
0
Fork 0
Code Issues Projects Releases Wiki Activity

Revised.

Browse Source
david-pic-changes
Werner Lemberg 25 years ago
parent 5330dd6e81
commit 0901f653db
2 changed files with 383 additions and 351 deletions
Whitespace
Show all changes Ignore whitespace when comparing lines Ignore changes in amount of whitespace Ignore changes in whitespace at EOL
Split View
Diff Options
Show Stats Download Patch File Download Diff File
  1. 4
      docs/glyphs/glyphs-1.html
  2. 730
      docs/glyphs/glyphs-2.html

4
docs/glyphs/glyphs-1.html
Unescape View File

@ -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

730
docs/glyphs/glyphs-2.html
Unescape View File

@ -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>

Write Preview
Loading…
Cancel
Save