Introduction
This is the first section of the FreeType 2 tutorial. It will teach you how to:
- initialize the library
- open a font file by creating a new face object
- select a character size in points or in pixels
- load a single glyph image and convert it to a bitmap
- render a very simple string of text
- render a rotated string of text easily
1. Header files
The following are instructions required to compile an application that uses the FreeType 2 library.
-
Locate the FreeType 2 include directory.
You have to add it to your compilation include path.
Note that on Unix systems, you can now run the freetype-config script with the --cflags option to retrieve the appropriate compilation flags. This script can also be used to check the version of the library that is installed on your system, as well as the required librarian and linker flags.
-
Include the file named ft2build.h.
It contains various macro declarations that are later used to #include the appropriate public FreeType 2 header files.
-
Include the main FreeType 2 API header file.
You should do that using the macro FT_FREETYPE_H, like in the following example:
#include <ft2build.h> #include FT_FREETYPE_HFT_FREETYPE_H is a special macro defined in the file ftheader.h. It contains some installation-specific macros to name other public header files of the FreeType 2 API.
You can read this section of the FreeType 2 API Reference for a complete listing of the header macros.
The use of macros in #include statements is ANSI-compliant. It is used for several reasons:
-
It avoids some painful conflicts with the FreeType 1.x public header files.
-
The macro names are not limited to the DOS 8.3 file naming limit; names like FT_MULTIPLE_MASTERS_H or FT_SFNT_NAMES_H are a lot more readable and explanatory than the real file names ftmm.h and ftsnames.h.
-
It allows special installation tricks that will not be discussed here.
NOTE: Starting with FreeType 2.1.6, the old header file inclusion scheme is no longer supported. This means that you now get an error if you do something like the following:
2. Initialize the library
Simply create a variable of type FT_Library named, for example, library, and call the function FT_Init_FreeType as in
This function is in charge of the following:
-
It creates a new instance of the FreeType 2 library, and sets the handle library to it.
-
It loads each module that FreeType knows about in the library. Among others, your new library object is able to handle TrueType, Type 1, CID-keyed & OpenType/CFF fonts gracefully.
As you can see, the function returns an error code, like most others in the FreeType API. An error code of 0 always means that the operation was successful; otherwise, the value describes the error, and library is set to NULL.
3. Load a font face
a. From a font file
Create a new face object by calling FT_New_Face. A face describes a given typeface and style. For example, ‘Times New Roman Regular’ and ‘Times New Roman Italic’ correspond to two different faces.
As you can certainly imagine, FT_New_Face opens a font file, then tries to extract one face from it. Its parameters are
| library | A handle to the FreeType library instance where the face object is created. |
| filepathname | The font file pathname (a standard C string). |
| face_index | Certain font formats allow several font faces to be embedded in a single file. This index tells which face you want to load. An error will be returned if its value is too large. Index 0 always work though. |
| face | A pointer to the handle that will be set to describe the new face object. It is set to NULL in case of error. |
To know how many faces a given font file contains, simply load its first face (this is, face_index should be set to zero), then check the value of face->num_faces which indicates how many faces are embedded in the font file.
b. From memory
In the case where you have already loaded the font file into memory, you can similarly create a new face object for it by calling FT_New_Memory_Face as in
As you can see, FT_New_Memory_Face 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 FT_New_Face.
Note that you must not deallocate the memory before calling FT_Done_Face.
c. From other sources (compressed files, network, etc.)
There are cases where using a file pathname or preloading the file into memory is simply not sufficient. With FreeType 2, it is possible to provide your own implementation of i/o routines.
This is done through the FT_Open_Face 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.
4. Accessing face content
A face object models all information that globally describes the face. Usually, this data can be accessed directly by dereferencing a handle, like in face−>num_glyphs.
The complete list of available fields in in the FT_FaceRec structure description. However, we describe here a few of them in more details:
| num_glyphs | This variable gives the number of glyphs available in the font face. A glyph is simply a character image. It doesn't necessarily correspond to a character code though. |
| face_flags | A 32-bit integer containing bit flags used to describe some face properties. For example, the flag FT_FACE_FLAG_SCALABLE is used to indicate that the face's font format is scalable and that glyph images can be rendered for all character pixel sizes. For more information on face flags, please read the FreeType 2 API Reference. |
| units_per_EM | This field is only valid for scalable formats (it is set to 0 otherwise). It indicates the number of font units covered by the EM. |
| num_fixed_sizes | This field gives the number of embedded bitmap strikes in the current face. A strike is simply a series of glyph images for a given character pixel size. For example, a font face could include strikes for pixel sizes 10, 12 and 14. Note that even scalable font formats can have embedded bitmap strikes! |
| available_sizes | A pointer to an array of FT_Bitmap_Size elements. Each FT_Bitmap_Size indicates the horizontal and vertical character pixel sizes for each of the strikes that are present in the face. Note that, generally speaking, these are not the cell size of the bitmap strikes. |
5. Setting the current pixel size
FreeType 2 uses size objects to model all information related to a given character size for a given face. For example, a size object will hold the value of certain metrics like the ascender or text height, expressed in 1/64th of a pixel, for a character size of 12 points.
When the FT_New_Face function is called (or one of its cousins), it automatically creates a new size object for the returned face. This size object is directly accessible as face−>size.
NOTE: A single face object can deal with one or more size objects at a time; however, this is something that few programmers really need to do. We have thus decided to simplify the API for the most common use (i.e., one size per face) while keeping this feature available through additional functions.
When a new face object is created, all elements are set to 0 during initialization. To populate the structure with sensible values, simply call FT_Set_Char_Size. Here is an example where the character size is set to 16pt for a 300×300dpi device:
Some notes:
-
The character widths and heights are specified in 1/64th of points. A point is a physical distance, equaling 1/72th of an inch. Normally, it is not equivalent to a pixel.
-
A value of 0 for the character width means ‘same as character height’, a value of 0 for the character height means ‘same as character width’. Otherwise, it is possible to specify different character widths and heights.
-
The horizontal and vertical device resolutions are expressed in dots-per-inch, or dpi. Normal values are 72 or 96 dpi for display devices like the screen. The resolution is used to compute the character pixel size from the character point size.
-
A value of 0 for the horizontal resolution means ‘same as vertical resolution’, a value of 0 for the vertical resolution means ‘same as horizontal resolution’. If both values are zero, 72 dpi is used for both dimensions.
-
The first argument is a handle to a face object, not a size object.
This function computes the character pixel size that corresponds to the character width and height and device resolutions. However, if you want to specify the pixel sizes yourself, you can simply call FT_Set_Pixel_Sizes, as in
This example will set the character pixel sizes to 16×16 pixels. As previously, a value of 0 for one of the dimensions means ‘same as the other’.
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 face->fixed_sizes array.
6. Loading a glyph image
a. Converting a character code into a glyph index
Usually, an application wants to load a glyph image based on its character code, which is a unique value that defines the character for a given encoding. For example, the character code 65 represents the ‘A’ in ASCII encoding.
A face object contains one or more tables, called charmaps, that are used to convert character codes to glyph indices. For example, most TrueType fonts contain two charmaps. One is used to convert Unicode character codes to glyph indices, the other is used to convert Apple Roman encoding into glyph indices. Such fonts can then be used either on Windows (which uses Unicode) and Macintosh (which uses Apple Roman). Note also that a given charmap might not map to all the glyphs present in the font.
By default, when a new face object is created, it selects a Unicode charmap. FreeType tries to emulate a Unicode charmap if the font doesn't contain such a charmap, based on glyph names. Note that it is possible that the emulation misses glyphs if glyph names are non-standard. For some fonts, including symbol fonts and (older) fonts for Asian scripts, no Unicode emulation is possible at all.
We will describe later how to look for specific charmaps in a face. For now, we will assume that the face contains at least a Unicode charmap that was selected during a call to FT_New_Face. To convert a Unicode character code to a font glyph index, we use FT_Get_Char_Index, as in
This will look up the glyph index corresponding to the given charcode in the charmap that is currently selected for the face. You should use the UTF-32 representation form of Unicode; for example, if you want to load character U+1F028, use value 0x1F028 as the value for charcode.
If no charmap was selected, the function simply returns the charcode.
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 missing glyph, which is commonly displayed as a box or a space.
b. Loading a glyph from the face
Once you have a glyph index, you can load the corresponding glyph 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 outlines to describe each glyph. Some formats may have even more exotic ways of representing glyphs (e.g., MetaFont — but this format is not supported). Fortunately, FreeType 2 is flexible enough to support any kind of glyph format through a simple API.
The glyph image is always stored in a special object called a glyph slot. As its name suggests, a glyph slot is simply a container that is able to hold one glyph image at a time, be it a bitmap, an outline, or something else. Each face object has a single glyph slot object that can be accessed as face->glyph. Its fields are explained by the FT_GlyphSlotRec structure documentation.
Loading a glyph image into the slot is performed by calling FT_Load_Glyph as in
The load_flags value is a set of bit flags used to indicate some special operations. The default value FT_LOAD_DEFAULT is 0.
This function will try to load the corresponding glyph image from the face:
-
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 FT_LOAD_NO_BITMAP flag.
-
Otherwise, a native image for the glyph will be loaded. It will also be scaled to the current pixel size, as well as hinted for certain formats like TrueType and Type 1.
The field face−>glyph−>format describes the format used to store the glyph image in the slot. If it is not FT_GLYPH_FORMAT_BITMAP, one can immediately convert it to a bitmap through FT_Render_Glyph as in:
The parameter render_mode is a set of bit flags used to specify how to render the glyph image. Set it to FT_RENDER_MODE_NORMAL to render a high-quality anti-aliased (256 gray levels) bitmap, as this is the default. You can alternatively use FT_RENDER_MODE_MONO if you want to generate a 1-bit monochrome bitmap.
Once you have a bitmapped glyph image, you can access it directly through glyph->bitmap (a simple bitmap descriptor), and position it through glyph->bitmap_left and glyph->bitmap_top.
Note that bitmap_left is the horizontal distance from the current pen position to the leftmost border of the glyph bitmap, while bitmap_top is the vertical distance from the pen position (on the baseline) to the topmost border of the glyph bitmap. It is positive to indicate an upwards distance.
The next section will give more details on the contents of a glyph slot and how to access specific glyph information (including metrics).
c. Using other charmaps
As said before, when a new face object is created, it will look for a Unicode charmap and select it. The currently selected charmap is accessed via face->charmap. This field is NULL when no charmap is selected, which typically happens when you create a new FT_Face object from a font file that doesn't contain a Unicode charmap (which is rather infrequent today).
There are two ways to select a different charmap with FreeType 2. The easiest is when the encoding you need already has a corresponding enumeration defined in FT_FREETYPE_H, for example FT_ENCODING_BIG5. In this case, you can simply call FT_Select_CharMap as in:
Another way is to manually parse the list of charmaps for the face; this is accessible through the fields num_charmaps and charmaps (notice the ‘s&rsquo) of the face object. As you could expect, the first is the number of charmaps in the face, while the second is a table of pointers to the charmaps embedded in the face.
Each charmap has a few visible fields used to describe it more precisely. Mainly, one will look at charmap->platform_id and charmap->encoding_id that define a pair of values that can be used to describe the charmap in a rather generic way.
Each value pair corresponds to a given encoding. For example, the pair (3,1) corresponds to Unicode. The list is defined in the TrueType specification but you can also use the file FT_TRUETYPE_IDS_H which defines several helpful constants to deal with them.
To select a specific encoding, you need to find a corresponding value pair in the specification, then look for it in the charmaps list. Don't forget that there are encodings which correspond to several value pairs due to historical reasons. Here some code to do it:
Once a charmap has been selected, either through FT_Select_CharMap or FT_Set_CharMap, it is used by all subsequent calls to FT_Get_Char_Index.
d. Glyph transformations
It is possible to specify an affine transformation to be applied to glyph images when they are loaded. Of course, this will only work for scalable (vectorial) font formats.
To do that, simply call FT_Set_Transform, as in:
This function will set the current transform for a given face object. Its second parameter is a pointer to a simple FT_Matrix structure that describes a 2×2 affine matrix. The third parameter is a pointer to a FT_Vector structure that describes a simple two-dimensional vector that is used to translate the glyph image after the 2×2 transformation.
Note that the matrix pointer can be set to NULL, in which case the identity transform will be used. Coefficients of the matrix are otherwise in 16.16 fixed-point units.
The vector pointer can also be set to NULL (in which case a delta of (0,0) will be used). The vector coordinates are expressed in 1/64th of a pixel (also known as 26.6 fixed-point numbers).
NOTE: The transformation is applied to every glyph that is loaded through FT_Load_Glyph and is completely independent of any hinting process. 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 of 12 pixels scaled by 2 through a transform, because the hints will have been computed differently (except you have disabled hints).
If you ever need to use a non-orthogonal transformation with optimal hints, you first have to decompose your transformation into a scaling part and a rotation/shearing part. Use the scaling part to compute a new character pixel size, then the other one to call FT_Set_Transform. This is explained in details in a later section of this tutorial.
NOTE2: Rotation usually disables hinting.
Loading a glyph bitmap with a non-identity transformation works; the transformation is ignored in this case.
7. Simple text rendering
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.
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 surface, then increment the current pen position.
a. Basic code
The following code performs our simple text rendering with the functions previously described.
This code needs a few explanations:
-
We define a handle named slot that points to the face object's glyph slot. (The type FT_GlyphSlot is a pointer). That is a convenience to avoid using face->glyph->XXX every time.
-
We increment the pen position with the vector slot->advance, which correspond to the glyph's advance width (also known as its escapement). The advance vector is expressed in 1/64th of pixels, and is truncated to integer pixels on each iteration.
-
The function my_draw_bitmap 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 FT_Bitmap descriptor and the position of its top-left corner as arguments.
-
The value of slot->bitmap_top is positive for an upwards vertical distance. Assuming that the coordinates taken by my_draw_bitmap use the opposite convention (increasing Y corresponds to downwards scanlines), we subtract it from pen_y, instead of adding to it.
b. Refined code
The following code is a refined version of the example above. It uses features and functions of FreeType 2 that have not yet been introduced, and which are explained below:
We have reduced the size of our code, but it does exactly the same thing:
-
We use the function FT_Load_Char instead of FT_Load_Glyph. As you probably imagine, it is equivalent to calling FT_Get_Char_Index then FT_Load_Glyph.
-
We do not use FT_LOAD_DEFAULT for the loading mode, but the bit flag FT_LOAD_RENDER. It indicates that the glyph image must be immediately converted to an anti-aliased bitmap. This is of course a shortcut that avoids calling FT_Render_Glyph explicitly but is strictly equivalent.
Note that you can also specify that you want a monochrome bitmap instead by using the addition FT_LOAD_MONOCHROME load flag.
c. More advanced rendering
Let us try to render transformed text now (for example through a rotation). We can do this using FT_Set_Transform. Here is how to do it:
Some remarks:
-
We now use a vector of type FT_Vector to store the pen position, with coordinates expressed as 1/64th of pixels, hence a multiplication. The position is expressed in cartesian space.
-
Glyph images are always loaded, transformed, and described in the cartesian coordinate system in FreeType (which means that increasing Y corresponds to upper scanlines), unlike the system typically used for bitmaps (where the topmost scanline has coordinate 0). We must thus convert between the two systems when we define the pen position, and when we compute the topleft position of the bitmap.
-
We set the transformation on each glyph to indicate the rotation matrix as well as a delta that will move the transformed image to the current pen position (in cartesian space, not bitmap space).
As a consequence, the values of bitmap_left and bitmap_top correspond to the bitmap origin in target space pixels. We thus don't add pen.x or pen.y to their values when calling my_draw_bitmap.
-
The advance width is always returned transformed, which is why it can be directly added to the current pen position. Note that it is not rounded this time.
A complete source code example can be found here.
It is important to note that, while this example is a bit more complex than the previous one, it is strictly equivalent for the case where the transform is the identity. Hence it can be used as a replacement (but a more powerful one).
It has however a few shortcomings that we will explain, and solve, in the next part of this tutorial.
Conclusion
In this first section, you have learned the basics of FreeType 2, as well as sufficient knowledge how to render rotated text.
The next section 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.
The third section will discuss issues like modules, caching and a few other advanced topics like how to use multiple size objects with a single face. [This part hasn't been written yet.]
FreeType 2 Tutorial Step 2
扫一扫
1466
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
