The FreeType 2 FAQ

I.1. I though the FreeType project was dead. Is this true?

Well, not exactly :-) It's true that the TrueType patents issues have been less than a graceful event to handle but it didn't not really killed the project per se, as Apple hasn't made an official statement yet regarding the use of the patented "technology" in open source projects (or other products).

We have thus continued updating FreeType 1.x, and started developping FreeType 2 with the idea of providing this time a completely patent free font engine. However, we largely preferred not to broadly communicate about it until we've got a satisfying implementation to show.

I.2. Why did it take so long to release FreeType 2?

I.3. Is FreeType 2 a Unix-only project?

I.4. When will X11/XFree support anti-aliased text?

This question isn't exactly related to FreeType as we have no direct connection to the XFree people, but we've been asked so frequently about it that it deserves a prominent place in this FAQ :-)

FreeType has been capable of anti-aliasing since version 1.0. The reason why XFree doesn't support it is directly related to the limitations of the design and specification of X11. More specifically:

• X11 assumes that all glyph images are monochrome bitmaps, hence the X font library and server are unable to send anything else to the X server.

• Even if the X font library/server was able to generate anti-aliased bitmaps (and this has been already done through extensions), the X rendering model doesn't allow translucent composition of "gray" pixmaps onto an arbitrary drawable.

As both the font and rendering models of X11 are limited, it's basically impossible to draw anti-aliased glyphs without performing huge hacks within the server.

Note that Keith Packard, from XFree fame, has recently started working on a new rendering model for X11 in order to support new features (mainly transparency and anti-aliased fonts). This will be provided through protocol extensions. The question of knowing wether legacy X applications will be able to display anti-aliased text is still very uncertain.

I.5. Is FreeType 2 backwards compatible with FreeType 1.x?

Not directly, though we had the project to provide an optional binary compatibility layer on top of it in order to easily re-link applications with the new version. However, this idea has been dropped as it is possible to install and use the two versions independtly on any system (read: no namespace conflicts).

The FreeType 2 API is a lot simpler than the one in 1.x while being much more powerful. We thus encourage you to adapt your source code to it as this should not involve much work.

I.6. Can I use FreeType 2 to edit fonts or create new ones?

The answer is a definitive NO, because the library was specifically designed to read font files with small code size and very low memory usage.

We thus do not plan to support editing or creation in the font engine in any way, as this would imply a complete rewrite. This doesn't mean that we won't introduce a font editing/creation library in the future, as this really depends on how many people are asking for it (or how much they would be willing to pay for it), as well as the time of the FreeType developers.

Do not expect anything in this direction until we officially announce something though. There are other axis of development for this project (like text-layout capabilities, glyph caching, etc..) that may be more important to us at the moment..

II.1. How do I compile the FreeType 2 library?

The library can be compiled in various ways, and a detailed documentation is available in the file "freetype2/docs/BUILD". However, we'll summarize the process to a few cases:

a. by using the command-line 2 build system

The engine comes with a sophisticated build system that is used to configure and compile a build of the library. You'll need GNU Make installed on your platform (NOTE: It will not work with other Make tools).

Basically, you'll need to invoke make a first time in the top-level FreeType 2 directory in order to setup the build. This will detect your current platform and choose a configuration sub-makefile to drive the build. A specific compiler can be selected on some platforms by providing an additional target. For example, on Win32:

• make visualc will select the Visual C++ compiler
• make lcc will select the Win32-lcc compiler

Note that on Unix, the first time make is called, a configure script located in "freetype2/builds/unix" will be run in order to automatically detect the platform & compiler.

A summary will be displayed showing the detected platform and compiler selected. You'll then be able to start the build by invoking make a second time. In case of problem, consult the BUILD document.

b. by direct compilation

You can also directly compile the library from the command line by using these simple rules:

• You should place the directories "freetype2/include" and "freetype2/src" in your include path in order to compile any component of the library. You can also add the system-specific build directory (i.e. "builds/system/") in the case where an alternate implementation of some of the components is available there (e.g. the memory-mapped i/o implementation on some Unix systems).

• The components of the library are located in sub-directories of "src", for example: "src/base", "src/truetype", etc..

• Each component is normally compiled through a single C file that "wraps" other sources in the component's directory. For example, your should compile the TrueType font driver by compiling the file "src/truetype/truetype.c". The list of C files to compile for a feature-complete build of the library is given in the BUILD document.

c. in a graphical IDE

Well, the process is vastly similar to the one described in b., except that you need to set the include paths, source code paths, etc.. in dialog boxes before running the compilation.

II.2. How do I configure my build of the library?

Each build of the library is configured through two header files located in "include/freetype/config":

• ftoption.h
  This file contains various configuration macros whose definition can be toggled on a per-build basis. Each macro is heavily commented in this file's comment, and we invite you to refer to it directly.

• ftmodule.h
  This file contains the list of all the modules that are initially registered (added) when the function FT_Init_FreeType is called. See the next answer to know how to change it and why it may be important.

Alternatively, some specific implementations of some FT2 components can be provided in a "builds/system/" directory (e.g. the Unix-specific ftsystem.c that uses memory-mapped file for i/o).

II.3. How do I select the modules I need in my build?

The function FT_Init_FreeType creates a new instance of the FT2 library and registers a set of "default" modules before returning to the calling application. Its default implementation is in the file "src/base/ftinit.c".

The list of default modules used by ftinit.c is located in the configuration file "include/freetype/config/ftmodule.h". It is normally automatically generated by the build system by invoking the "make modules" command in the top level FT2 directory (note: only works with GNU Make, you can edit the file by hand otherwise). It does so by parsing all sub-directories of "src" that contain a file named module.mk.

Note that a specific port or project is free to provide its own implementation of ftinit.c in order to ensure a different initialisation sequence. For example, one could do something like:

• compile each module as a shared library (DLL or .so) with a common "entry point" to retrieve a pointer to its module class (there is already some code that allows this when compiling each module).

• place these modules in a directory like "/usr/lib/freetype2/modules/"

• provide an implementation of ftinit.c that would scan the directory for valid modules.

This example only emphasize the flexibility that is left to developers when building the library.

II.4. How do I compile all FreeType 2 files in a single directory?

Some projects may need, for the sake of simplicity or ease of building, to compile the FT2 library with all source files copied to a single directory. This is possible.

To do so, you'll need to copy all source files located under "src" to your own directory (you must retain the include files in a distinct hierarchy though), then compile each of the FreeType 2 component with the macro FT_FLAT_COMPILE. This will change the way #include works during the build.

IV.1. Under which license is the FreeType 2 auto-hinter released

IV.2. How does the auto-hinter works ?

IV.3. Why does the auto-hinter doesn't work correctly with CJK fonts ?

The auto-hinter was first designed to manage and hint latin-based fonts, as they consist of most of the fonts available today. It doesn't hint asian fonts, as well as a few other complex scripts, because we didn't put enough research on the topic yet. Hinting CJK isn't really more difficult than latin, just different with a set of different constraints (basically, more distortion of glyphs is acceptable as long as certain features like triple-stem positions are respected more strictly..).

We thus plan to handle such a case rather rapidly.. Please be patient.

V.1. What is the anti-aliasing algorithm used by FreeType 2 ?

V.2. When will FreeType 2 support OpenType ?

Well, the engine already reads OpenType/CFF files perfectly. What it doesn't do is handle "OpenType Layout" tables yet.

FreeType 1 comes with a set of extensions that are used to load and manage OpenType Layout tables. It even has a demonstration program named "ftstrtto" used to demonstrate its capabilities that runs pretty smooth.

For FreeType 2, we have decided that the layout operations provided through these tables is better placed in a specific text-layout library, (many people having asked for such a thing). This new engine would not depend on FT2 explicitely and will be developed as a separate project. We plan to announce it in a few weeks with all gory details, once the definitive 2.0 release of FreeType has been made.