major reformatting of the "Glyph Conventions" document.
It is now made of 7 different pages and has been updated
This commit is contained in:
David Turner
parent
f42e6595e6
commit
3574643bc0
Binary file not shown.
|
Before Width: | Height: | Size: 1.1 KiB After Width: | Height: | Size: 2.2 KiB |
169
docs/glyphs/glyphs-1.html
Normal file
169
docs/glyphs/glyphs-1.html
Normal file
@ -0,0 +1,169 @@
|
||||
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
|
||||
<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>
|
||||
</head>
|
||||
<body>
|
||||
|
||||
<body text="#000000"
|
||||
bgcolor="#FFFFFF"
|
||||
link="#0000EF"
|
||||
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%">
|
||||
|
||||
</td>
|
||||
<td align=center width="30%">
|
||||
<a href="index.html">Contents</a>
|
||||
</td>
|
||||
<td align=center width="30%">
|
||||
<a href="glyphs-2.html">Next</a>
|
||||
</td>
|
||||
</tr></table></center>
|
||||
|
||||
<table width="100%" cellpadding=5><tr bgcolor="#CCCCFF" valign=center><td>
|
||||
<h2>
|
||||
I. Basic typographic concepts
|
||||
</h2>
|
||||
</td></tr></table>
|
||||
|
||||
<a name="section-1"><h3>
|
||||
1. Font files, format and information
|
||||
</h3><blockquote>
|
||||
|
||||
<p>
|
||||
A font is a collection of various character images that can
|
||||
be used to display or print text. The images in a single font share some
|
||||
common properties, including look, style, serifs, etc.. Typographically
|
||||
speaking, one has to distinguish between a <b>font family</b> and its
|
||||
multiple <b>font faces</b>, which usually differ in style though come
|
||||
from the same template.</p>
|
||||
|
||||
For example, "<i>Palatino Regular</i>" and "<i>Palatino Italic</i>" are
|
||||
two distinct <i>faces</i> from the same famous <i>family</i>, called
|
||||
"<i>Palatino</i>" itself.</p>
|
||||
|
||||
<p>The single term font is nearly always used in ambiguous ways to refer
|
||||
to either a given family or given face, depending on the context. For example,
|
||||
most users of word-processors use "font" to describe a font family (e.g.
|
||||
Courier, Palatino, etc..); however most of these families are implemented
|
||||
through several data files depending on the file format : for TrueType,
|
||||
this is usually one per face (i.e. ARIAL.TFF for "Arial Regular", ARIALI.TTF
|
||||
for "Arial Italic", etc..). The file is also called a "font" but really
|
||||
contains a font face.
|
||||
</p>
|
||||
|
||||
<p>A <i>digital font</i> is thus a data file that may contain <i>one or
|
||||
more font faces</i>. For each of these, it contains character images,
|
||||
character metrics, as well as other kind of information important to the
|
||||
layout of text and the processing of specific character encodings. In some
|
||||
awkward formats, like Adobe Type1, a single font face is described through
|
||||
several files (i.e. one contains the character images, another one the
|
||||
character metrics). We will ignore this implementation issue in most of
|
||||
this document and consider digital fonts as single files, though FreeType
|
||||
2.0 is able to support multiple-files fonts correctly.
|
||||
</p>
|
||||
|
||||
<p>As a convenience, a font file containing more than one face is called
|
||||
a font collection. This case is rather rare but can be seen in many asian
|
||||
fonts, which contain images for two or more scripts for a given language.
|
||||
</p>
|
||||
|
||||
|
||||
|
||||
</blockquote><h3><a name="section-2">
|
||||
2. Character images and mappings :
|
||||
</h3><blockquote>
|
||||
|
||||
|
||||
|
||||
<p>The character images are called <b>glyphs</b>. A single character
|
||||
can have several distinct images, i.e. several glyphs, depending on script,
|
||||
usage or context. Several characters can also take a single glyph (good
|
||||
examples are roman ligatures like "oe" and "fi" which can be represented
|
||||
by a single glyph). The relationships between characters
|
||||
and glyphs can be a very complex one but won't be detailed in this document.
|
||||
Moreover, some formats use more or less awkward schemes to store and access
|
||||
the glyphs. For the sake of clarity, we'll only retain the following notions
|
||||
when working with FreeType :</p>
|
||||
|
||||
<ul>
|
||||
<p><li>
|
||||
A font file contains a set of glyphs, each one can be stored as a bitmap,
|
||||
a vector representation or any other scheme (e.g. most scalable formats
|
||||
use a combination of math representation and control data/programs). These
|
||||
glyphs can be stored in any order in the font file, and is typically accessed
|
||||
through a simple glyph index.
|
||||
</li></p>
|
||||
|
||||
<p><li>
|
||||
The font file contains one (or more) table, called a character map (or
|
||||
charmap in short), which is used to convert character codes for a given
|
||||
encoding (e.g. ASCII, Unicode, DBCS, Big5, etc..) into glyph indexes
|
||||
relative to the font file. A single font face may contain several charmaps.
|
||||
For example, most TrueType fonts contain an Apple-specific charmap as well
|
||||
as a Unicode charmap, which makes them usable on both Mac and Windows
|
||||
platforms.
|
||||
</li></p>
|
||||
</ul>
|
||||
|
||||
|
||||
|
||||
</blockquote><h3><a name="section-3">
|
||||
3. Character and font metrics :
|
||||
</h3><blockquote>
|
||||
|
||||
<p>Each glyph image is associated to various metrics which are used to
|
||||
describe the way it must be placed and managed when rendering text. Though
|
||||
they are described in more details in section III, they relate to glyph
|
||||
placement, cursor advances as well as text layouts. They are extremely
|
||||
important to compute the flow of text when rendering string of text.
|
||||
</p>
|
||||
|
||||
<p>Each scalable format also contains some global metrics, expressed in
|
||||
notional units, used to describe some properties of all glyphs in a same
|
||||
face. For example : the maximum glyph bounding box, the ascender, descender
|
||||
and text height for the font.
|
||||
</p>
|
||||
|
||||
<p>Though these metrics also exist for non-scalable formats, they only
|
||||
apply for a set of given character dimensions and resolutions, and they're
|
||||
usually expressed in pixels then.</p>
|
||||
|
||||
<center><table width="100%" border=0 cellpadding=5><tr bgcolor="#CCFFCC" valign=center>
|
||||
<td align=center width="30%">
|
||||
|
||||
</td>
|
||||
<td align=center width="30%">
|
||||
<a href="index.html">Contents</a>
|
||||
</td>
|
||||
<td align=center width="30%">
|
||||
<a href="glyphs-2.html">Next</a>
|
||||
</td>
|
||||
</tr></table></center>
|
||||
|
||||
</td></tr></table></center>
|
||||
|
||||
|
||||
</body>
|
||||
</html>
|
||||
367
docs/glyphs/glyphs-2.html
Normal file
367
docs/glyphs/glyphs-2.html
Normal file
@ -0,0 +1,367 @@
|
||||
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
|
||||
<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>
|
||||
</head>
|
||||
<body>
|
||||
|
||||
<body text="#000000"
|
||||
bgcolor="#FFFFFF"
|
||||
link="#0000EF"
|
||||
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>
|
||||
|
||||
<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>
|
||||
|
||||
<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 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 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>
|
||||
|
||||
<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>
|
||||
</body>
|
||||
</html>
|
||||
309
docs/glyphs/glyphs-3.html
Normal file
309
docs/glyphs/glyphs-3.html
Normal file
@ -0,0 +1,309 @@
|
||||
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
|
||||
<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>
|
||||
</head>
|
||||
<body>
|
||||
|
||||
<body text="#000000"
|
||||
bgcolor="#FFFFFF"
|
||||
link="#0000EF"
|
||||
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-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>
|
||||
|
||||
<table width="100%"><tr valign=center bgcolor="#ccccff"><td><h2>
|
||||
III. Glyph metrics
|
||||
</h2></td></tr></table>
|
||||
|
||||
<h3><a name="section-1">
|
||||
1. Baseline, Pens and Layouts
|
||||
</h3><blockquote>
|
||||
|
||||
<p>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.
|
||||
</p>
|
||||
|
||||
<p>Each layout uses a different convention for glyph placement:</p>
|
||||
<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.
|
||||
</li>
|
||||
|
||||
|
||||
<p>the distance between two successive pen positions is glyph-specific
|
||||
and is called the <b>advance width</b>. 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.
|
||||
</p>
|
||||
|
||||
<p>IMPORTANT NOTE: The pen position is always placed on the baseline.
|
||||
</p>
|
||||
|
||||
<p><center><img SRC="Image1.png" height=179 width=458></center></p>
|
||||
|
||||
|
||||
<li>with a vertical layout, glyphs are centered around the baseline:</li>
|
||||
|
||||
<p><center><img SRC="Image2.png" height=275 width=162></center></p>
|
||||
|
||||
</ul>
|
||||
|
||||
</blockquote><h3><a name="section-2">
|
||||
2. Typographic metrics and bounding boxes
|
||||
</h3><blockquote>
|
||||
|
||||
<p>A various number of face metrics are defined for all glyphs in a given
|
||||
font.</p>
|
||||
|
||||
<p><b>the ascent</b></p>
|
||||
<ul>
|
||||
<p>this is 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 axis upwards.
|
||||
</p>
|
||||
</ul>
|
||||
|
||||
<p><br><b>the descent</b></p>
|
||||
<ul><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>
|
||||
<ul>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></center>
|
||||
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">
|
||||
3. Bearings and Advances</h3>
|
||||
|
||||
<ul>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:
|
||||
<p><b>the left side bearing: a.k.a. bearingX</b>
|
||||
<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>
|
||||
<ul>this is 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</ul>
|
||||
|
||||
<p><br><b>the advance width: a.k.a. advanceX</b>
|
||||
<ul>is 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.</ul>
|
||||
|
||||
<p><br><b>the advance height: a.k.a. advanceY</b>
|
||||
<ul>is 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.</ul>
|
||||
|
||||
<p><br><b>the glyph width</b>
|
||||
<ul>this is simply the glyph's horizontal extent. More simply it is (bbox.xMax-bbox.xMin)
|
||||
for unscaled font coordinates. For scaled glyphs, its computation requests
|
||||
specific care, described in the grid-fitting chapter below.</ul>
|
||||
|
||||
<p><br><b>the glyph height</b>
|
||||
<ul>this is simply the glyph's vertical extent. More simply, it is (bbox.yMax-bbox.yMin)
|
||||
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>
|
||||
<ul>is 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.</ul>
|
||||
|
||||
<center><tt>advance_width - left_side_bearing - (xMax-xMin)</tt></center>
|
||||
|
||||
<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><img SRC="Image4.png" height=278 width=294></center>
|
||||
</ul>
|
||||
|
||||
<h3><a name="section-4">
|
||||
4. The effects of grid-fitting</h3>
|
||||
|
||||
<ul>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.
|
||||
<p>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.
|
||||
<p>The glyph metrics are also influenced by the grid-fitting process. Mainly
|
||||
because :
|
||||
<br>
|
||||
<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
|
||||
when the hinted bitmap is larger than the scaled one, to reflect the augmented
|
||||
glyph width.</li>
|
||||
</ul>
|
||||
|
||||
<p><br>Note also that :
|
||||
<br>
|
||||
<ul>
|
||||
<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>
|
||||
<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>
|
||||
</ul>
|
||||
|
||||
<ul>
|
||||
<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>
|
||||
<br>Performing 2D transforms on glyph outlines is very easy with FreeType.
|
||||
However, when using translation on a hinted outlines, one should aways
|
||||
take care of <b>exclusively using integer pixel distances</b> (which
|
||||
means that the parameters to the FT_Translate_Outline API should all be
|
||||
multiples of 64, as the point coordinates are in 26.6 fixed float format).
|
||||
<p><b>Otherwise</b>, the translation will simply <b>ruin the hinter's work</b>,
|
||||
resulting in a very low quality bitmaps.
|
||||
<br>
|
||||
<br> </ul>
|
||||
|
||||
<h3><a name="section-5">
|
||||
5. Text widths and bounding box :</h3>
|
||||
|
||||
<ul>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>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.
|
||||
<br>
|
||||
<p>The same conventions apply to strings of text. This means that :
|
||||
<br>
|
||||
<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>
|
||||
The string's advance width isn't related to its bounding box's dimensions.
|
||||
Especially if it contains beginning and terminal spaces or tabs.</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>
|
||||
<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>
|
||||
</html>
|
||||
178
docs/glyphs/glyphs-4.html
Normal file
178
docs/glyphs/glyphs-4.html
Normal file
@ -0,0 +1,178 @@
|
||||
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
|
||||
<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>
|
||||
</head>
|
||||
<body>
|
||||
|
||||
<body text="#000000"
|
||||
bgcolor="#FFFFFF"
|
||||
link="#0000EF"
|
||||
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-3.html">Previous</a>
|
||||
</td>
|
||||
<td align=center width="30%">
|
||||
<a href="index.html">Contents</a>
|
||||
</td>
|
||||
<td align=center width="30%">
|
||||
<a href="glyphs-5.html">Next</a>
|
||||
</td>
|
||||
</tr></table></center>
|
||||
|
||||
<table width="100%" cellpadding=5><tr bgcolor="#CCCCFF" valign=center><td>
|
||||
<h2>
|
||||
IV. Kerning
|
||||
</h2>
|
||||
</td></tr></table>
|
||||
|
||||
<p>The term 'kerning' refers to specific information used to adjust
|
||||
the relative positions of coincident glyphs in a string of text. This section
|
||||
describes several types of kerning information, as well as the way to process
|
||||
them when performing text layout.
|
||||
</p>
|
||||
|
||||
<h3><a name="section-1">
|
||||
1. Kerning pairs
|
||||
</h3><blockquote>
|
||||
|
||||
<p>Kerning consists in modifying the spacing between two successive
|
||||
glyphs according to their outlines. For example, a "T" and a "y" can be
|
||||
easily moved closer, as the top of the "y" fits nicely under the "T"'s
|
||||
upper right bar.
|
||||
</p>
|
||||
|
||||
<p>When laying out text with only their standard widths, some consecutive
|
||||
glyphs sometimes seem a bit too close or too distant. For example, the
|
||||
space between the 'A' and the 'V' in the following word seems a little
|
||||
wider than needed.
|
||||
<center>
|
||||
<p><img SRC="bravo_unkerned.png" height=37 width=116></center>
|
||||
|
||||
<p>Compare this to the same word, when the distance between these two letters
|
||||
has been slightly reduced :
|
||||
<center>
|
||||
<p><img SRC="bravo_kerned.png" height=37 width=107></center>
|
||||
|
||||
<p>As you can see, this adjustment can make a great difference. Some font
|
||||
faces thus include a table containing kerning distances for a set of given
|
||||
glyph pairs, used during text layout. Note that :
|
||||
<br>
|
||||
<blockquote>
|
||||
<ul>
|
||||
<li>
|
||||
The pairs are ordered, i.e. the space for pair (A,V) isn't necessarily
|
||||
the space for pair (V,A). They also index glyphs, and not characters.</li>
|
||||
</ul>
|
||||
|
||||
<ul>
|
||||
<li>
|
||||
Kerning distances can be expressed in horizontal or vertical directions,
|
||||
depending on layout and/or script. For example, some horizontal layouts
|
||||
like arabic can make use of vertical kerning adjustments between successive
|
||||
glyphs. A vertical script can have vertical kerning distances.</li>
|
||||
</ul>
|
||||
|
||||
<ul>
|
||||
<li>
|
||||
Kerning distances are expressed in grid units. They are usually oriented
|
||||
in the X axis, which means that a negative value indicates that two glyphs
|
||||
must be set closer in a horizontal layout.</li>
|
||||
</ul>
|
||||
</blockquote>
|
||||
</blockquote>
|
||||
|
||||
<h3><a name="section-2">
|
||||
2. Applying kerning</h3>
|
||||
|
||||
<blockquote>Applying kerning when rendering text is a rather easy process.
|
||||
It merely consists in adding the scaled kern distance to the pen position
|
||||
before writing each next glyph. However, the typographically correct renderer
|
||||
must take a few more details in consideration.
|
||||
<p>The "sliding dot" problem is a good example : many font faces include
|
||||
a kerning distance between capital letters like "T" or "F" and a following
|
||||
dot ("."), in order to slide the latter glyph just right to their main
|
||||
leg. I.e.
|
||||
<center>
|
||||
<p><img SRC="twlewis1.png" height=38 width=314></center>
|
||||
|
||||
<p>However, this sometimes requires additional adjustments between the
|
||||
dot and the letter following it, depending on the shapes of the enclosing
|
||||
letters. When applying "standard" kerning adjustments, the previous sentence
|
||||
would become :
|
||||
<center>
|
||||
<p><img SRC="twlewis2.png" height=36 width=115></center>
|
||||
|
||||
<p>Which clearly is too contracted. The solution here, as exhibited in
|
||||
the first example is to only slide the dots when possible. Of course, this
|
||||
requires a certain knowledge of the text's meaning. The above adjustments
|
||||
would not necessarily be welcomed if we were rendering the final dot of
|
||||
a given paragraph.
|
||||
<p>This is only one example, and there are many others showing that a real
|
||||
typographer is needed to layout text properly. If not available, some kind
|
||||
of user interaction or tagging of the text could be used to specify some
|
||||
adjustments, but in all cases, this requires some support in applications
|
||||
and text libraries.
|
||||
<p>For more mundane and common uses, however, we can have a very simple
|
||||
algorithm, which avoids the sliding dot problem, and others, though
|
||||
not producing optimal results. It can be seen as :
|
||||
<br>
|
||||
<blockquote>
|
||||
<ol>
|
||||
<li>
|
||||
place the first glyph on the baseline</li>
|
||||
|
||||
<li>
|
||||
save the location of the pen position/origin in pen1</li>
|
||||
|
||||
<li>
|
||||
adjust the pen position with the kerning distance between the first and
|
||||
second glyph</li>
|
||||
|
||||
<li>
|
||||
place the second glyph and compute the next pen position/origin in pen2.</li>
|
||||
|
||||
<li>
|
||||
use pen1 as the next pen position if it is beyond pen2, use pen2 otherwise.</li>
|
||||
</ol>
|
||||
</blockquote>
|
||||
</blockquote>
|
||||
</blockquote>
|
||||
|
||||
<center><table width="100%" border=0 cellpadding=5><tr bgcolor="#CCFFCC" valign=center>
|
||||
<td align=center width="30%">
|
||||
<a href="glyphs-3.html">Previous</a>
|
||||
</td>
|
||||
<td align=center width="30%">
|
||||
<a href="index.html">Contents</a>
|
||||
</td>
|
||||
<td align=center width="30%">
|
||||
<a href="glyphs-5.html">Next</a>
|
||||
</td>
|
||||
</tr></table></center>
|
||||
|
||||
</td></tr></table></center>
|
||||
|
||||
</body>
|
||||
</html>
|
||||
275
docs/glyphs/glyphs-5.html
Normal file
275
docs/glyphs/glyphs-5.html
Normal file
@ -0,0 +1,275 @@
|
||||
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
|
||||
<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>
|
||||
</head>
|
||||
<body>
|
||||
|
||||
<body text="#000000"
|
||||
bgcolor="#FFFFFF"
|
||||
link="#0000EF"
|
||||
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-4.html">Previous</a>
|
||||
</td>
|
||||
<td align=center width="30%">
|
||||
<a href="index.html">Contents</a>
|
||||
</td>
|
||||
<td align=center width="30%">
|
||||
<a href="glyphs-6.html">Next</a>
|
||||
</td>
|
||||
</tr></table></center>
|
||||
|
||||
<table width="100%"><tr valign=center bgcolor="#CCCCFF"><td><h2>
|
||||
V. Text processing
|
||||
</h2></td></tr></table>
|
||||
|
||||
<p>This section demonstrates how to use the concepts previously
|
||||
defined to render text, whatever the layout you use.
|
||||
</p>
|
||||
|
||||
|
||||
<h3><a name="section-1">
|
||||
1. Writing simple text strings :
|
||||
</h3><blockquote>
|
||||
|
||||
<p>In this first example, we'll generate a simple string of Roman
|
||||
text, i.e. with a horizontal left-to-right layout. Using exclusively pixel
|
||||
metrics, the process looks like :
|
||||
<blockquote><tt>1) convert the character string into a series of glyph
|
||||
indexes.</tt>
|
||||
<br><tt>2) place the pen to the cursor position.</tt>
|
||||
<br><tt>3) get or load the glyph image.</tt>
|
||||
<br><tt>4) translate the glyph so that its 'origin' matches the pen position</tt>
|
||||
<br><tt>5) render the glyph to the target device</tt>
|
||||
<br><tt>6) increment the pen position by the glyph's advance width in pixels</tt>
|
||||
<br><tt>7) start over at step 3 for each of the remaining glyphs</tt>
|
||||
<br><tt>8) when all glyphs are done, set the text cursor to the new pen
|
||||
position</tt></blockquote>
|
||||
Note that kerning isn't part of this algorithm.</blockquote>
|
||||
|
||||
<h3><a name="section-2">
|
||||
2. Sub-pixel positioning :</h3>
|
||||
|
||||
<blockquote>It is somewhat useful to use sub-pixel positioning when rendering
|
||||
text. This is crucial, for example, to provide semi-WYSIWYG text layouts.
|
||||
Text rendering is very similar to the algorithm described in sub-section
|
||||
1, with the following few differences :
|
||||
<ul>
|
||||
<li>
|
||||
The pen position is expressed in fractional pixels.</li>
|
||||
|
||||
<li>
|
||||
Because translating a hinted outline by a non-integer distance will ruin
|
||||
its grid-fitting, the position of the glyph origin must be rounded before
|
||||
rendering the character image.</li>
|
||||
|
||||
<li>
|
||||
The advance width is expressed in fractional pixels, and isn't necessarily
|
||||
an integer.</li>
|
||||
</ul>
|
||||
|
||||
<p><br>Which finally looks like :
|
||||
<blockquote><tt>1. convert the character string into a series of glyph
|
||||
indexes.</tt>
|
||||
<br><tt>2. place the pen to the cursor position. This can be a non-integer
|
||||
point.</tt>
|
||||
<br><tt>3. get or load the glyph image.</tt>
|
||||
<br><tt>4. translate the glyph so that its 'origin' matches the rounded
|
||||
pen position.</tt>
|
||||
<br><tt>5. render the glyph to the target device</tt>
|
||||
<br><tt>6. increment the pen position by the glyph's advance width in fractional
|
||||
pixels.</tt>
|
||||
<br><tt>7. start over at step 3 for each of the remaining glyphs</tt>
|
||||
<br><tt>8. when all glyphs are done, set the text cursor to the new pen
|
||||
position</tt></blockquote>
|
||||
Note that with fractional pixel positioning, the space between two given
|
||||
letters isn't fixed, but determined by the accumulation of previous rounding
|
||||
errors in glyph positioning.</blockquote>
|
||||
|
||||
<h3><a name="section-3">
|
||||
3. Simple kerning :</h3>
|
||||
|
||||
<blockquote>Adding kerning to the basic text rendering algorithm is easy
|
||||
: when a kerning pair is found, simply add the scaled kerning distance
|
||||
to the pen position before step 4. Of course, the distance should be rounded
|
||||
in the case of algorithm 1, though it doesn't need to for algorithm 2.
|
||||
This gives us :
|
||||
<p>Algorithm 1 with kerning:
|
||||
<blockquote><tt>3) get or load the glyph image.</tt>
|
||||
<br><tt>4) Add the rounded scaled kerning distance, if any, to the pen
|
||||
position</tt>
|
||||
<br><tt>5) translate the glyph so that its 'origin' matches the pen position</tt>
|
||||
<br><tt>6) render the glyph to the target device</tt>
|
||||
<br><tt>7) increment the pen position by the glyph's advance width in pixels</tt>
|
||||
<br><tt>8) start over at step 3 for each of the remaining glyphs</tt></blockquote>
|
||||
|
||||
<p><br>Algorithm 2 with kerning:
|
||||
<blockquote><tt>3) get or load the glyph image.</tt>
|
||||
<br><tt>4) Add the scaled unrounded kerning distance, if any, to the pen
|
||||
position.</tt>
|
||||
<br><tt>5) translate the glyph so that its 'origin' matches the rounded
|
||||
pen position.</tt>
|
||||
<br><tt>6) render the glyph to the target device</tt>
|
||||
<br><tt>7) increment the pen position by the glyph's advance width in fractional
|
||||
pixels.</tt>
|
||||
<br><tt>8) start over at step 3 for each of the remaining glyphs</tt></blockquote>
|
||||
Of course, the algorithm described in section IV can also be applied to
|
||||
prevent the sliding dot problem if one wants to..</blockquote>
|
||||
|
||||
<h3><a name="section-4">
|
||||
4. Right-To-Left Layout :</h3>
|
||||
|
||||
<blockquote>The process of laying out arabic or hebrew text is extremely
|
||||
similar. The only difference is that the pen position must be decremented
|
||||
before the glyph rendering (remember : the advance width is always positive,
|
||||
even for arabic glyphs). Thus, algorithm 1 becomes :
|
||||
<p>Right-to-left Algorithm 1:
|
||||
<blockquote><tt>3) get or load the glyph image.</tt>
|
||||
<br><tt>4) Decrement the pen position by the glyph's advance width in pixels</tt>
|
||||
<br><tt>5) translate the glyph so that its 'origin' matches the pen position</tt>
|
||||
<br><tt>6) render the glyph to the target device</tt>
|
||||
<br><tt>7) start over at step 3 for each of the remaining glyphs</tt></blockquote>
|
||||
|
||||
<p><br>The changes to Algorithm 2, as well as the inclusion of kerning
|
||||
are left as an exercise to the reader.
|
||||
<br>
|
||||
<br> </blockquote>
|
||||
|
||||
<h3><a name="section-5">
|
||||
5. Vertical layouts :</h3>
|
||||
|
||||
<blockquote>Laying out vertical text uses exactly the same processes, with
|
||||
the following significant differences :
|
||||
<br>
|
||||
<blockquote>
|
||||
<li>
|
||||
The baseline is vertical, and the vertical metrics must be used instead
|
||||
of the horizontal one.</li>
|
||||
|
||||
<li>
|
||||
The left bearing is usually negative, but this doesn't change the fact
|
||||
that the glyph origin must be located on the baseline.</li>
|
||||
|
||||
<li>
|
||||
The advance height is always positive, so the pen position must be decremented
|
||||
if one wants to write top to bottom (assuming the Y axis is oriented upwards).</li>
|
||||
</blockquote>
|
||||
Through the following algorithm :
|
||||
<blockquote><tt>1) convert the character string into a series of glyph
|
||||
indexes.</tt>
|
||||
<br><tt>2) place the pen to the cursor position.</tt>
|
||||
<br><tt>3) get or load the glyph image.</tt>
|
||||
<br><tt>4) translate the glyph so that its 'origin' matches the pen position</tt>
|
||||
<br><tt>5) render the glyph to the target device</tt>
|
||||
<br><tt>6) decrement the vertical pen position by the glyph's advance height
|
||||
in pixels</tt>
|
||||
<br><tt>7) start over at step 3 for each of the remaining glyphs</tt>
|
||||
<br><tt>8) when all glyphs are done, set the text cursor to the new pen
|
||||
position</tt></blockquote>
|
||||
</blockquote>
|
||||
|
||||
<h3><a name="section-6">
|
||||
6. WYSIWYG text layouts :</h3>
|
||||
|
||||
<blockquote>As you probably know, the acronym WYSIWYG stands for '<i>What
|
||||
You See Is What You Get</i>'. Basically, this means that the output of
|
||||
a document on the screen should match "perfectly" its printed version.
|
||||
A <b><i>true</i></b> wysiwyg system requires two things :
|
||||
<p><b>device-independent text layout</b>
|
||||
<blockquote>Which means that the document's formatting is the same on the
|
||||
screen than on any printed output, including line breaks, justification,
|
||||
ligatures, fonts, position of inline images, etc..</blockquote>
|
||||
|
||||
<p><br><b>matching display and print character sizes</b>
|
||||
<blockquote>Which means that the displayed size of a given character should
|
||||
match its dimensions when printed. For example, a text string which is
|
||||
exactly 1 inch tall when printed should also appear 1 inch tall on the
|
||||
screen (when using a scale of 100%).</blockquote>
|
||||
|
||||
<p><br>It is clear that matching sizes cannot be possible if the computer
|
||||
has no knowledge of the physical resolutions of the display device(s) it
|
||||
is using. And of course, this is the most common case ! That's not too
|
||||
unfortunate, however because most users really don't care about this
|
||||
feature. Legibility is much more important.
|
||||
<p>When the Mac appeared, Apple decided to choose a resolution of 72 dpi
|
||||
to describe the Macintosh screen to the font sub-system (whatever the monitor
|
||||
used). This choice was most probably driven by the fact that, at this resolution,
|
||||
1 point = 1 pixel. However; it neglected one crucial fact : as most users
|
||||
tend to choose a document character size between 10 and 14 points, the
|
||||
resultant displayed text was rather small and not too legible without scaling.
|
||||
Microsoft engineers took notice of this problem and chose a resolution
|
||||
of 96 dpi on Windows, which resulted in slightly larger, and more legible,
|
||||
displayed characters (for the same printed text size).
|
||||
<p>These distinct resolutions explain some differences when displaying
|
||||
text at the same character size on a Mac and a Windows machine. Moreover,
|
||||
it is not unusual to find some TrueType fonts with enhanced hinting (tech
|
||||
note: through delta-hinting) for the sizes of 10, 12, 14 and 16 points
|
||||
at 96 dpi.
|
||||
<br>
|
||||
<p>As for device-independent text, it is a notion that is, unfortunately,
|
||||
often abused. For example, many word processors, including MS Word, do
|
||||
not really use device-independent glyph positioning algorithms when laying
|
||||
out text. Rather, they use the target printer's resolution to compute <i>hinted</i>
|
||||
glyph metrics for the layout. Though it guarantees that the printed version
|
||||
is always the "nicest" it can be, especially for very low resolution printers
|
||||
(like dot-matrix), it has a very sad effect : changing the printer can
|
||||
have dramatic effects on the <i>whole</i> document layout, especially if
|
||||
it makes strong use of justification, uses few page breaks, etc..
|
||||
<p>Because the glyph metrics vary slightly when the resolution changes
|
||||
(due to hinting), line breaks can change enormously, when these differences
|
||||
accumulate over long runs of text. Try for example printing a very long
|
||||
document (with no page breaks) on a 300 dpi ink-jet printer, then the same
|
||||
one on a 3000 dpi laser printer : you'll be extremely lucky if your final
|
||||
page count didn't change between the prints ! Of course, we can still call
|
||||
this WYSIWYG, as long as the printer resolution is fixed !!
|
||||
<p>Some applications, like Adobe Acrobat, which targeted device-independent
|
||||
placement from the start, do not suffer from this problem. There are two
|
||||
ways to achieve this : either use the scaled and unhinted glyph metrics
|
||||
when laying out text both in the rendering and printing processes, or simply
|
||||
use wathever metrics you want and store them with the text in order to
|
||||
get sure they're printed the same on all devices (the latter being probably
|
||||
the best solution, as it also enables font substitution without breaking
|
||||
text layouts).
|
||||
<p>Just like matching sizes, device-independent placement isn't necessarily
|
||||
a feature that most users want. However, it is pretty clear that for any
|
||||
kind of professional document processing work, it <b><i>is</i></b> a requirement.</blockquote>
|
||||
</blockquote>
|
||||
|
||||
<center><table width="100%" border=0 cellpadding=5><tr bgcolor="#CCFFCC" valign=center>
|
||||
<td align=center width="30%">
|
||||
<a href="glyphs-4.html">Previous</a>
|
||||
</td>
|
||||
<td align=center width="30%">
|
||||
<a href="index.html">Contents</a>
|
||||
</td>
|
||||
<td align=center width="30%">
|
||||
<a href="glyphs-6.html">Next</a>
|
||||
</td>
|
||||
</tr></table></center>
|
||||
|
||||
</td></tr></table></center>
|
||||
|
||||
</body>
|
||||
</html>
|
||||
377
docs/glyphs/glyphs-6.html
Normal file
377
docs/glyphs/glyphs-6.html
Normal file
@ -0,0 +1,377 @@
|
||||
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
|
||||
<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>
|
||||
</head>
|
||||
<body>
|
||||
|
||||
<body text="#000000"
|
||||
bgcolor="#FFFFFF"
|
||||
link="#0000EF"
|
||||
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-5.html">Previous</a>
|
||||
</td>
|
||||
<td align=center width="30%">
|
||||
<a href="index.html">Contents</a>
|
||||
</td>
|
||||
<td align=center width="30%">
|
||||
<a href="glyphs-7.html">Next</a>
|
||||
</td>
|
||||
</tr></table></center>
|
||||
|
||||
|
||||
<table width="100%"><tr valign=center bgcolor="#CCCCFF"><td><h2>
|
||||
VI. FreeType Outlines
|
||||
</h2></td></tr></table>
|
||||
|
||||
<p>The purpose of this section is to present the way FreeType
|
||||
manages vectorial outlines, as well as the most common operations that
|
||||
can be applied on them.
|
||||
</p>
|
||||
|
||||
<h3><a name="section-1">
|
||||
1. FreeType outline description and structure :
|
||||
</h3><blockquote>
|
||||
|
||||
<h4>
|
||||
a. Outline curve decomposition :
|
||||
</h4>
|
||||
|
||||
<p>An outline is described as a series of closed contours in the
|
||||
2D plane. Each contour is made of a series of line segments and bezier
|
||||
arcs. Depending on the file format, these can be second-order or third-order
|
||||
polynomials. The former are also called quadratic or conic arcs, and they
|
||||
come from the TrueType format. The latter are called cubic arcs and mostly
|
||||
come from the Type1 format.
|
||||
</p>
|
||||
|
||||
<p>Each arc is described through a series of start, end and control points.
|
||||
Each point of the outline has a specific tag which indicates wether it
|
||||
is used to describe a line segment or an arc. The tags can take the
|
||||
following values :
|
||||
</p>
|
||||
|
||||
<center><table CELLSPACING=5 CELLPADDING=5 WIDTH="80%">
|
||||
<tr VALIGN=TOP><td>
|
||||
<p><b>FT_Curve_Tag_On </b></p>
|
||||
</td>
|
||||
|
||||
<td VALIGN=TOP>
|
||||
<p>Used when the point is "on" the curve. This corresponds to
|
||||
start and end points of segments and arcs. The other tags specify what
|
||||
is called an "off" point, i.e. one which isn't located on the contour itself,
|
||||
but serves as a control point for a bezier arc.</p>
|
||||
</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td>
|
||||
<p><b>FT_Curve_Tag_Conic</b></p>
|
||||
</td>
|
||||
|
||||
<td>
|
||||
<p>Used for an "off" point used to control a conic bezier arc.</p>
|
||||
</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td>
|
||||
<p><b>FT_Curve_Tag_Cubic</b></p>
|
||||
</td>
|
||||
|
||||
<td>
|
||||
<p>Used for an "off" point used to control a cubic bezier arc.</p>
|
||||
</td>
|
||||
</tr>
|
||||
</table></center>
|
||||
|
||||
|
||||
<p>The following rules are applied to decompose the contour's points into
|
||||
segments and arcs :
|
||||
</p>
|
||||
|
||||
<ul>
|
||||
<li>two successive "on" points indicate a line segment joining them.</li>
|
||||
|
||||
<li>one conic "off" point amidst two "on" points indicates a conic bezier
|
||||
arc, the "off" point being the control point, and the "on" ones the
|
||||
start and end points.</li>
|
||||
|
||||
<li>
|
||||
Two successive cubic "off" points amidst two "on" points indicate a cubic
|
||||
bezier arc. There must be exactly two cubic control points and two on
|
||||
points for each cubic arc (using a single cubic "off" point between two
|
||||
"on" points is forbidden, for example).
|
||||
</li>
|
||||
|
||||
<li>
|
||||
finally, two successive conic "off" points forces the rasterizer to create
|
||||
(during the scan-line conversion process exclusively) a virtual "on" point
|
||||
amidst them, at their exact middle. This greatly facilitates the definition
|
||||
of successive conic bezier arcs. Moreover, it's the way outlines are
|
||||
described in the TrueType specification.
|
||||
</li>
|
||||
</ul>
|
||||
|
||||
<p><br>Note that it is possible to mix conic and cubic arcs in a single
|
||||
contour, even though no current font driver produces such outlines.
|
||||
<br> </ul>
|
||||
|
||||
<center><table>
|
||||
<tr>
|
||||
<td>
|
||||
<blockquote><img SRC="points_segment.png" height=166 width=221></blockquote>
|
||||
</td>
|
||||
|
||||
<td>
|
||||
<blockquote><img SRC="points_conic.png" height=183 width=236></blockquote>
|
||||
</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td>
|
||||
<blockquote><img SRC="points_cubic.png" height=162 width=214></blockquote>
|
||||
</td>
|
||||
|
||||
<td>
|
||||
<blockquote><img SRC="points_conic2.png" height=204 width=225></blockquote>
|
||||
</td>
|
||||
</tr>
|
||||
</table></center>
|
||||
|
||||
<h4>
|
||||
b. Outline descriptor :</h4>
|
||||
|
||||
<p>A FreeType outline is described through a simple structure,
|
||||
called <tt>FT_Outline</tt>, which fields are :</p>
|
||||
|
||||
<center><table CELLSPACING=3 CELLPADDING=3 BGCOLOR="#CCCCCC">
|
||||
<tr>
|
||||
<td>
|
||||
<p><b><tt>n_points</tt></b></p>
|
||||
</td>
|
||||
|
||||
<td>
|
||||
<p>the number of points in the outline</p>
|
||||
</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td>
|
||||
<p><b><tt>n_contours</tt></b></p>
|
||||
</td>
|
||||
|
||||
<td>
|
||||
<p>the number of contours in the outline</p>
|
||||
</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td>
|
||||
<p><b><tt>points</tt></b></p>
|
||||
</td>
|
||||
|
||||
<td>
|
||||
<p>array of point coordinates</p>
|
||||
</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td>
|
||||
<p><b><tt>contours</tt></b></p>
|
||||
</td>
|
||||
|
||||
<td>
|
||||
<p>array of contour end indices</p>
|
||||
</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td>
|
||||
<p><b><tt>tags</tt></b></p>
|
||||
</td>
|
||||
|
||||
<td>
|
||||
<p>array of point flags</p>
|
||||
</td>
|
||||
</tr>
|
||||
</table></center>
|
||||
|
||||
<p>Here, <b><tt>points</tt></b> is a pointer to an array of
|
||||
<tt>FT_Vector</tt> records, used to store the vectorial coordinates of each
|
||||
outline point. These are expressed in 1/64th of a pixel, which is also
|
||||
known as the <i>26.6 fixed float format</i>.
|
||||
</p>
|
||||
|
||||
<p><b><tt>contours</tt></b> is an array of point indices used to delimit
|
||||
contours in the outline. For example, the first contour always starts at
|
||||
point 0, and ends a point <b><tt>contours[0]</tt></b>. The second contour
|
||||
starts at point "<b><tt>contours[0]+1</tt></b>" and ends at
|
||||
<b><tt>contours[1]</tt></b>, etc..
|
||||
</p>
|
||||
|
||||
<p>Note that each contour is closed, and that <b><tt>n_points</tt></b>
|
||||
should be equal to "<b><tt>contours[n_contours-1]+1</tt></b>" for a valid
|
||||
outline.
|
||||
</p>
|
||||
|
||||
<p>Finally, <b><tt>tags</tt></b> is an array of bytes, used to store each
|
||||
outline point's tag.
|
||||
</p>
|
||||
|
||||
|
||||
</blockquote><h3><a name="section-2">
|
||||
2. Bounding and control box computations :
|
||||
</h3><blockquote>
|
||||
|
||||
<p>A <b>bounding box</b> (also called "<b>bbox</b>") is simply
|
||||
the smallest possible rectangle that encloses the shape of a given outline.
|
||||
Because of the way arcs are defined, bezier control points are not
|
||||
necessarily contained within an outline's bounding box.
|
||||
</p>
|
||||
|
||||
<p>This situation happens when one bezier arc is, for example, the upper
|
||||
edge of an outline and an off point happens to be above the bbox. However,
|
||||
it is very rare in the case of character outlines because most font designers
|
||||
and creation tools always place on points at the extrema of each curved
|
||||
edges, as it makes hinting much easier.
|
||||
</p>
|
||||
|
||||
<p>We thus define the <b>control box</b> (a.k.a. the "<b>cbox</b>") as
|
||||
the smallest possible rectangle that encloses all points of a given outline
|
||||
(including its off points). Clearly, it always includes the bbox, and equates
|
||||
it in most cases.
|
||||
</p>
|
||||
|
||||
<p>Unlike the bbox, the cbox is also much faster to compute.</p>
|
||||
|
||||
<center><table>
|
||||
<tr>
|
||||
<td><img SRC="bbox1.png" height=264 width=228></td>
|
||||
|
||||
<td><img SRC="bbox2.png" height=229 width=217></td>
|
||||
</tr>
|
||||
</table></center>
|
||||
|
||||
<p>Control and bounding boxes can be computed automatically through the
|
||||
functions <b><tt>FT_Get_Outline_CBox</tt></b> and <b><tt>FT_Get_Outline_BBox</tt></b>.
|
||||
The former function is always very fast, while the latter <i>may</i> be
|
||||
slow in the case of "outside" control points (as it needs to find the extreme
|
||||
of conic and cubic arcs for "perfect" computations). If this isn't the
|
||||
case, it's as fast as computing the control box.
|
||||
<p>Note also that even though most glyph outlines have equal cbox and bbox
|
||||
to ease hinting, this is not necessary the case anymore when a
|
||||
transform like rotation is applied to them.
|
||||
</p>
|
||||
|
||||
</blockquote><h3><a name="section-3">
|
||||
3. Coordinates, scaling and grid-fitting :
|
||||
</h3><blockquote>
|
||||
|
||||
<p>An outline point's vectorial coordinates are expressed in the
|
||||
26.6 format, i.e. in 1/64th of a pixel, hence coordinates (1.0, -2.5) is
|
||||
stored as the integer pair ( x:64, y: -192 ).
|
||||
</p>
|
||||
|
||||
<p>After a master glyph outline is scaled from the EM grid to the current
|
||||
character dimensions, the hinter or grid-fitter is in charge of aligning
|
||||
important outline points (mainly edge delimiters) to the pixel grid. Even
|
||||
though this process is much too complex to be described in a few lines,
|
||||
its purpose is mainly to round point positions, while trying to preserve
|
||||
important properties like widths, stems, etc..
|
||||
</p>
|
||||
|
||||
<p>The following operations can be used to round vectorial distances in
|
||||
the 26.6 format to the grid :
|
||||
</p>
|
||||
|
||||
<center>
|
||||
<p><tt>round(x) == (x+32) & -64</tt>
|
||||
<br><tt>floor(x) == x &
|
||||
-64</tt>
|
||||
<br><tt>ceiling(x) == (x+63) & -64</tt></center>
|
||||
|
||||
<p>Once a glyph outline is grid-fitted or transformed, it often is interesting
|
||||
to compute the glyph image's pixel dimensions before rendering it. To do
|
||||
so, one has to consider the following :
|
||||
<p>The scan-line converter draws all the pixels whose <i>centers</i> fall
|
||||
inside the glyph shape. It can also detect "<b><i>drop-outs</i></b>", i.e.
|
||||
discontinuities coming from extremely thin shape fragments, in order to
|
||||
draw the "missing" pixels. These new pixels are always located at a distance
|
||||
less than half of a pixel but one cannot predict easily where they'll appear
|
||||
before rendering.
|
||||
<p>This leads to the following computations :
|
||||
<br>
|
||||
<ul>
|
||||
<li>
|
||||
compute the bbox</li>
|
||||
</ul>
|
||||
|
||||
<ul>
|
||||
<li>
|
||||
grid-fit the bounding box with the following :</li>
|
||||
</ul>
|
||||
|
||||
<ul><p>
|
||||
<ul><tt>xmin = floor( bbox.xMin )</tt>
|
||||
<br><tt>xmax = ceiling( bbox.xMax )</tt>
|
||||
<br><tt>ymin = floor( bbox.yMin )</tt>
|
||||
<br><tt>ymax = ceiling( bbox.yMax )</tt>
|
||||
</p></ul>
|
||||
|
||||
<li>
|
||||
return pixel dimensions, i.e.
|
||||
<tt>width = (xmax - xmin)/64</tt> and <tt>height = (ymax - ymin)/64</tt>
|
||||
</li>
|
||||
</ul>
|
||||
|
||||
<p><br>By grid-fitting the bounding box, one guarantees that all the pixel
|
||||
centers that are to be drawn, <b><i>including those coming from drop-out
|
||||
control</i></b>, will be <b><i>within</i></b> the adjusted box. Then the
|
||||
box's dimensions in pixels can be computed.
|
||||
<p>Note also that, when <i>translating</i> a <i>grid-fitted outline</i>,
|
||||
one should <b><i>always</i></b> use <b><i>integer distances</i></b> to
|
||||
move an outline in the 2D plane. Otherwise, glyph edges won't be aligned
|
||||
on the pixel grid anymore, and the hinter's work will be lost, producing
|
||||
<b><i>very
|
||||
low quality </i></b>bitmaps and pixmaps..</blockquote>
|
||||
</blockquote>
|
||||
|
||||
<center><table width="100%" border=0 cellpadding=5><tr bgcolor="#CCFFCC" valign=center>
|
||||
<td align=center width="30%">
|
||||
<a href="glyphs-5.html">Previous</a>
|
||||
</td>
|
||||
<td align=center width="30%">
|
||||
<a href="index.html">Contents</a>
|
||||
</td>
|
||||
<td align=center width="30%">
|
||||
<a href="glyphs-7.html">Next</a>
|
||||
</td>
|
||||
</tr></table></center>
|
||||
|
||||
</td></tr></table></center>
|
||||
|
||||
</body>
|
||||
</html>
|
||||
291
docs/glyphs/glyphs-7.html
Normal file
291
docs/glyphs/glyphs-7.html
Normal file
@ -0,0 +1,291 @@
|
||||
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
|
||||
<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>
|
||||
</head>
|
||||
<body>
|
||||
|
||||
<body text="#000000"
|
||||
bgcolor="#FFFFFF"
|
||||
link="#0000EF"
|
||||
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-6.html">Previous</a>
|
||||
</td>
|
||||
<td align=center width="30%">
|
||||
<a href="index.html">Contents</a>
|
||||
</td>
|
||||
<td align=center width="30%">
|
||||
|
||||
</td>
|
||||
</tr></table></center>
|
||||
|
||||
|
||||
<table width="100%"><tr valign=center bgcolor="#CCCCFF"><td><h2>
|
||||
VII. FreeType Bitmaps
|
||||
</h2></td></tr></table>
|
||||
|
||||
|
||||
<p>The purpose of this section is to present the way FreeType
|
||||
manages bitmaps and pixmaps, and how they relate to the concepts previously
|
||||
defined. The relationships between vectorial and pixel coordinates is
|
||||
explained.
|
||||
</p>
|
||||
|
||||
<h3><a name="section-1">
|
||||
1. Vectorial versus pixel coordinates :
|
||||
</h3><blockquote>
|
||||
|
||||
<p>This sub-section explains the differences between vectorial
|
||||
and pixel coordinates. To make things clear, brackets will be used to describe
|
||||
pixel coordinates, e.g. [3,5], while parentheses will be used for vectorial
|
||||
ones, e.g. (-2,3.5).
|
||||
<p>In the pixel case, as we use the <i>Y upwards</i> convention, the coordinate
|
||||
[0,0] always refers to the <i>lower left pixel</i> of a bitmap, while coordinate
|
||||
[width-1, rows-1] to its <i>upper right pixel</i>.
|
||||
<p>In the vectorial case, point coordinates are expressed in floating units,
|
||||
like (1.25, -2.3). Such a position doesn't refer to a given pixel, but
|
||||
simply to an immaterial point in the 2D plane
|
||||
<p>The pixels themselves are indeed <i>square boxes</i> of the 2D plane,
|
||||
which centers lie in half pixel coordinates. For example, the <i>lower
|
||||
left pixel</i> of a bitmap is delimited by the <i>square</i> (0,0)-(1,1),
|
||||
its center being at location (0.5,0.5).
|
||||
<p>This introduces some differences when computing distances. For example,
|
||||
the "<i>length</i>" in pixels of the line [0,0]-[10,0] is 11. However,
|
||||
the vectorial distance between (0,0)-(10,0) covers exactly 10 pixel centers,
|
||||
hence its length if 10.
|
||||
<center><img SRC="grid_1.png" height=390 width=402></center>
|
||||
|
||||
|
||||
</blockquote><h3><a name="section-2">
|
||||
2. FreeType bitmap and pixmap descriptor :
|
||||
</h3><blockquote>
|
||||
|
||||
<p>A bitmap or pixmap is described through a single structure,
|
||||
called <tt>FT_Bitmap</tt>, defined in the file
|
||||
<tt><freetype/ftimage.h></tt>. It is a simple descriptor whose fields are:</p>
|
||||
|
||||
<center><table CELLSPACING=3 CELLPADDING=5 BGCOLOR="#CCCCCC" width="80%" >
|
||||
<caption><tt>FT_Bitmap</tt></caption>
|
||||
|
||||
<tr>
|
||||
<td><b>rows</b></td>
|
||||
|
||||
<td>the number of rows, i.e. lines, in the bitmap</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td><b>width</b></td>
|
||||
|
||||
<td>the number of horizontal pixels in the bitmap</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td><b>pitch</b></td>
|
||||
|
||||
<td>its absolute value is the number of bytes per bitmap line.
|
||||
it can be either positive or negative depending on the bitmap's
|
||||
vertical orientation</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td><b>buffer</b></td>
|
||||
|
||||
<td>a typeless pointer to the bitmap pixel bufer</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td><b>pixel_mode</b></td>
|
||||
|
||||
<td>an enumeration used to describe the pixel format of the bitmap.
|
||||
Examples are: <tt>ft_pixel_mode_mono</tt> for 1-bit monochrome bitmaps
|
||||
and <tt>ft_pixel_mode_grays</tt> for 8-bit anti-aliased "gray" values
|
||||
</td>
|
||||
|
||||
<tr>
|
||||
<td><b>num_grays</b></td>
|
||||
|
||||
<td>this is only used for "gray" pixel modes, it gives the
|
||||
number of gray levels used to describe the anti-aliased gray levels.
|
||||
256 by default with FreeType 2.
|
||||
</td>
|
||||
</tr>
|
||||
|
||||
</table></center>
|
||||
|
||||
|
||||
<p>Note that the sign of the <b><tt>pitch</tt></b> fields determines wether
|
||||
the rows in the pixel buffer are stored in ascending or descending order.
|
||||
</p>
|
||||
|
||||
<p>Remember that FreeType uses the <i>Y upwards</i> convention in the 2D
|
||||
plane. Which means that a coordinate of (0,0) always refer to the
|
||||
<i>lower-left corner</i> of a bitmap.
|
||||
</p>
|
||||
|
||||
<p>When the pitch is positive, the rows are stored in decreasing vertical
|
||||
position, which means that the first bytes of the pixel buffer are part
|
||||
of the <i>upper</i> bitmap row.
|
||||
</p>
|
||||
|
||||
<p>On the opposite, when the pitch is negative, the first bytes of the
|
||||
pixel buffer are part of the <i>lower</i> bitmap row.</p>
|
||||
|
||||
<p>In all cases, one can see the pitch as the byte increment needed
|
||||
to skip to the <em>next lower scanline</em> in a given bitmap buffer.</p>
|
||||
|
||||
<p>The two conventions are detailed by this graphics:</p>
|
||||
|
||||
<center><table>
|
||||
<tr>
|
||||
<td><img SRC="up_flow.png" height=261 width=275></td>
|
||||
|
||||
<td><img SRC="down_flow.png" height=263 width=273></td>
|
||||
</tr>
|
||||
</table></center>
|
||||
|
||||
<p>The <em>positive pitch</em> convention is very often used, though
|
||||
some systems might need otherwise.</p>
|
||||
|
||||
|
||||
</blockquote><h3><a name="section-3">
|
||||
3. Converting outlines into bitmaps and pixmaps :
|
||||
</h3><blockquote>
|
||||
|
||||
<p>Generating a bitmap or pixmap image from a vectorial image
|
||||
is easy with FreeType. However, one must understand a few points regarding
|
||||
the positioning of the outline in the 2D plane before converting it to
|
||||
a bitmap. These are :</p>
|
||||
|
||||
<ul>
|
||||
|
||||
<li><p>
|
||||
The glyph loader and hinter always places the outline in the 2D plane so
|
||||
that (0,0) matches its character origin. This means that the glyph’s outline,
|
||||
and corresponding bounding box, can be placed anywhere in the 2D plane
|
||||
(see the graphics in section III).
|
||||
</p></li>
|
||||
|
||||
<li><p>
|
||||
The target bitmap’s area is mapped to the 2D plane, with its lower left
|
||||
corner at (0,0). This means that a bitmap or pixmap of dimensions
|
||||
[<tt>w,h</tt>] will be mapped to a 2D rectangle window delimited by
|
||||
(0,0)-(<tt>w,h</tt>).
|
||||
</p></li>
|
||||
|
||||
<li><p>
|
||||
When scan-converting the outline, everything that falls
|
||||
within the bitmap window is rendered, the rest is ignored.
|
||||
</p></li>
|
||||
|
||||
<p>A common mistake made by many developers when they begin using FreeType
|
||||
is believing that a loaded outline can be directly rendered in a bitmap
|
||||
of adequate dimensions. The following images illustrate why this is a problem:
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<ul>
|
||||
|
||||
<li>
|
||||
the first image shows a loaded outline in the 2D plane.
|
||||
</li>
|
||||
|
||||
<li>
|
||||
the second one shows the target window for a bitmap of arbitrary dimensions
|
||||
[w,h]
|
||||
</li>
|
||||
|
||||
<li>
|
||||
the third one shows the juxtaposition of the outline and window in the
|
||||
2D plane
|
||||
</li>
|
||||
|
||||
<li>
|
||||
the last image shows what will really be rendered in the bitmap.
|
||||
</li>
|
||||
</ul>
|
||||
</p>
|
||||
|
||||
</ul>
|
||||
<center><img SRC="clipping.png" height=151 width=539></center>
|
||||
|
||||
<p><br>
|
||||
<br>
|
||||
<br>
|
||||
<p>Indeed, in nearly all cases, the loaded or transformed outline must
|
||||
be translated before it is rendered into a target bitmap, in order to adjust
|
||||
its position relative to the target window.
|
||||
</p>
|
||||
|
||||
<p>For example, the correct way of creating a <i>standalone</i> glyph bitmap
|
||||
is thus to :
|
||||
</p>
|
||||
|
||||
<ul>
|
||||
<li><p>
|
||||
Compute the size of the glyph bitmap. It can be computed directly from
|
||||
the glyph metrics, or by computing its bounding box (this is useful when
|
||||
a transform has been applied to the outline after the load, as the glyph
|
||||
metrics are not valid anymore).
|
||||
</p></li>
|
||||
|
||||
<li><p>
|
||||
Create the bitmap with the computed dimensions. Don't forget to fill the
|
||||
pixel buffer with the background color.
|
||||
</p></li>
|
||||
|
||||
<li><p>
|
||||
Translate the outline so that its lower left corner matches (0,0). Don’t
|
||||
forget that in order to preserve hinting, one should use integer, i.e.
|
||||
rounded distances (of course, this isn’t required if preserving hinting
|
||||
information doesn’t matter, like with rotated text). Usually, this means
|
||||
translating with a vector <tt>( -ROUND(xMin), -ROUND(yMin) )</tt>.
|
||||
</p></li>
|
||||
|
||||
<li><p>
|
||||
Call the rendering function (it can be <tt>FT_Outline_Render</tt> for
|
||||
example).
|
||||
</p></li>
|
||||
|
||||
<p><br>In the case where one wants to write glyph images directly into
|
||||
a large bitmap, the outlines must be translated so that their vectorial
|
||||
position correspond to the current text cursor/character origin.</blockquote>
|
||||
</blockquote>
|
||||
|
||||
<center><table width="100%" border=0 cellpadding=5><tr bgcolor="#CCFFCC" valign=center>
|
||||
<td align=center width="30%">
|
||||
<a href="glyphs-6.html">Previous</a>
|
||||
</td>
|
||||
<td align=center width="30%">
|
||||
<a href="index.html">Contents</a>
|
||||
</td>
|
||||
<td align=center width="30%">
|
||||
|
||||
</td>
|
||||
</tr></table></center>
|
||||
|
||||
</td></tr></table></center>
|
||||
|
||||
</body>
|
||||
</html>
|
||||
File diff suppressed because it is too large
Load Diff
Binary file not shown.
|
Before Width: | Height: | Size: 1.1 KiB After Width: | Height: | Size: 2.2 KiB |
Loading…
Reference in New Issue
Block a user