Edit File - File Manager

Edit File: glyphs-3.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>

<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>) 
 Copyright&nbsp;2000 The FreeType Development Team (<a
 href="mailto:devel@freetype.org">devel@freetype.org</a>)
</h3>

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

<hr>

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

<a name="section-1">
 <h3>
 1. Baseline, pens and layouts
 </h3>

The baseline is an imaginary line that is used to "guide" glyphs when
 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.

Each layout uses a different convention for glyph placement:

<ul>
 <li>
 With horizontal layout, glyphs simply "rest" on the baseline.
 Text is rendered by incrementing the pen position, either to the
 right or to the left.

The distance between two successive pen positions is
 glyph-specific and is called the advance width. Note that
 its value is always positive, even for right-to-left
 oriented alphabets, like Arabic. This introduces some differences
 in the way text is rendered.

The pen position is always placed on the baseline.

<center>
 <img src="Image1.png"
 height=179 width=458
 alt="horizontal layout">
 </center>
 </li>
 <li>
 With a vertical layout, glyphs are centered around the
 baseline:

<a name="section-2">
 <h3>
 2. Typographic metrics and bounding boxes
 </h3>

A various number of face metrics are defined for all glyphs in a
 given font.

<ul>
 <li>
 Ascent

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 Y&nbsp;axis
 upwards.
 </li>

<li>
 Descent

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.
 </li>

<li>
 Linegap

The distance that must be placed between two lines of text. The
 baseline-to-baseline distance should be computed as:

<center>
 <tt>ascent - descent + linegap</tt>
 </center>

if you use the typographic values.
 </li>
 </ul>

Other, simpler metrics are:

<ul>
 <li>
 The glyph's bounding box, also called bbox

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).

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.
 </li>

<li>
 Internal leading

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>
 <tt>internal leading = ascent - descent - EM_size</tt>
 </center>
 </li>

<li>
 External leading

This is another name for the line gap.
 </li>
 </ul>

<a name="section-3">
 <h3>
 3. Bearings and Advances
 </h3>

Each glyph has also distances called bearings and
 advances. 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>
 <li>
 Left side bearing or bearingX

The horizontal distance from the current pen position to the
 glyph's left bbox edge. It is positive for horizontal layouts, and
 in most cases negative for vertical ones.
 </li>

<li>
 Top side bearing or bearingY

The vertical distance from the baseline to the top of the glyph's
 bbox. It is usually positive for horizontal layouts, and negative
 for vertical ones.
 </li>

<li>
 Advance width or advanceX

The horizontal distance the pen position must be incremented (for
 left-to-right writing) or decremented (for right-to-left writing) by
 after each glyph is rendered when processing text. It is always
 positive for horizontal layouts, and null for vertical ones.
 </li>

<li>
 Advance height advanceY

The vertical distance the pen position must be decremented by
 after each glyph is rendered. It is always null for horizontal
 layouts, and positive for vertical layouts.
 </li>

<li>
 Glyph width

The glyph's horizontal extent. For unscaled font coordinates, it
 is <tt>bbox.xMax-bbox.xMin</tt>. For scaled glyphs, its computation
 requests specific care, described in the grid-fitting chapter
 below.
 </li>

<li>
 Glyph height

The glyph's vertical extent. For unscaled font coordinates, it is
 <tt>bbox.yMax-bbox.yMin</tt>. For scaled glyphs, its computation
 requests specific care, described in the grid-fitting chapter
 below.
 </li>

<li>
 Right side bearing

Only used for horizontal layouts to describe the distance from
 the bbox's right edge to the advance width. It is in most cases a
 non-negative number:

<center>
 <tt>advance_width - left_side_bearing - (xMax-xMin)</tt>
 </center>
 </li>
 </ul>

Here is a picture giving all the details for horizontal metrics:

And here is another one for the vertical metrics:

<a name="section-4">
 <h3>
 4. The effects of grid-fitting
 </h3>

Because hinting aligns the glyph's control points to the pixel grid,
 this process slightly modifies the dimensions of character images in
 ways that differ from simple scaling.

For example, the image of the lowercase "m" letter sometimes fits a
 square in the master grid. However, to make it readable at small pixel
 sizes, hinting tends to enlarge its scaled outline in order to keep its
 three legs distinctly visible, resulting in a larger character
 bitmap.

The glyph metrics are also influenced by the grid-fitting process:

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

This has some implications:

<ul>
 <li>
 Because of hinting, simply scaling the font ascent or descent might
 not give correct results. A possible solution is to keep the ceiling
 of the scaled ascent, and floor of the scaled descent.
 </li>

<li>
 There is no easy way to get the hinted glyph and advance widths of a
 range of glyphs, as hinting works differently on each outline. The
 only solution is to hint each glyph separately and record the
 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>

Performing 2D transformations on glyph outlines is very easy with
 FreeType. However, when using translation on a hinted outlines, one
 should aways take care of exclusively using integer pixel
 distances (which means that the parameters to the
 <tt>FT_Outline_Translate()</tt> API should all be multiples
 of&nbsp;64, as the point coordinates are in 26.6&nbsp;fixed float
 format).

Otherwise, the translation will simply ruin the hinter's
 work, resulting in a very low quality bitmaps!

<a name="section-5">
 <h3>
 5. Text widths and bounding box
 </h3>

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.

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.

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>

<hr>

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

</body>
</html>

Back to File Manager