Supported font formats
FreeType 2 readily supports the following font formats:
- TrueType files (.ttf) and collections (.ttc)
- Type 1 font files both in ASCII (.pfa) or binary (.pfb) format
- Type 1 Multiple Master fonts. The FreeType 2 API also provides
routines to manage design instances easily
- Type 1 CID-keyed fonts
- OpenType/CFF (.otf) fonts
- CFF/Type 2 fonts
- Adobe CEF fonts (.cef), used to embed fonts in SVG documents
with the Adobe SVG viewer plugin.
- Windows FNT/FON bitmap fonts
Note that Apple's TrueType GX fonts are supported as normal TTFs,
(the advanced tables are ignored).
Besides, it's possible to add support for new font formats by providing
a specific font driver module. Modules can be added either at
build time (when recompiling the library), or at run-time;
this allows, for example, applications to register their own
font driver to support program-specific formats.
Patent-free automatic hinter
TrueType fonts are normally renderered (hinted) with the help of a
specific bytecode where the behaviour of a few opcodes is patented by
Apple. We're currently in contact with Apple to discuss the importance
of such patents and their use in open source projects like FreeType.
In the meantime, we have developped our own alternative technology that
is capable of automatically hinting scalable glyph images. It is
now part of the FreeType 2 source tree as the "autohint" module,
and is used to hint glyphs when the bytecode interpreter is disabled
(through a configuration macro when building the engine). Note that
the auto-hinter is also used to handle glyphs in other formats like
CFF and Type 1.
The auto-hinter provides pretty good results (in some cases, it even
significantly improves the output of poorly hinted fonts) but we'll
continue to improve it with each new release of FreeType to achieve
the highest possible quality.
Modular design:
The design of FreeType 2 is extremely modular as most features are
supported through optional modules. This means it's easily possible to
only compile the features you need. As each module is between
10 and 20 Kb in size, it's possible to build a bare-bones
font engine that supports anti-aliasing in about 30 Kb !!
Configuration is performed by modifications of only two header
files (one to select global features, another one to select modules)
and don't need tweaking of source code. Note that it is however
possible to provide your own implementation of certain components.
For example, when building on Unix, the engine will automatically
use memory-mapped files when available on the target platform,
thus significantly increasing font file i/o.
Due to its very flexible design, it is possible to add, remove and
upgrade modules at run-time.
Advanced glyph management
The API comes with a standard extension used to extract individual
glyph images from font files. These images can be bitmaps, scalable
bezier outlines or even anything else. (e.g. bi-color or metafont
glyphs, as long as they're supported by a module).
Each scalable glyph image can be transformed, measured and
rendered into a monochrome or anti-aliased bitmaps easily
through a uniform interface.
This allows client applications to easily cache glyphs or
perform text rendering effects with minimal difficulty
(look at the FreeType 2 Tutorial to see how to render
rotated text with very few lines of code).
Advanced font access
The FreeType 2 API is useful to retrieve advanced information from
various fonts:
- vertical metrics are available whenever found in the font file
- kerning distances are available when found in the font file. It
is also possible to "attach" a given additional file to a given
font face. This is useful to load kerning distances from an
.afm file into a Type 1 face for example.
- provides ASCII glyph names whenever available in the font
(TrueType, OpenType, Type1, etc..)
- provides access to important tables for SFNT-based font formats
(i.e. TrueType, OpenType, CEF, etc..), like the name table,
font header, maximum profile, etc...
- automatic synthesis of Unicode-based character maps for
those fonts or formats that do not provide one. This is
extremely useful with Type 1 fonts which are normally
limited to a stupid 256-characters encoding.
Simple & clean API
The FreeType 2 high-level API is simple and straightforward, as it
has been specifically designed to make the most commmon font operations
easy
As a comparison, the number of function calls needed to perform a
the tasks of font face creation/opening and glyph loading/rendering
has been reduced by a factor of 4 !!
The API is also independent of any font-format specific issue, though
it provides standard extensions to access format-specific tables and
information. More extensions can also be easily added through new
modules
Robust & Portable code
Because it is written in industry-standard ANSI C, FreeType 2 compiles
on all platforms with a compliant compiler. Because the default build
only relies on the C library, it is free of any system-specific
dependencies, even if it is possible to "enhance" certain components
by providing a specific implementation.
The code doesn't use global or static variables. Client applications
can provide their own memory manager. Font files can be read from
a disk file, memory, or through a client-provided input stream. This
allows to support compressed font files, remote fonts, fonts embedded
in other streams (e.g. Type42 fonts), etc..
An advanced i/o sub-system is used to optimise file access, as well
as reduce memory usage of the library when the file is memory-based
( ROM, RAM, memory-mapped ).
Open Source & Vendor Independence
Finally, FreeType 2 is released under its own BSD-like open source
license, one of the less restricting licenses available, and this
means that:
It can be included in all kinds of products, be they proprietary
or not.
As any module can be added or replaced anytime, any third party
vendor has the ability to provide its own set of modules (under
its own license) in order to support proprietary font formats or
more advanced features (e.g. a new auto-hinter, or a new
anti-aliasing renderer for LCDs or TV screens).
One could even imagine an application using the FreeType 2 API with
a "wrapper" module used to access system-specific fonts (like through
the Windows GDI). This would mean native font support with more portable
application code (as simply changing the wrapper module would be required
to port the application to another system).
| 