More fixes to the tutorial.
Added artificial Type 1 pid/eid paors to ttnameid.h.
This commit is contained in:
parent
0b7b23edfd
commit
e67e349a0b
|
@ -37,7 +37,7 @@
|
|||
Introduction
|
||||
</h2>
|
||||
|
||||
<p>This is the first section of the FreeType 2 tutorial. It will
|
||||
<p>This is the first part of the FreeType 2 tutorial. It will
|
||||
teach you to do the following:</p>
|
||||
|
||||
<ul>
|
||||
|
@ -55,7 +55,7 @@
|
|||
1. Header files
|
||||
</h3>
|
||||
|
||||
<p>To include the main FreeType header file, simply say</p>
|
||||
<p>To include the main FreeType header file, say</p>
|
||||
|
||||
<font color="blue">
|
||||
<pre>
|
||||
|
@ -64,7 +64,8 @@
|
|||
|
||||
<p>in your application code. Note that other files are available in the
|
||||
FreeType include directory, most of them being included by
|
||||
<tt>freetype.h</tt>. They will be described later in this tutorial.</p>
|
||||
<tt>freetype.h</tt> and other (internal) files. Some of them will be
|
||||
described later in this tutorial.</p>
|
||||
|
||||
<hr>
|
||||
|
||||
|
@ -104,15 +105,15 @@
|
|||
<li>
|
||||
Load each module that FreeType knows about in the library. This
|
||||
means that by default, your new <tt>library</tt> object is able to
|
||||
handle TrueType, Type 1, CID-keyed & OpenType/CFF fonts
|
||||
gracefully.
|
||||
handle TrueType, Type 1, Windows FON, CID-keyed & OpenType/CFF
|
||||
fonts gracefully.
|
||||
</li>
|
||||
</ul>
|
||||
|
||||
<p>As you can see, the function returns an error code, like most others
|
||||
in the FreeType API. An error code of 0 <em>always</em> means that
|
||||
the operation was successful; otherwise, the value describes the error,
|
||||
and <tt>library</tt> is set to NULL.</p>
|
||||
and <tt>library</tt> is set to <tt>NULL</tt>.</p>
|
||||
|
||||
<hr>
|
||||
|
||||
|
@ -150,7 +151,7 @@
|
|||
else if ( error )
|
||||
{
|
||||
... another error code means that the font file could not
|
||||
... be opened or read, or simply that it is broken
|
||||
... be opened or read, or that it is broken
|
||||
}</pre>
|
||||
</font>
|
||||
|
||||
|
@ -160,24 +161,24 @@
|
|||
<table cellpadding=5>
|
||||
<tr valign="top">
|
||||
<td>
|
||||
<tt><b>library</b></tt>
|
||||
<tt>library</tt>
|
||||
</td>
|
||||
<td>
|
||||
<p>a handle to the FreeType library instance where the face
|
||||
<p>A handle to the FreeType library instance where the face
|
||||
object is created</p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr valign="top">
|
||||
<td>
|
||||
<tt><b>filepathname</b></tt>
|
||||
<tt>filepathname</tt>
|
||||
</td>
|
||||
<td>
|
||||
<p>the font file pathname (standard C string).</p>
|
||||
<p>The font file pathname (a standard C string).</p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr valign="top">
|
||||
<td>
|
||||
<tt><b>face_index</b></tt>
|
||||
<tt>face_index</tt>
|
||||
</td>
|
||||
<td>
|
||||
<p>Certain font formats allow several font faces to be embedded
|
||||
|
@ -191,13 +192,13 @@
|
|||
</tr>
|
||||
<tr valign="top">
|
||||
<td>
|
||||
<tt><b>face</b></tt>
|
||||
<tt>face</tt>
|
||||
</td>
|
||||
<td>
|
||||
<p>A <em>pointer</em> to the handle that will be set to describe
|
||||
the new face object.</p>
|
||||
|
||||
<p>It is set to NULL in case of error.</p>
|
||||
<p>It is set to <tt>NULL</tt> in case of error.</p>
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
@ -232,9 +233,9 @@
|
|||
if ( error ) { ... }</pre>
|
||||
</font>
|
||||
|
||||
<p>As you can see, <tt>FT_New_Memory_Face()</tt> simply takes a
|
||||
pointer to the font file buffer and its size in bytes instead of a
|
||||
file pathname. Other than that, it has exactly the same semantics as
|
||||
<p>As you can see, <tt>FT_New_Memory_Face()</tt> takes a pointer to
|
||||
the font file buffer and its size in bytes instead of a file pathname.
|
||||
Other than that, it has exactly the same semantics as
|
||||
<tt>FT_New_Face()</tt>.</p>
|
||||
|
||||
<h4>
|
||||
|
@ -242,14 +243,14 @@
|
|||
</h4>
|
||||
|
||||
<p>There are cases where using a file pathname or preloading the file
|
||||
in memory is simply not enough. With FreeType 2, it is possible
|
||||
to provide your own implementation of i/o routines.</p>
|
||||
in memory is not sufficient. With FreeType 2, it is possible to
|
||||
provide your own implementation of I/O routines.</p>
|
||||
|
||||
<p>This is done through the <tt>FT_Open_Face()</tt> function, which
|
||||
can be used to open a new font face with a custom input stream, select
|
||||
a specific driver for opening, or even pass extra parameters to the
|
||||
font driver when creating the object. We advise you to refer to the
|
||||
FreeType 2 reference manual in order to learn how to use it.</p>
|
||||
FreeType 2 API reference in order to learn how to use it.</p>
|
||||
|
||||
<p>Note that providing a custom stream might also be used to access a
|
||||
TrueType font embedded in a Postscript Type 42 wrapper.</p>
|
||||
|
@ -267,7 +268,7 @@
|
|||
<table cellpadding=5>
|
||||
<tr valign="top">
|
||||
<td>
|
||||
<tt><b>face->num_glyphs</b></tt>
|
||||
<tt>face->num_glyphs</tt>
|
||||
</td>
|
||||
<td>
|
||||
<p>Gives the number of <em>glyphs</em> available in the font face.
|
||||
|
@ -277,7 +278,7 @@
|
|||
</tr>
|
||||
<tr valign="top">
|
||||
<td>
|
||||
<tt><b>face->flags</b></tt>
|
||||
<tt>face->flags</tt>
|
||||
</td>
|
||||
<td>
|
||||
<p>A 32-bit integer containing bit flags used to describe some
|
||||
|
@ -290,7 +291,7 @@
|
|||
</tr>
|
||||
<tr valign="top">
|
||||
<td>
|
||||
<tt><b>face->units_per_EM</b></tt>
|
||||
<tt>face->units_per_EM</tt>
|
||||
</td>
|
||||
<td>
|
||||
<p>This field is only valid for scalable formats (it is set
|
||||
|
@ -300,7 +301,7 @@
|
|||
</tr>
|
||||
<tr valign="top">
|
||||
<td>
|
||||
<tt><b>face->num_fixed_sizes</b></tt>
|
||||
<tt>face->num_fixed_sizes</tt>
|
||||
</td>
|
||||
<td>
|
||||
<p>This field gives the number of embedded bitmap <em>strikes</em>
|
||||
|
@ -313,7 +314,7 @@
|
|||
</tr>
|
||||
<tr valign="top">
|
||||
<td>
|
||||
<tt><b>face->fixed_sizes</b></tt>
|
||||
<tt>face->fixed_sizes</tt>
|
||||
</td>
|
||||
<td>
|
||||
<p>This is a pointer to an array of <tt>FT_Bitmap_Size</tt>
|
||||
|
@ -376,7 +377,7 @@
|
|||
<li>
|
||||
The character width and heights are specified in 1/64th of points.
|
||||
A point is a <em>physical</em> distance, equaling 1/72th of an inch;
|
||||
it's not a pixel.
|
||||
it is not a pixel.
|
||||
</li>
|
||||
<li>
|
||||
Horizontal and vertical device resolutions are expressed in
|
||||
|
@ -397,7 +398,7 @@
|
|||
</li>
|
||||
<li>
|
||||
The first argument is a handle to a face object, not a size object.
|
||||
That's normal, and must be seen as a convenience.
|
||||
This behaviour must be seen as a convenience.
|
||||
</li>
|
||||
</ul>
|
||||
|
||||
|
@ -421,7 +422,7 @@
|
|||
<p>Note that both functions return an error code. Usually, an error
|
||||
occurs with a fixed-size font format (like FNT or PCF) when trying to
|
||||
set the pixel size to a value that is not listed in the
|
||||
<tt>face->fixed_sizes></tt> array.</p>
|
||||
<tt>face->fixed_sizes</tt> array.</p>
|
||||
|
||||
<hr>
|
||||
|
||||
|
@ -436,7 +437,7 @@
|
|||
<p>Usually, an application wants to load a glyph image based on its
|
||||
<em>character code</em>, which is a unique value that defines the
|
||||
character for a given <em>encoding</em>. For example, the character
|
||||
code 65 represents the `A' in ASCII encoding.</p>
|
||||
code 65 in ASCII encoding represents letter `A'.</p>
|
||||
|
||||
<p>A face object contains one or more tables, called
|
||||
<em>charmaps</em>, that are used to convert character codes to glyph
|
||||
|
@ -468,10 +469,10 @@
|
|||
face.
|
||||
|
||||
<p>Note that this is one of the rare FreeType functions that do not
|
||||
return an error code. However, when a given character code has no
|
||||
glyph image in the face, the value 0 is returned. By convention,
|
||||
it always corresponds to a special glyph image called the <b>missing
|
||||
glyph</b>, which usually is represented as a box or a space.</p>
|
||||
return an error code. If a given character code has no glyph image in
|
||||
the face, the value 0 is returned. By convention, it always
|
||||
corresponds to a special glyph image called the <em>missing
|
||||
glyph</em>, which usually is represented as a box or a space.</p>
|
||||
|
||||
<h4>
|
||||
b. Loading a glyph from the face
|
||||
|
@ -481,8 +482,8 @@
|
|||
image. The latter can be stored in various formats within the font
|
||||
file. For fixed-size formats like FNT or PCF, each image is a bitmap.
|
||||
Scalable formats like TrueType or Type 1 use vectorial shapes,
|
||||
named <em>outlines</em> to describe each glyph. Some formats may have
|
||||
even more exotic ways of representing glyph (e.g. MetaFont).
|
||||
named <em>outlines</em>, to describe each glyph. Some formats may have
|
||||
even more exotic ways of representing glyphs (e.g. MetaFont).
|
||||
Fortunately, FreeType 2 is flexible enough to support any kind of
|
||||
glyph format through a simple API.</p>
|
||||
|
||||
|
@ -513,10 +514,10 @@
|
|||
<ul>
|
||||
<li>
|
||||
<p>If a bitmap is found for the corresponding glyph and pixel
|
||||
size, it will be loaded into the slot (embedded bitmaps are always
|
||||
favored over native image formats, because we assume that they are
|
||||
higher-quality versions of the same glyph. This can be changed by
|
||||
using the <tt>FT_LOAD_NO_BITMAP</tt> flag)</p>
|
||||
size, it will be loaded into the slot. Embedded bitmaps are
|
||||
always favored over native image formats, because we assume that
|
||||
they are higher-quality versions of the same glyph. This can be
|
||||
changed by using the <tt>FT_LOAD_NO_BITMAP</tt> flag.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>Otherwise, a native image for the glyph will be loaded. It
|
||||
|
@ -554,8 +555,8 @@
|
|||
position (on the baseline) to the top-most border of the glyph bitmap.
|
||||
<em>It is positive to indicate an upwards distance</em>.</p>
|
||||
|
||||
<p>The second part of the tutorial will describe the contents of a
|
||||
glyph slot and how to access specific glyph information (including
|
||||
<p>The second part of the tutorial describes the contents of a glyph
|
||||
slot and how to access specific glyph information (including
|
||||
metrics).</p>
|
||||
|
||||
<h4>
|
||||
|
@ -565,16 +566,16 @@
|
|||
<p>As said before, when a new face object is created, it will look for
|
||||
a Unicode, Latin-1, or ASCII charmap and select it. The currently
|
||||
selected charmap is accessed via <tt>face->charmap</tt>. This field
|
||||
is NULL if no charmap is selected, which typically happens when you
|
||||
create a new <tt>FT_Face</tt> object from a font file that doesn't
|
||||
contain an ASCII, Latin-1, or Unicode charmap (rare stuff).</p>
|
||||
is <tt>NULL</tt> if no charmap is selected, which typically happens
|
||||
when you create a new <tt>FT_Face</tt> object from a font file that
|
||||
doesn't contain an ASCII, Latin-1, or Unicode charmap (rare
|
||||
stuff).</p>
|
||||
|
||||
<p>There are two ways to select a different charmap with
|
||||
FreeType 2. The easiest is if the encoding you need already has
|
||||
a corresponding enumeration defined in
|
||||
<tt><freetype/freetype.h></tt>, as <tt>ft_encoding_big5</tt>.
|
||||
In this case, you can simply call <tt>FT_Select_CharMap()</tt> as
|
||||
in</p>
|
||||
a corresponding enumeration defined in <tt>freetype/freetype.h</tt>,
|
||||
as <tt>ft_encoding_big5</tt>. In this case, you can simply call
|
||||
<tt>FT_Select_CharMap()</tt> as in</p>
|
||||
|
||||
<font color="blue"><pre>
|
||||
error = FT_Select_CharMap(
|
||||
|
@ -582,12 +583,12 @@
|
|||
ft_encoding_big5 ); /* encoding */</pre>
|
||||
</font>
|
||||
|
||||
<p>Another way is to manually parse the list of charmaps for the face,
|
||||
<p>Another way is to manually parse the list of charmaps for the face;
|
||||
this is accessible through the fields <tt>num_charmaps</tt> and
|
||||
<tt>charmaps</tt> (notice the final 's') of the face object. As you
|
||||
could expect, the first is the number of charmaps in the face, while
|
||||
the second is <em>a table of pointers to the charmaps</em> embedded in
|
||||
the face.</p>
|
||||
<tt>charmaps</tt> (notice the final 's') of the face object. As
|
||||
expected, the first is the number of charmaps in the face, while the
|
||||
second is <em>a table of pointers to the charmaps</em> embedded in the
|
||||
face.</p>
|
||||
|
||||
<p>Each charmap has a few visible fields used to describe it more
|
||||
precisely. Mainly, one will look at <tt>charmap->platform_id</tt> and
|
||||
|
@ -595,16 +596,20 @@
|
|||
be used to describe the charmap in a rather generic way.</p>
|
||||
|
||||
<p>Each value pair corresponds to a given encoding. For example, the
|
||||
pair (3,1) corresponds to Unicode. A list of such pairs is defined in
|
||||
the TrueType specification, but you can also use the file
|
||||
<tt><freetype/ftnameid.h></tt> which defines several helpful
|
||||
constants to deal with them.</p>
|
||||
pair (3,1) corresponds to Unicode (on the Windows platform). A list
|
||||
of such pairs is defined in the TrueType specification, but you can
|
||||
also use the file <tt><freetype/ttnameid.h></tt> which defines
|
||||
several helpful constants to deal with them.</p>
|
||||
|
||||
<p>Note that some pid/eid pairs are <em>artificial</em>; such values
|
||||
have been created by FreeType to identify platforms resp. encodings
|
||||
not covered by the original TrueType specification.</p>
|
||||
|
||||
<p>To look up a specific encoding you need to find a corresponding
|
||||
value pair in the specification, then look for it in the charmaps
|
||||
list. Bear in mind that some encodings correspond to several values
|
||||
pairs (yes, it's a real mess, but blame Apple and Microsoft on such
|
||||
stupidity). Here some code to do it:</p>
|
||||
value pair in the specification, then look for it in the
|
||||
<tt>charmaps</tt> list. Bear in mind that some encodings correspond
|
||||
to several values pairs (yes, it's a real mess, but blame Apple and
|
||||
Microsoft on such stupidity). Here some code to do it:</p>
|
||||
|
||||
<font color="blue">
|
||||
<pre>
|
||||
|
@ -654,26 +659,26 @@
|
|||
</font>
|
||||
|
||||
<p>This function will set the current transformation for a given face
|
||||
object. Its second parameter is a pointer to a <tt>FT_Matrix</tt>
|
||||
structure that describes a 2x2 affine matrix. The third parameter is
|
||||
a pointer to a <tt>FT_Vector</tt> structure that describes a simple 2d
|
||||
vector that is used to translate the glyph image <em>after</em> the
|
||||
2x2 transformation.</p>
|
||||
object. Its second parameter is a pointer to an <tt>FT_Matrix</tt>
|
||||
structure that describes a 2x2 affine matrix. The third
|
||||
parameter is a pointer to an <tt>FT_Vector</tt> structure that
|
||||
describes a simple 2d vector that is used to translate the glyph
|
||||
image <em>after</em> the 2x2 transformation.</p>
|
||||
|
||||
<p>Note that the matrix pointer can be set to NULL, in which case the
|
||||
identity transformation will be used. Coefficients of the matrix are
|
||||
otherwise in 16.16 fixed float units.</p>
|
||||
<p>Note that the matrix pointer can be set to <tt>NULL</tt>, in which
|
||||
case the identity transformation will be used. Coefficients of the
|
||||
matrix are otherwise in 16.16 fixed float units.</p>
|
||||
|
||||
<p>The vector pointer can also be set to NULL in which case a delta
|
||||
vector of (0,0) will be used. The vector coordinates are expressed in
|
||||
1/64th of a pixel (also known as 26.6 fixed floats).</p>
|
||||
<p>The vector pointer can also be set to <tt>NULL</tt> in which case a
|
||||
delta vector of (0,0) will be used. The vector coordinates are
|
||||
expressed in 1/64th of a pixel (also known as 26.6 fixed floats).</p>
|
||||
|
||||
<p><em>The transformation is applied to every glyph that is loaded
|
||||
through <tt>FT_Load_Glyph()</tt> and is <b>completely independent of
|
||||
any hinting process.</b> This means that you won't get the same
|
||||
results if you load a glyph at the size of 24 pixels, or a glyph
|
||||
at the size at 12 pixels scaled by 2 through a
|
||||
transformation, because the hints will have been computed differently
|
||||
transformation, because hints will have been computed differently
|
||||
(unless hints have been disabled, of course).</em></p>
|
||||
|
||||
<p>If you ever need to use a non-orthogonal transformation with
|
||||
|
@ -692,9 +697,8 @@
|
|||
7. Simple text rendering
|
||||
</h3>
|
||||
|
||||
<p>We will now present you with a very simple example used to render a
|
||||
string of 8-bit Latin-1 text, assuming a face that contains a Unicode
|
||||
charmap</p>
|
||||
<p>We will now present a very simple example used to render a string of
|
||||
8-bit Latin-1 text, assuming a face that contains a Unicode charmap</p>
|
||||
|
||||
<p>The idea is to create a loop that will, on each iteration, load one
|
||||
glyph image, convert it to an anti-aliased bitmap, draw it on the target
|
||||
|
@ -764,9 +768,9 @@
|
|||
truncated to integer pixels on each iteration.
|
||||
</li>
|
||||
<li>
|
||||
The function <tt>my_draw_bitmap()</tt> is not part of FreeType,
|
||||
but must be provided by the application to draw the bitmap to the
|
||||
target surface. In this example, it takes a pointer to a
|
||||
The function <tt>my_draw_bitmap()</tt> is not part of FreeType but
|
||||
must be provided by the application to draw the bitmap to the
|
||||
target surface. In this example, it takes a pointer to an
|
||||
<tt>FT_Bitmap</tt> descriptor and the position of its top-left
|
||||
corner as arguments.
|
||||
</li>
|
||||
|
@ -834,8 +838,8 @@
|
|||
equivalent.</p>
|
||||
|
||||
<p>Note that you can also specify that you want a monochrome
|
||||
bitmap instead by using the additional <tt>FT_LOAD_MONOCHROME</tt>
|
||||
load flag.</p>
|
||||
bitmap by using the <tt>FT_LOAD_MONOCHROME</tt> load flag
|
||||
instead.</p>
|
||||
</li>
|
||||
</ul>
|
||||
|
||||
|
@ -850,7 +854,7 @@
|
|||
FT_Matrix matrix; /* transformation matrix */
|
||||
FT_UInt glyph_index;
|
||||
FT_Vector pen; /* untransformed origin */
|
||||
int pen_x, pen_y, n;
|
||||
int n;
|
||||
|
||||
|
||||
.. initialize library ..
|
||||
|
@ -896,8 +900,8 @@
|
|||
multiplication. The position is expressed in cartesian space.
|
||||
</li>
|
||||
<li>
|
||||
Glyph images are always loaded, transformed, and described in the
|
||||
cartesian coordinate system in FreeType (which means that
|
||||
In FreeType, glyph images are always loaded, transformed, and
|
||||
described in the cartesian coordinate system (which means that
|
||||
increasing Y corresponds to upper scanlines), unlike the
|
||||
system typically used for bitmaps (where the top-most scanline has
|
||||
coordinate 0). We must thus convert between the two systems
|
||||
|
@ -905,8 +909,8 @@
|
|||
position of the bitmap.
|
||||
</li>
|
||||
<li>
|
||||
We set the transformation on each glyph to indicate the rotation
|
||||
matrix, as well as a delta vector that will move the transformed
|
||||
We apply the transformation matrix on each glyph to indicate
|
||||
rotation as well as a delta vector that will move the transformed
|
||||
image to the current pen position (in cartesian space, not bitmap
|
||||
space).
|
||||
</li>
|
||||
|
@ -931,13 +935,12 @@
|
|||
Conclusion
|
||||
</h3>
|
||||
|
||||
<p>In this first section, you have learned the basics of
|
||||
FreeType 2, as well as sufficient knowledge how to render rotated
|
||||
text.</p>
|
||||
<p>In this first section, you have learned the basics of FreeType 2
|
||||
as well as sufficient knowledge how to render rotated text.</p>
|
||||
|
||||
<p>The next part will dive into more details of the API in order to let
|
||||
you access glyph metrics and images directly, as well as how to deal
|
||||
with scaling, hinting, kerning, etc.</p>
|
||||
you access glyph metrics and images directly, how to deal with scaling,
|
||||
hinting, kerning, etc.</p>
|
||||
|
||||
<p>The third part will discuss issues like modules, caching, and a few
|
||||
other advanced topics like how to use multiple size objects with a
|
||||
|
|
|
@ -37,8 +37,8 @@
|
|||
Introduction
|
||||
</h2>
|
||||
|
||||
<p>This is the second section of the FreeType 2 tutorial. It will
|
||||
teach you the following:</p>
|
||||
<p>This is the second part of the FreeType 2 tutorial. It will teach
|
||||
you the following:</p>
|
||||
|
||||
<ul>
|
||||
<li>how to retrieve glyph metrics</li>
|
||||
|
@ -69,8 +69,8 @@
|
|||
|
||||
<p>Note that only a few font formats provide vertical metrics. You can
|
||||
test wether a given face object contains them by using the macro
|
||||
<tt>FT_HAS_VERTICAL(face)</tt>, which is true if has vertical
|
||||
metrics.</p>
|
||||
<tt>FT_HAS_VERTICAL(face)</tt>, which is true if vertical metrics are
|
||||
available.</p>
|
||||
|
||||
<p>Individual glyph metrics can be accessed by first loading the glyph
|
||||
in a face's glyph slot, then using the <tt>face->glyph->metrics</tt>
|
||||
|
@ -85,7 +85,7 @@
|
|||
</td>
|
||||
<td>
|
||||
This is the width of the glyph image's bounding box. It is
|
||||
independent of layout direction.
|
||||
independent of the layout direction.
|
||||
</td>
|
||||
</tr>
|
||||
<tr valign=top>
|
||||
|
@ -94,7 +94,7 @@
|
|||
</td>
|
||||
<td>
|
||||
This is the height of the glyph image's bounding box. It is
|
||||
independent of layout direction.
|
||||
independent of the layout direction.
|
||||
</td>
|
||||
</tr>
|
||||
<tr valign=top>
|
||||
|
@ -165,8 +165,8 @@
|
|||
should not be considered reliable if <tt>FT_HAS_VERTICAL(face)</tt> is
|
||||
false.</em></p>
|
||||
|
||||
<p>The following graphics illustrate the metrics more clearly. First,
|
||||
for horizontal metrics, where the baseline is the horizontal axis:</p>
|
||||
<p>The following graphics illustrate the metrics more clearly. First
|
||||
horizontal metrics, where the baseline is the horizontal axis:</p>
|
||||
|
||||
<center>
|
||||
<img src="metrics.png"
|
||||
|
@ -221,7 +221,7 @@
|
|||
multiple of 64) by the font driver used to load the glyph
|
||||
image. <tt>linearHoriAdvance</tt> is a 16.16 fixed float number
|
||||
that gives the value of the original glyph advance width in
|
||||
1/65536th of pixels. It can be use to perform pseudo
|
||||
1/65536th of pixels. It can be used to perform pseudo
|
||||
device-independent text layouts.
|
||||
</td>
|
||||
</tr>
|
||||
|
@ -250,9 +250,9 @@
|
|||
glyph image, the previous one is erased from the glyph slot.</p>
|
||||
|
||||
<p>There are times, however, where you may need to extract this image
|
||||
from the glyph slot, in order to cache it within your application, and
|
||||
even perform additional transformations and measures on it before
|
||||
converting it to a bitmap.</p>
|
||||
from the glyph slot. For example, you want to cache images within your
|
||||
application, or you want to apply additional transformations and
|
||||
measures on it before converting it to a bitmap.</p>
|
||||
|
||||
<p>The FreeType 2 API has a specific extension which is capable of
|
||||
dealing with glyph images in a flexible and generic way. To use it, you
|
||||
|
@ -297,11 +297,11 @@
|
|||
<li>
|
||||
loaded the glyph image normally in the face's glyph slot. We did
|
||||
not use <tt>FT_LOAD_RENDER</tt> because we want to grab a scalable
|
||||
glyph image, in order to transform it later,
|
||||
glyph image in order to transform it later,
|
||||
</li>
|
||||
<li>
|
||||
copied the glyph image from the slot into a new <tt>FT_Glyph</tt>
|
||||
object, by calling <tt>FT_Get_Glyph()</tt>. This function returns
|
||||
object by calling <tt>FT_Get_Glyph()</tt>. This function returns
|
||||
an error code and sets <tt>glyph</tt>.
|
||||
</li>
|
||||
</ul>
|
||||
|
@ -313,25 +313,25 @@
|
|||
|
||||
<p>You can access the field <tt>glyph->format</tt> if you want to know
|
||||
exactly how the glyph is modeled and stored. A new glyph object can
|
||||
be destroyed with a call to <tt>FT_Done_Glyph</tt>.</p>
|
||||
be destroyed with a call to <tt>FT_Done_Glyph()</tt>.</p>
|
||||
|
||||
<p>The glyph object contains exactly one glyph image and a 2d vector
|
||||
representing the glyph's advance in 16.16 fixed float coordinates.
|
||||
The latter can be accessed directly as <tt>glyph->advance</tt>.</p>
|
||||
<p>The glyph object contains exactly one glyph image and a
|
||||
2d vector representing the glyph's advance in 16.16 fixed float
|
||||
coordinates. The latter can be accessed directly as
|
||||
<tt>glyph->advance</tt>.</p>
|
||||
|
||||
<p><em>Note that unlike other FreeType objects, the library doesn't
|
||||
keep a list of all allocated glyph objects. This means you will need
|
||||
to destroy them yourself, instead of relying on
|
||||
<tt>FT_Done_FreeType()</tt> doing all the clean-up.</em></p>
|
||||
<tt>FT_Done_FreeType()</tt> to do all the clean-up.</em></p>
|
||||
|
||||
<h4>
|
||||
b. Transforming & copying the glyph image
|
||||
</h4>
|
||||
|
||||
<p>If the glyph image is scalable (i.e., if <tt>glyph->format</tt> is
|
||||
not equal to <tt>ft_glyph_format_bitmap</tt>), it is possible to
|
||||
transform the image anytime by a call to
|
||||
<tt>FT_Glyph_Transform()</tt>.</p>
|
||||
not <tt>ft_glyph_format_bitmap</tt>), it is possible to transform the
|
||||
image anytime by a call to <tt>FT_Glyph_Transform()</tt>.</p>
|
||||
|
||||
<p>You can also copy a single glyph image with
|
||||
<tt>FT_Glyph_Copy()</tt>. Here some example code:</p>
|
||||
|
@ -362,18 +362,20 @@
|
|||
matrix.yx = 0.12 * 0x10000L;
|
||||
matrix.yy = 0x10000L;
|
||||
|
||||
FT_Glyph_Transform( glyph2, &lmatrix, 0 );</pre>
|
||||
FT_Glyph_Transform( glyph2, &matrix, 0 );</pre>
|
||||
</font>
|
||||
|
||||
<p>Note that the 2x2 transform matrix is always applied to the 16.16
|
||||
advance vector in the glyph; you thus don't need to recompute it.</p>
|
||||
<p>Note that the 2x2 transformation matrix is always applied to
|
||||
the 16.16 advance vector in the glyph; you thus don't need to
|
||||
recompute it.</p>
|
||||
|
||||
<h4>
|
||||
c. Measuring the glyph image
|
||||
</h4>
|
||||
|
||||
<p>You can also retrieve the control (bounding) box of any glyph image
|
||||
(scalable or not), using the <tt>FT_Glyph_Get_CBox</tt> function:</p>
|
||||
(scalable or not), using the <tt>FT_Glyph_Get_CBox()</tt>
|
||||
function:</p>
|
||||
|
||||
<font color="blue">
|
||||
<pre>
|
||||
|
@ -386,8 +388,8 @@
|
|||
|
||||
<p>Coordinates are relative to the glyph origin, i.e. (0,0), using the
|
||||
Y upwards convention. This function takes a special argument,
|
||||
the <em>bbox mode</em>, to indicate how box coordinates are expressed.
|
||||
If <tt>bbox_mode</tt> is set to <tt>ft_glyph_bbox_subpixels</tt>, the
|
||||
<tt>bbox_mode</tt>, to indicate how box coordinates are expressed. If
|
||||
<tt>bbox_mode</tt> is set to <tt>ft_glyph_bbox_subpixels</tt>, the
|
||||
coordinates are returned in 26.6 pixels (i.e. 1/64th of pixels).
|
||||
|
||||
<p>Note that the box's maximum coordinates are exclusive, which means
|
||||
|
@ -412,10 +414,10 @@
|
|||
bbox.yMax = CEILING(bbox.yMax)</pre>
|
||||
</font>
|
||||
|
||||
<p>The default value for the bbox mode is
|
||||
<p>The default value for <tt>bbox_mode</tt> is
|
||||
<tt>ft_glyph_bbox_pixels</tt> (i.e. integer, grid-fitted pixel
|
||||
coordinates). Please check the API reference for
|
||||
<tt>FT_Glyph_Get_CBox()</tt> other possible values</p>
|
||||
coordinates). Please check the API reference of
|
||||
<tt>FT_Glyph_Get_CBox()</tt> for other possible values.</p>
|
||||
|
||||
<h4>
|
||||
d. Converting the glyph image to a bitmap
|
||||
|
@ -430,7 +432,7 @@
|
|||
FT_Vector origin;
|
||||
|
||||
|
||||
origin.x = 32; /* 1/2 pixel in 26.26 format */
|
||||
origin.x = 32; /* 1/2 pixel in 26.6 format */
|
||||
origin.y = 0;
|
||||
|
||||
error = FT_Glyph_To_Bitmap( &glyph,
|
||||
|
@ -455,12 +457,12 @@
|
|||
or <tt>ft_render_mode_mono</tt> for a 1-bit monochrome bitmap.
|
||||
</li>
|
||||
<li>
|
||||
The third parameter is a pointer to a 2d vector that is used to
|
||||
translate the source glyph image before the conversion. Note that
|
||||
the source image will be translated back to its original position
|
||||
(and will thus be left unchanged) after the call. If you do not
|
||||
need to translate the source glyph before rendering, set this
|
||||
pointer to 0.
|
||||
The third parameter is a pointer to a 2d vector that is used
|
||||
to translate the source glyph image before the conversion. Note
|
||||
that the source image will be translated back to its original
|
||||
position (and will thus be left unchanged) after the call. If you
|
||||
do not need to translate the source glyph before rendering, set
|
||||
this pointer to 0.
|
||||
</li>
|
||||
<li>
|
||||
The last parameter is a Boolean to indicate whether the source
|
||||
|
@ -530,13 +532,12 @@
|
|||
<p>For scalable formats, all global metrics are expressed in font
|
||||
units in order to be later scaled to device space, according to the
|
||||
rules described in the last chapter of this part of the tutorial. You
|
||||
can access them directly as simple fields of a <tt>FT_Face</tt>
|
||||
handle.</p>
|
||||
can access them directly as fields of an <tt>FT_Face</tt> handle.</p>
|
||||
|
||||
<p>However, you need to check that the font face's format is scalable
|
||||
before using them. One can do it by using the macro
|
||||
<tt>FT_IS_SCALABLE(face)</tt> which returns true if we have a
|
||||
scalable format.</p>
|
||||
before using them. This can be done with the macro
|
||||
<tt>FT_IS_SCALABLE(face)</tt> which returns true if we have a scalable
|
||||
format.</p>
|
||||
|
||||
<p>In this case, you can access the global design metrics as</p>
|
||||
|
||||
|
@ -659,7 +660,7 @@
|
|||
b. Scaled global metrics
|
||||
</h4>
|
||||
|
||||
<p>Each size object also contains a scaled versions of some of the
|
||||
<p>Each size object also contains scaled versions of some of the
|
||||
global metrics described above. They can be accessed directly through
|
||||
the <tt>face->size->metrics</tt> structure.</p>
|
||||
|
||||
|
@ -749,7 +750,10 @@
|
|||
if ( error ) { ... }
|
||||
|
||||
error = FT_Attach_File( face, "/usr/shared/fonts/cour.afm" );
|
||||
if ( error ) { .. could not read kerning and additional metrics .. }</pre>
|
||||
if ( error )
|
||||
{
|
||||
.. could not read kerning and additional metrics ..
|
||||
}</pre>
|
||||
</font>
|
||||
|
||||
<p>Note that <tt>FT_Attach_Stream()</tt> is similar to
|
||||
|
@ -785,10 +789,9 @@
|
|||
a pointer to a destination vector that receives the corresponding
|
||||
distances.</p>
|
||||
|
||||
<p>The kerning mode is very similar to the <em>bbox mode</em>
|
||||
described in a previous part. It is an enumeration value that
|
||||
indicates how the kerning distances are expressed in the target
|
||||
vector.</p>
|
||||
<p>The kerning mode is very similar to <tt>bbox_mode</tt> described in
|
||||
a previous part. It is an enumeration value that indicates how the
|
||||
kerning distances are expressed in the target vector.</p>
|
||||
|
||||
<p>The default value <tt>ft_kerning_mode_default</tt> (which has
|
||||
value 0) corresponds to kerning distances expressed in 26.6
|
||||
|
@ -808,8 +811,8 @@
|
|||
|
||||
<p>Note that the "left" and "right" positions correspond to the
|
||||
<em>visual order</em> of the glyphs in the string of text. This is
|
||||
important for bi-directional text, or simply when writing
|
||||
right-to-left text.</p>
|
||||
important for bidirectional text, or when writing right-to-left
|
||||
text.</p>
|
||||
|
||||
<hr>
|
||||
|
||||
|
@ -817,10 +820,9 @@
|
|||
4. Simple text rendering: kerning + centering
|
||||
</h3>
|
||||
|
||||
<p>In order to show off what we have just learned, we will now show how
|
||||
to modify the example code that was provided in the first part to render
|
||||
a string of text, and enhance it to support kerning and delayed
|
||||
rendering.</p>
|
||||
<p>In order to show off what we have just learned, we will now modify
|
||||
the example code that was provided in the first part to render a string
|
||||
of text, and enhance it to support kerning and delayed rendering.</p>
|
||||
|
||||
<h4>
|
||||
a. Kerning support
|
||||
|
@ -828,9 +830,9 @@
|
|||
|
||||
<p>Adding support for kerning to our code is trivial, as long as we
|
||||
consider that we are still dealing with a left-to-right script like
|
||||
Latin. We simply need to retrieve the kerning distance between two
|
||||
glyphs in order to alter the pen position appropriately. The code
|
||||
looks like</p>
|
||||
Latin. We need to retrieve the kerning distance between two glyphs in
|
||||
order to alter the pen position appropriately. The code looks
|
||||
like</p>
|
||||
|
||||
<font color="blue">
|
||||
<pre>
|
||||
|
@ -913,7 +915,7 @@
|
|||
<li>
|
||||
We do not check the error code returned by
|
||||
<tt>FT_Get_Kerning()</tt>. This is because the function always
|
||||
set the content of <tt>delta</tt> to (0,0) when an error occurs.
|
||||
set <tt>delta</tt> to (0,0) when an error occurs.
|
||||
</li>
|
||||
</ul>
|
||||
|
||||
|
@ -1000,7 +1002,7 @@
|
|||
}</pre>
|
||||
</font>
|
||||
|
||||
<p>As you see, this is a very simple variation of our previous code
|
||||
<p>As you see, this is a very slight variation of our previous code
|
||||
where we extract each glyph image from the slot, and store it, along
|
||||
with the corresponding position, in our tables.</p>
|
||||
|
||||
|
@ -1111,7 +1113,7 @@
|
|||
We call <tt>FT_Glyph_To_Bitmap()</tt> with the <tt>destroy</tt>
|
||||
parameter set to 0 (false), in order to avoid destroying the
|
||||
original glyph image. The new glyph bitmap is accessed through
|
||||
<tt>image</tt> after the call and is typecasted to a
|
||||
<tt>image</tt> after the call and is typecast to an
|
||||
<tt>FT_BitmapGlyph</tt>.
|
||||
</li>
|
||||
<li>
|
||||
|
@ -1304,7 +1306,7 @@
|
|||
</h4>
|
||||
|
||||
<p>However, directly transforming the glyphs in our sequence is not a
|
||||
useful idea if we want to re-use them in order to draw the text string
|
||||
useful idea if we want to reuse them in order to draw the text string
|
||||
with various angles or transforms. It is better to perform the affine
|
||||
transformation just before the glyph is rendered, as in the following
|
||||
code:</p>
|
||||
|
@ -1403,8 +1405,8 @@
|
|||
</ul>
|
||||
|
||||
<p>It is possible to call this function several times to render the
|
||||
string width different angles, or even change the way <tt>start</tt>
|
||||
is computed in order to move it to different place.</p>
|
||||
string with different angles, or even change the way <tt>start</tt>
|
||||
is computed in order to move it to a different place.</p>
|
||||
|
||||
<p>This code is the basis of the FreeType 2 demonstration program
|
||||
named <tt>ftstring.c</tt>. It could be easily extended to perform
|
||||
|
@ -1421,12 +1423,12 @@
|
|||
<hr>
|
||||
|
||||
<h3>
|
||||
6. Accessing metrics in design font units, and scaling them
|
||||
6. Accessing metrics in design font units and scaling them
|
||||
</h3>
|
||||
|
||||
<p>Scalable font formats usually store a single vectorial image, called
|
||||
an <em>outline</em>, for each in a face. Each outline is defined in an
|
||||
abstract grid called the <em>design space</em>, with coordinates
|
||||
an <em>outline</em>, for each glyph in a face. Each outline is defined
|
||||
in an abstract grid called the <em>design space</em>, with coordinates
|
||||
expressed in nominal <em>font units</em>. When a glyph image is loaded,
|
||||
the font driver usually scales the outline to device space according to
|
||||
the current character pixel size found in a <tt>FT_Size</tt> object.
|
||||
|
@ -1494,10 +1496,10 @@
|
|||
<tt>x_ppem</t>
|
||||
</td>
|
||||
<td>
|
||||
Which stands for "X Pixels Per EM"; this is the size in integer
|
||||
pixels of the EM square, which also is the <em>horizontal
|
||||
character pixel size</em>, called <tt>pixel_size_x</tt> in the
|
||||
above example.
|
||||
This is the size in integer pixels of the EM square, which also is
|
||||
the <em>horizontal character pixel size</em>, called
|
||||
<tt>pixel_size_x</tt> in the above example. <tt>x_ppem</tt> means
|
||||
"x pixels per EM".
|
||||
</td>
|
||||
</tr>
|
||||
<tr valign=top>
|
||||
|
@ -1505,10 +1507,10 @@
|
|||
<tt>y_ppem</tt>
|
||||
</td>
|
||||
<td>
|
||||
Which stands for "Y Pixels Per EM"; this is the size in integer
|
||||
pixels of the EM square, which also is the <em>vertical character
|
||||
pixel size</em>, called <tt>pixel_size_y</tt> in the above
|
||||
example.
|
||||
This is the size in integer pixels of the EM square, which also is
|
||||
the <em>vertical character pixel size</em>, called
|
||||
<tt>pixel_size_y</tt> in the above example. <tt>y_ppem</tt> means
|
||||
"y pixels per EM".
|
||||
</td>
|
||||
</tr>
|
||||
<tr valign=top>
|
||||
|
@ -1532,9 +1534,9 @@
|
|||
</table>
|
||||
</center>
|
||||
|
||||
<p>Basically, this means that you can scale a distance expressed in
|
||||
font units to 26.6 pixels directly with the help of the
|
||||
<tt>FT_MulFix()</tt> function, as in:</p>
|
||||
<p>You can scale a distance expressed in font units to 26.6 pixels
|
||||
directly with the help of the <tt>FT_MulFix()</tt> function, as
|
||||
in:</p>
|
||||
|
||||
<font color="blue">
|
||||
<pre>
|
||||
|
@ -1567,12 +1569,12 @@
|
|||
b. Accessing design metrics (glyph & global)
|
||||
</h4>
|
||||
|
||||
<p>You can access glyph metrics in font units simply by specifying the
|
||||
<p>You can access glyph metrics in font units by specifying the
|
||||
<tt>FT_LOAD_NO_SCALE</tt> bit flag in <tt>FT_Load_Glyph()</tt> or
|
||||
<tt>FT_Load_Char()</tt>. The metrics returned in
|
||||
<tt>face->glyph->metrics</tt> will then all be in font units.</p>
|
||||
|
||||
<p>You can access unscaled kerning data using the
|
||||
<p>Unscaled kerning data can be retrieved using the
|
||||
<tt>ft_kerning_mode_unscaled</tt> mode.</p>
|
||||
|
||||
<p>Finally, a few global metrics are available directly in font units
|
||||
|
@ -1590,9 +1592,8 @@
|
|||
render text much more intelligently (kerning, measuring, transforming
|
||||
& caching).</p>
|
||||
|
||||
<p>You have now sufficient knowledge to build a pretty decent text
|
||||
service on top of FreeType 2, and you could possibly stop there if
|
||||
you want.</p>
|
||||
<p>With this knowledge you can build a pretty decent text service on top
|
||||
of FreeType 2, and you could possibly stop there if you want.</p>
|
||||
|
||||
<p>The next section will deal with FreeType 2 internals (like
|
||||
modules, vector outlines, font drivers, renderers), as well as a few
|
||||
|
|
|
@ -359,9 +359,8 @@
|
|||
/* <Fields> */
|
||||
/* face :: A handle to the parent face object. */
|
||||
/* */
|
||||
/* flags :: A set of bit flags used to describe the charmap. */
|
||||
/* Each bit indicates that a given encoding is */
|
||||
/* supported. */
|
||||
/* encoding :: A tag which identifies the charmap. Use this with */
|
||||
/* FT_Select_Charmap(). */
|
||||
/* */
|
||||
/* platform_id :: An ID number describing the platform for the */
|
||||
/* following encoding ID. This comes directly from */
|
||||
|
|
|
@ -35,6 +35,9 @@
|
|||
#define TT_PLATFORM_ISO 2 /* deprecated */
|
||||
#define TT_PLATFORM_MICROSOFT 3
|
||||
|
||||
/* artificial values defined ad-hoc by FreeType */
|
||||
#define TT_PLATFORM_ADOBE 7
|
||||
|
||||
|
||||
/*************************************************************************/
|
||||
/* */
|
||||
|
@ -118,6 +121,19 @@
|
|||
#define TT_MS_ID_JOHAB 6
|
||||
|
||||
|
||||
/*************************************************************************/
|
||||
/* */
|
||||
/* possible values of the platform specific encoding identifier field in */
|
||||
/* the name records of the TTF `name' table if the `platform' identifier */
|
||||
/* code is TT_PLATFORM_ADOBE. */
|
||||
/* */
|
||||
/* These are artificial values defined ad-hoc by FreeType. */
|
||||
/* */
|
||||
#define TT_ADOBE_ID_STANDARD 0
|
||||
#define TT_ADOBE_ID_EXPERT 1
|
||||
#define TT_ADOBE_ID_CUSTOM 2
|
||||
|
||||
|
||||
/*************************************************************************/
|
||||
/* */
|
||||
/* Possible values of the language identifier field in the name records */
|
||||
|
|
Loading…
Reference in New Issue