This commit is contained in:
Werner Lemberg 2000-11-09 16:23:23 +00:00
parent 0901f653db
commit fed760b1bf
2 changed files with 372 additions and 251 deletions

View File

@ -62,7 +62,7 @@
<tr bgcolor="#CCCCFF" <tr bgcolor="#CCCCFF"
valign=center><td> valign=center><td>
<h2> <h2>
II. Glyph Outlines II. Glyph mutlines
</h2> </h2>
</td></tr> </td></tr>
</table> </table>

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> <html>
<head> <head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> <meta http-equiv="Content-Type"
<meta name="Author" content="blob"> content="text/html; charset=iso-8859-1">
<meta name="GENERATOR" content="Mozilla/4.5 [fr] (Win98; I) [Netscape]"> <meta name="Author"
content="David Turner">
<title>FreeType Glyph Conventions</title> <title>FreeType Glyph Conventions</title>
</head> </head>
<body>
<body text="#000000" <body text="#000000"
bgcolor="#FFFFFF" bgcolor="#FFFFFF"
@ -14,296 +15,416 @@
vlink="#51188E" vlink="#51188E"
alink="#FF0000"> alink="#FF0000">
<center> <h1 align=center>
<h1> FreeType Glyph Conventions
FreeType Glyph Conventions</h1></center> </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> <center>
<h2> <table width="65%">
version 2.1</h2></center> <tr><td>
<center> <center>
<h3> <table width="100%"
Copyright 1998-2000 David Turner (<a href="mailto:david@freetype.org">david@freetype.org</a>)<br> border=0
Copyright 2000 The FreeType Development Team (<a href="devel@freetype.org">devel@freetype.org</a>)</h3></center> cellpadding=5>
<tr bgcolor="#CCFFCC"
valign=center>
<td align=center
width="30%">
<a href="glyphs-2.html">Previous</a>
</td>
<td align=center
width="30%">
<a href="index.html">Contents</a>
</td>
<td align=center
width="30%">
<a href="glyphs-4.html">Next</a>
</td>
</tr>
</table>
</center>
<center><table width=650><tr><td> <p><hr></p>
<center><table width="100%" border=0 cellpadding=5><tr bgcolor="#CCFFCC" valign=center> <table width="100%">
<td align=center width="30%"> <tr bgcolor="#CCCCFF"
<a href="glyphs-2.html">Previous</a> valign=center><td>
</td> <h2>
<td align=center width="30%"> III. Glyph metrics
<a href="index.html">Contents</a> </h2>
</td> </td></tr>
<td align=center width="30%"> </table>
<a href="glyphs-4.html">Next</a>
</td>
</tr></table></center>
<table width="100%"><tr valign=center bgcolor="#ccccff"><td><h2> <a name="section-1">
III. Glyph metrics <h3>
</h2></td></tr></table> 1. Baseline, pens and layouts
</h3>
<h3><a name="section-1"> <p>The baseline is an imaginary line that is used to "guide" glyphs when
1. Baseline, Pens and Layouts rendering text. It can be horizontal (e.g. Roman, Cyrillic, Arabic,
</h3><blockquote> etc.) or vertical (e.g. Chinese, Japanese, Korean, etc). Moreover, to
render text, a virtual point, located on the baseline, called the <em>pen
position</em> or <em>origin</em>, is used to locate glyphs.</p>
<p>The baseline is an imaginary line that is used to "guide" glyphs when <p>Each layout uses a different convention for glyph placement:</p>
rendering text. It can be horizontal (e.g. Roman, Cyrillic, Arabic, etc.)
or vertical (e.g. Chinese, Japanese, Korean, etc). Moreover, to render
text, a virtual point, located on the baseline, called the "pen position"
or "origin", is used to locate glyphs.
</p>
<p>Each layout uses a different convention for glyph placement:</p> <ul>
<ul>
<li> <li>
with horizontal layout, glyphs simply "rest" on the baseline. Text <p>With horizontal layout, glyphs simply "rest" on the baseline.
is rendered by incrementing the pen position, either to the right or Text is rendered by incrementing the pen position, either to the
to the left. right or to the left.</p>
<p>The distance between two successive pen positions is
glyph-specific and is called the <em>advance width</em>. Note that
its value is <em>always</em> positive, even for right-to-left
oriented alphabets, like Arabic. This introduces some differences
in the way text is rendered.</p>
<p><em>The pen position is always placed on the baseline.</em></p>
<p><center>
<img src="Image1.png"
height=179 width=458
alt="horizontal layout">
</center></p>
</li>
<li>
<p>With a vertical layout, glyphs are centered around the
baseline:</p>
<p><center>
<img src="Image2.png"
height=275 width=162
alt="vertical layout">
</center></p>
</li>
</ul>
<a name="section-2">
<h3>
2. Typographic metrics and bounding boxes
</h3>
<p>A various number of face metrics are defined for all glyphs in a
given font.</p>
<ul>
<li>
<p><em>Ascent</em></p>
<p>The distance from the baseline to the highest/upper grid
coordinate used to place an outline point. It is a positive value,
due to the grid's orientation with the <i>Y</i>&nbsp;axis
upwards.</p>
</li> </li>
<li>
<p><em>Descent</em></p>
<p>the distance between two successive pen positions is glyph-specific <p>The distance from the baseline to the lowest grid coordinate used
and is called the <b>advance width</b>. Note that its value is _always_ to place an outline point. This is a negative value, due to the
positive, even for right-to-left oriented alphabets, like Arabic. This grid's orientation.</p>
introduces some differences in the way text is rendered. </li>
</p>
<p>IMPORTANT NOTE:&nbsp; The pen position is always placed on the baseline. <li>
</p> <p><em>Linegap</em></p>
<p><center><img SRC="Image1.png" height=179 width=458></center></p> <p>The distance that must be placed between two lines of text. The
baseline-to-baseline distance should be computed as:
<center><p>
<tt>ascent - descent + linegap</tt>
</p></center>
<p>if you use the typographic values.</p>
</li>
</ul>
<p>Other, simpler metrics are:</p>
<ul>
<li>
<p><em>The glyph's bounding box</em>, also called <em>bbox</em></p>
<p>This is an imaginary box that encloses all glyphs from the font,
usually as tightly as possible. It is represented by four fields,
namely <tt>xMin</tt>, <tt>yMin</tt>, <tt>xMax</tt>, and
<tt>yMax</tt>, that can be computed for any outline. Their values
can be in font units (if measured in the original outline) or in
fractional/integer pixel units (when measured on scaled
outlines).</p>
<p>Note that if it wasn't for grid-fitting, you wouldn't need to
know a box's complete values, but only its dimensions to know how
big is a glyph outline/bitmap. However, correct rendering of hinted
glyphs needs the preservation of important grid alignment on each
glyph translation/placement on the baseline.</p>
</li>
<li>
<p><em>Internal leading</em></p>
<p>This concept comes directly from the world of traditional
typography. It represents the amount of space within the
<em>leading</em> which is reserved for glyph features that lay
outside of the EM square (like accentuation). It usually can be
computed as:</p>
<center><p>
<tt>internal leading = ascent - descent - EM_size</tt>
</p></center>
</li>
<li>
<p><em>External leading</em></p>
<p>This is another name for the line gap.</p>
</li>
</ul>
<li>with a vertical layout, glyphs are centered around the baseline:</li> <a name="section-3">
<h3>
3. Bearings and Advances
</h3>
<p><center><img SRC="Image2.png" height=275 width=162></center></p> Each glyph has also distances called <em>bearings</em> and
<em>advances</em>. Their definition is constant, but their values
depend on the layout, as the same glyph can be used to render text
either horizontally or vertically:
</ul> <ul>
<li>
<p><em>Left side bearing</em> or <em>bearingX</em></p>
</blockquote><h3><a name="section-2"> <p>The horizontal distance from the current pen position to the
2. Typographic metrics and bounding boxes glyph's left bbox edge. It is positive for horizontal layouts, and
</h3><blockquote> in most cases negative for vertical one.</p>
</li>
<p>A various number of face metrics are defined for all glyphs in a given <li>
font.</p> <p><em>Top side bearing</em> or <em>bearingY</em></p>
<p><b>the ascent</b></p> <p>The vertical distance from the baseline to the top of the glyph's
<ul> bbox. It is usually positive for horizontal layouts, and negative
<p>this is the distance from the baseline to the highest/upper grid coordinate for vertical ones</p>
used to place an outline point. It is a positive value, due to the grid's </li>
orientation with the Y axis upwards.
</p>
</ul>
<p><br><b>the descent</b></p> <li>
<ul><p> <p><em>Advance width</em> or <em>advanceX</em></p>
the distance from the baseline to the lowest grid coordinate used to
place an outline point. This is a negative value, due to the grid's
orientation.
</p></ul>
<p><br><b>the linegap</b> <p>The horizontal distance the pen position must be incremented (for
<ul>the distance that must be placed between two lines of text. The baseline-to-baseline left-to-right writing) or decremented (for right-to-left writing) by
distance should be computed as: after each glyph is rendered when processing text. It is always
<center> positive for horizontal layouts, and null for vertical ones.</p>
<p><tt>ascent - descent + linegap</tt></center> </li>
if you use the typographic values.</ul>
Other, simpler metrics are:
<p><b>the glyph's bounding box</b>, also called "<b>bbox</b>"
<ul>this is an imaginary box that encloses all glyphs from the font, as
tightly as possible. It is represented by four fields, namely <tt>xMin</tt>,
<tt>yMin</tt>,
<tt>xMax</tt>,
and <tt>yMax</tt>, that can be computed for any outline. Their values can
be in font units (if measured in the original outline) or in fractional/integer
pixel units (when measured on scaled outlines).
<p>Note that if it wasn't for grid-fitting, you wouldn't need to know a
box's complete values, but only its dimensions to know how big is a glyph
outline/bitmap. However, correct rendering of hinted glyphs needs the preservation
of important grid alignment on each glyph translation/placement on the
baseline.</ul>
<b>the internal leading</b>
<ul>this concept comes directly from the world of traditional typography.
It represents the amount of space within the "leading" which is reserved
for glyph features that lay outside of the EM square (like accentuation).
It usually can be computed as:
<center>
<p><tt>internal leading = ascent - descent - EM_size</tt></center>
</ul>
<b>the external leading</b>
<ul>this is another name for the line gap.</ul>
</ul>
<h3><a name="section-3"> <li>
3. Bearings and Advances</h3> <p><em>Advance height</em> <em>advanceY</em></p>
<ul>Each glyph has also distances called "bearings" and "advances". Their <p>The vertical distance the pen position must be decremented by
definition is constant, but their values depend on the layout, as the same after each glyph is rendered. It is always null for horizontal
glyph can be used to render text either horizontally or vertically: layouts, and positive for vertical layouts.</p>
<p><b>the left side bearing: a.k.a. bearingX</b> </li>
<ul>this is the horizontal distance from the current pen position to the
glyph's left bbox edge. It is positive for horizontal layouts, and most
generally negative for vertical one.</ul>
<p><br><b>the top side bearing: a.k.a. bearingY</b> <li>
<ul>this is the vertical distance from the baseline to the top of the glyph's <p><em>Glyph width</em></p>
bbox. It is usually positive for horizontal layouts, and negative for vertical
ones</ul>
<p><br><b>the advance width: a.k.a. advanceX</b> <p>The glyph's horizontal extent. For unscaled font coordinates, it
<ul>is the horizontal distance the pen position must be incremented (for is <tt>bbox.xMax-bbox.xMin</tt>. For scaled glyphs, its computation
left-to-right writing) or decremented (for right-to-left writing) by after requests specific care, described in the grid-fitting chapter
each glyph is rendered when processing text. It is always positive for below.</p>
horizontal layouts, and null for vertical ones.</ul> </li>
<p><br><b>the advance height: a.k.a. advanceY</b> <li>
<ul>is the vertical distance the pen position must be decremented by after <p><em>Glyph height</em>
each glyph is rendered. It is always null for horizontal layouts, and positive
for vertical layouts.</ul>
<p><br><b>the glyph width</b> <p>The glyph's vertical extent. For unscaled font coordinates, it is
<ul>this is simply the glyph's horizontal extent. More simply it is (bbox.xMax-bbox.xMin) <tt>bbox.yMax-bbox.yMin</tt>. For scaled glyphs, its computation
for unscaled font coordinates. For scaled glyphs, its computation requests requests specific care, described in the grid-fitting chapter
specific care, described in the grid-fitting chapter below.</ul> below.</p>
</li>
<p><br><b>the glyph height</b> <li>
<ul>this is simply the glyph's vertical extent. More simply, it is (bbox.yMax-bbox.yMin) <p><em>Right side bearing</em></p>
for unscaled font coordinates. For scaled glyphs, its computation requests
specific care, described in the grid-fitting chapter below.</ul>
<p><br><b>the right side bearing</b> <p>Only used for horizontal layouts to describe the distance from
<ul>is only used for horizontal layouts to describe the distance from the the bbox's right edge to the advance width. It is in most cases a
bbox's right edge to the advance width. It is in most cases a non-negative non-negative number:</p>
number.</ul>
<center><tt>advance_width - left_side_bearing - (xMax-xMin)</tt></center> <p><center>
<tt>advance_width - left_side_bearing - (xMax-xMin)</tt>
</center></p>
</li>
</ul>
<p>Here is a picture giving all the details for horizontal metrics : <p>Here is a picture giving all the details for horizontal metrics:
<center>
<p><img SRC="Image3.png" height=253 width=388></center>
<p>And here is another one for the vertical metrics : <center><p>
<center> <img src="Image3.png"
<p><img SRC="Image4.png" height=278 width=294></center> height=253 width=388
</ul> alt="horizontal glyph metrics">
</p></center>
<h3><a name="section-4"> <p>And here is another one for the vertical metrics:</p>
4. The effects of grid-fitting</h3>
<ul>Because hinting aligns the glyph's control points to the pixel grid, <center><p>
this process slightly modifies the dimensions of character images in ways <img src="Image4.png"
that differ from simple scaling. height=278 width=294
<p>For example, the image of the lowercase "m" letter sometimes fits a alt="vertical glyph metrics">
square in the master grid. However, to make it readable at small pixel </p></center>
sizes, hinting tends to enlarge its scaled outline in order to keep its
three legs distinctly visible, resulting in a larger character bitmap.
<p>The glyph metrics are also influenced by the grid-fitting process. Mainly
because :
<br>&nbsp;
<ul>
<li>
The image's width and height are altered. Even if this is only by one pixel,
it can make a big difference at small pixel sizes</li>
<li>
The image's bounding box is modified, thus modifying the bearings</li>
<li> <a name="section-4">
The advances must be updated. For example, the advance width must be incremented <h3>
when the hinted bitmap is larger than the scaled one, to reflect the augmented 4. The effects of grid-fitting
glyph width.</li> </h3>
</ul>
<p><br>Note also that : <p>Because hinting aligns the glyph's control points to the pixel grid,
<br>&nbsp; this process slightly modifies the dimensions of character images in
<ul> ways that differ from simple scaling.</p>
<li>
Because of hinting, simply scaling the font ascent or descent might not
give correct results. A simple solution consists in keeping the ceiling
of the scaled ascent, and floor of the scaled descent.</li>
</ul>
<ul> <p>For example, the image of the lowercase "m" letter sometimes fits a
<li> square in the master grid. However, to make it readable at small pixel
There is no easy way to get the hinted glyph and advance widths of a range sizes, hinting tends to enlarge its scaled outline in order to keep its
of glyphs, as hinting works differently on each outline. The only solution three legs distinctly visible, resulting in a larger character
is to hint each glyph separately and record the returned values. Some formats, bitmap.</p>
like TrueType, even include a table of pre-computed values for a small
set of common character pixel sizes.</li>
</ul>
<ul> <p>The glyph metrics are also influenced by the grid-fitting process:
<li>
Hinting depends on the final character width and height in pixels, which
means that it is highly resolution-dependent. This property makes correct
WYSIWYG layouts difficult to implement.</li>
</ul>
<p><br><b>IMPORTANT NOTE:</b> <ul>
<br>Performing 2D transforms on glyph outlines is very easy with FreeType. <li>
However, when using translation on a hinted outlines, one should aways The image's width and height are altered. Even if this is only by
take care of&nbsp; <b>exclusively using integer pixel distances</b> (which one pixel, it can make a big difference at small pixel sizes.
means that the parameters to the FT_Translate_Outline API should all be </li>
multiples of 64, as the point coordinates are in 26.6 fixed float format). <li>
<p><b>Otherwise</b>, the translation will simply <b>ruin the hinter's work</b>, The image's bounding box is modified, thus modifying the bearings.
resulting in a very low quality bitmaps. </li>
<br>&nbsp; <li>
<br>&nbsp;</ul> The advances must be updated. For example, the advance width must
be incremented if the hinted bitmap is larger than the scaled one,
to reflect the augmented glyph width.
</li>
</ul>
<h3><a name="section-5"> <p>This has some implications:</p>
&nbsp;5. Text widths and bounding box :</h3>
<ul>As seen before, the "origin" of a given glyph corresponds to the position <ul>
of the pen on the baseline. It is not necessarily located on one of the <li>
glyph's bounding box corners, unlike many typical bitmapped font formats. Because of hinting, simply scaling the font ascent or descent might
In some cases, the origin can be out of the bounding box, in others, it not give correct results. A possible solution is to keepthe ceiling
can be within it, depending on the shape of the given glyph. of the scaled ascent, and floor of the scaled descent.
<p>Likewise, the glyph's "advance width" is the increment to apply to the </li>
pen position during layout, and is not related to the glyph's "width",
which really is the glyph's bounding width.
<br>&nbsp;
<p>The same conventions apply to strings of text. This means that :
<br>&nbsp;
<ul>
<ul>
<li>
The bounding box of a given string of text doesn't necessarily contain
the text cursor, nor is the latter located on one of its corners.</li>
</ul>
<ul> <li>
<li> There is no easy way to get the hinted glyph and advance widths of a
The string's advance width isn't related to its bounding box's dimensions. range of glyphs, as hinting works differently on each outline. The
Especially if it contains beginning and terminal spaces or tabs.</li> only solution is to hint each glyph separately and record the
</ul> returned values. Some formats, like TrueType, even include a table
of pre-computed values for a small set of common character pixel
sizes.
</li>
<li>
Hinting depends on the final character width and height in pixels,
which means that it is highly resolution-dependent. This property
makes correct WYSIWYG layouts difficult to implement.
</li>
</ul>
<ul>
<li>
Finally, additional processing like kerning creates strings of text whose
dimensions are not directly related to the simple juxtaposition of individual
glyph metrics. For example, the advance width of "VA" isn't the sum of
the advances of "V" and "A" taken separately.</li>
</ul>
</ul>
</ul>
</ul>
<center><table width="100%" border=0 cellpadding=5><tr bgcolor="#CCFFCC" valign=center> <em>
<td align=center width="30%"> <p>Performing 2D transformations on glyph outlines is very easy with
<a href="glyphs-2.html">Previous</a> FreeType. However, when using translation on a hinted outlines, one
</td> should aways take care of <b>exclusively using integer pixel
<td align=center width="30%"> distances</b> (which means that the parameters to the
<a href="index.html">Contents</a> <tt>FT_Translate_Outline()</tt> API should all be multiples
</td> of&nbsp;64, as the point coordinates are in 26.6&nbsp;fixed float
<td align=center width="30%"> format).</p>
<a href="glyphs-4.html">Next</a>
</td>
</tr></table></center>
</td></tr></table></center> <p>Otherwise, the translation will simply <em>ruin the hinter's
work</em>, resulting in a very low quality bitmaps!</p>
</em>
<a name="section-5">
<h3>
5. Text widths and bounding box
</h3>
<p>As seen before, the "origin" of a given glyph corresponds to the
position of the pen on the baseline. It is not necessarily located on
one of the glyph's bounding box corners, unlike many typical bitmapped
font formats. In some cases, the origin can be out of the bounding box,
in others, it can be within it, depending on the shape of the given
glyph.</p>
<p>Likewise, the glyph's "advance width" is the increment to apply to
the pen position during layout, and is not related to the glyph's
"width", which really is the glyph's bounding width.
<p>The same conventions apply to strings of text. This means that:
<ul>
<li>
The bounding box of a given string of text doesn't necessarily
contain the text cursor, nor is the latter located on one of its
corners.
</li>
<li>
The string's advance width isn't related to its bounding box
dimensions. Especially if it contains beginning and terminal spaces
or tabs.
</li>
<li>
Finally, additional processing like kerning creates strings of text
whose dimensions are not directly related to the simple
juxtaposition of individual glyph metrics. For example, the advance
width of "VA" isn't the sum of the advances of "V" and "A" taken
separately.
</li>
</ul>
<p><hr></p>
<center>
<table width="100%"
border=0
cellpadding=5>
<tr bgcolor="#CCFFCC"
valign=center>
<td align=center
width="30%">
<a href="glyphs-2.html">Previous</a>
</td>
<td align=center
width="30%">
<a href="index.html">Contents</a>
</td>
<td align=center
width="30%">
<a href="glyphs-4.html">Next</a>
</td>
</tr>
</table>
</center>
</td></tr>
</table>
</center>
</body> </body>
</html> </html>