485 lines
14 KiB
HTML
485 lines
14 KiB
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>
|
|
|
|
<body text="#000000"
|
|
bgcolor="#FFFFFF"
|
|
link="#0000EF"
|
|
vlink="#51188E"
|
|
alink="#FF0000">
|
|
|
|
<h1 align=center>
|
|
FreeType Glyph Conventions
|
|
</h1>
|
|
|
|
<h2 align=center>
|
|
Version 2.1
|
|
</h2>
|
|
|
|
<h3 align=center>
|
|
Copyright 1998-2000 David Turner (<a
|
|
href="mailto:david@freetype.org">david@freetype.org</a>)<br>
|
|
Copyright 2000 The FreeType Development Team (<a
|
|
href="mailto:devel@freetype.org">devel@freetype.org</a>)
|
|
</h3>
|
|
|
|
<center>
|
|
<table width="65%">
|
|
<tr><td>
|
|
|
|
<center>
|
|
<table width="100%"
|
|
border=0
|
|
cellpadding=5>
|
|
<tr bgcolor="#CCFFCC"
|
|
valign=center>
|
|
<td align=center
|
|
width="30%">
|
|
<a href="glyphs-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>
|
|
|
|
<p><hr></p>
|
|
|
|
<table width="100%">
|
|
<tr bgcolor="#CCCCFF"
|
|
valign=center><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>
|
|
|
|
|
|
<a name="section-1">
|
|
<h3>
|
|
1. Writing simple text strings
|
|
</h3>
|
|
|
|
<p>In this first example, we will generate a simple string of Roman
|
|
text, i.e. with a horizontal left-to-right layout. Using exclusively
|
|
pixel metrics, the process looks like:
|
|
|
|
<tt>
|
|
<ol>
|
|
<li>
|
|
Convert the character string into a series of glyph
|
|
indices.
|
|
</li>
|
|
<li>
|
|
Place the pen to the cursor position.
|
|
</li>
|
|
<li>
|
|
Get or load the glyph image.
|
|
</li>
|
|
<li>
|
|
Translate the glyph so that its 'origin' matches the pen position.
|
|
</li>
|
|
<li>
|
|
Render the glyph to the target device.
|
|
</li>
|
|
<li>
|
|
Increment the pen position by the glyph's advance width in pixels.
|
|
</li>
|
|
<li>
|
|
Start over at step 3 for each of the remaining glyphs.
|
|
</li>
|
|
<li>
|
|
When all glyphs are done, set the text cursor to the new pen
|
|
position.
|
|
</li>
|
|
</ol>
|
|
</tt>
|
|
|
|
<p>Note that kerning isn't part of this algorithm.</p>
|
|
|
|
|
|
<a name="section-2">
|
|
<h3>
|
|
2. Sub-pixel positioning
|
|
</h3>
|
|
|
|
<p>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
|
|
subsection 1, with the following few differences:</p>
|
|
|
|
<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>
|
|
</ol>
|
|
|
|
<p>Here an improved version of the algorithm:</p>
|
|
|
|
<tt>
|
|
<ol>
|
|
<li>
|
|
Convert the character string into a series of glyph
|
|
indices.
|
|
</li>
|
|
<li>
|
|
Place the pen to the cursor position. This can be a non-integer
|
|
point.
|
|
</li>
|
|
<li>
|
|
Get or load the glyph image.
|
|
</li>
|
|
<li>
|
|
Translate the glyph so that its "origin" matches the rounded pen
|
|
position.
|
|
</li>
|
|
<li>
|
|
Render the glyph to the target device.
|
|
</li>
|
|
<li>
|
|
Increment the pen position by the glyph's advance width in
|
|
fractional pixels.
|
|
</li>
|
|
<li>
|
|
Start over at step 3 for each of the remaining glyphs.
|
|
</li>
|
|
<li>
|
|
When all glyphs are done, set the text cursor to the new pen
|
|
position.
|
|
</li>
|
|
</ol>
|
|
</tt>
|
|
|
|
<p>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.</p>
|
|
|
|
|
|
<a name="section-3">
|
|
<h3>
|
|
3. Simple kerning
|
|
</h3>
|
|
|
|
<p>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>
|
|
|
|
<p>Algorithm 1 with kerning:</p>
|
|
|
|
<tt>
|
|
<ol>
|
|
<li>
|
|
Convert the character string into a series of glyph
|
|
indices.
|
|
</li>
|
|
<li>
|
|
Place the pen to the cursor position.
|
|
</li>
|
|
<li>
|
|
Get or load the glyph image.
|
|
</li>
|
|
<li>
|
|
Add the rounded scaled kerning distance, if any, to the pen
|
|
position.
|
|
</li>
|
|
<li>
|
|
Translate the glyph so that its "origin" matches the pen position.
|
|
</li>
|
|
<li>
|
|
Render the glyph to the target device.
|
|
</li>
|
|
<li>
|
|
Increment the pen position by the glyph's advance width in pixels.
|
|
</li>
|
|
<li>
|
|
Start over at step 3 for each of the remaining glyphs.
|
|
</li>
|
|
</ol>
|
|
</tt>
|
|
|
|
<p>Algorithm 2 with kerning:</p>
|
|
|
|
<tt>
|
|
<ol>
|
|
<li>
|
|
Convert the character string into a series of glyph
|
|
indices.
|
|
</li>
|
|
<li>
|
|
Place the pen to the cursor position.
|
|
</li>
|
|
<li>
|
|
Get or load the glyph image.
|
|
</li>
|
|
<li>
|
|
Add the scaled unrounded kerning distance, if any, to the pen
|
|
position.
|
|
</li>
|
|
<li>
|
|
Translate the glyph so that its "origin" matches the rounded pen
|
|
position.
|
|
</li>
|
|
<li>
|
|
Render the glyph to the target device.
|
|
</li>
|
|
<li>
|
|
Increment the pen position by the glyph's advance width in
|
|
fractional pixels.
|
|
</li>
|
|
<li>
|
|
Start over at step 3 for each of the remaining glyphs.
|
|
</li>
|
|
</ol>
|
|
</tt>
|
|
|
|
Of course, the algorithm described in section IV can also be
|
|
applied to prevent the sliding dot problem if one wants to.
|
|
|
|
|
|
<a name="section-4">
|
|
<h3>
|
|
4. Right-to-left layout
|
|
</h3>
|
|
|
|
<p>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).</p>
|
|
|
|
<p>Right-to-left algorithm 1:</p>
|
|
|
|
<tt>
|
|
<ol>
|
|
<li>
|
|
Convert the character string into a series of glyph
|
|
indices.
|
|
</li>
|
|
<li>
|
|
Place the pen to the cursor position.
|
|
</li>
|
|
<li>
|
|
Get or load the glyph image.
|
|
</li>
|
|
<li>
|
|
Decrement the pen position by the glyph's advance width in pixels.
|
|
</li>
|
|
<li>
|
|
Translate the glyph so that its "origin" matches the pen position.
|
|
</li>
|
|
<li>
|
|
Render the glyph to the target device.
|
|
</li>
|
|
<li>
|
|
Start over at step 3 for each of the remaining glyphs.
|
|
</li>
|
|
</ol>
|
|
</tt>
|
|
|
|
<p>The changes to algorithm 2, as well as the inclusion of kerning
|
|
are left as an exercise to the reader.</p>
|
|
|
|
|
|
<a name="section-5">
|
|
<h3>
|
|
5. Vertical layouts
|
|
</h3>
|
|
|
|
<p>Laying out vertical text uses exactly the same processes, with the
|
|
following significant differences:</p>
|
|
|
|
<ul>
|
|
<li>
|
|
<p>The baseline is vertical, and the vertical metrics must be used
|
|
instead of the horizontal one.</p>
|
|
</li>
|
|
<li>
|
|
<p>The left bearing is usually negative, but this doesn't change the
|
|
fact that the glyph origin must be located on the baseline.</p>
|
|
</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
|
|
<i>Y</i> axis is oriented upwards).
|
|
</li>
|
|
</ul>
|
|
|
|
<p>Here the algorithm:</p>
|
|
|
|
<tt>
|
|
<ol>
|
|
<li>
|
|
Convert the character string into a series of glyph
|
|
indices.
|
|
</li>
|
|
<li>
|
|
Place the pen to the cursor position.
|
|
</li>
|
|
<li>
|
|
Get or load the glyph image.
|
|
</li>
|
|
<li>
|
|
Translate the glyph so that its "origin" matches the pen position.
|
|
</li>
|
|
<li>
|
|
Render the glyph to the target device.
|
|
</li>
|
|
<li>
|
|
Decrement the vertical pen position by the glyph's advance height
|
|
in pixels.
|
|
</li>
|
|
<li>
|
|
Start over at step 3 for each of the remaining glyphs.
|
|
</li>
|
|
<li>
|
|
When all glyphs are done, set the text cursor to the new pen
|
|
position.
|
|
</li>
|
|
</ol>
|
|
</tt>
|
|
|
|
|
|
<a name="section-6">
|
|
<h3>
|
|
6. WYSIWYG text layouts
|
|
</h3>
|
|
|
|
<p>As you probably know, the acronym WYSIWYG stands for "What You See Is
|
|
What You Get". Basically, this means that the output of a document on
|
|
the screen should match "perfectly" its printed version. A
|
|
<em>true</em> WYSIWYG system requires two things:</p>
|
|
|
|
<ul>
|
|
<li>
|
|
<p><em>device-independent text layout</em></p>
|
|
|
|
<p>This 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.</p>
|
|
</li>
|
|
<li>
|
|
<p><em>matching display and print character sizes</em></p>
|
|
|
|
<p>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%).</p>
|
|
</li>
|
|
</ul>
|
|
|
|
<p>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 is not too
|
|
unfortunate, however, because most users really don't care about this
|
|
feature. Legibility is much more important.</p>
|
|
|
|
<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 equals exactly
|
|
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>
|
|
|
|
<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 (technical note: through delta-hinting) for the sizes of 10, 12,
|
|
14 and 16 points at 96 dpi.</p>
|
|
|
|
<p>The term <em>device-independent text</em> 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 <em>hinted</em> 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
|
|
<em>whole</em> document layout, especially if it makes strong use of
|
|
justification, uses few page breaks, etc.</p>
|
|
|
|
<p>Because 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 will 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>
|
|
|
|
<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 whatever metrics you want and store
|
|
them with the text in order to get sure they are printed the same on all
|
|
devices (the latter being probably the best solution, as it also enables
|
|
font substitution without breaking text layouts).</p>
|
|
|
|
<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
|
|
<em>is</em> a requirement.</p>
|
|
|
|
|
|
<p><hr></p>
|
|
|
|
<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>
|