fontdb is a simple, in-memory font database with CSS-like queries.
- The database can load fonts from files, directories and raw data (
- The database can match a font using CSS-like queries. See
- The database can try to load system fonts. Currently, this is implemented by scanning predefined directories. The library does not interact with the system API.
- Provides a unique ID for each font face.
Advanced font properties querying.
The database provides only storage and matching capabilities. For font properties querying you can use ttf-parser.
A font fallback mechanism.
This library can be used to implement a font fallback mechanism, but it doesn’t implement one.
Application’s global database.
The database doesn’t use
static, therefore it’s up to the caller where it should be stored.
Font types support other than TrueType.
A font is a collection of font faces. Therefore, a font face is a subset of a font. A simple font (*.ttf/*.otf) usually contains a single font face, but a font collection (*.ttc) can contain multiple font faces.
fontdb stores and matches font faces, not fonts.
Therefore, after loading a font collection with 5 faces (for example), the database will be populated
FaceInfo objects, all of which will be pointing to the same file or binary data.
The database performance is largely limited by the storage itself. We are using ttf-parser, so the parsing should not be a bottleneck.
On my machine with Samsung SSD 860 and Gentoo Linux, it takes ~20ms to load 1906 font faces (most of them are from Google Noto collection) with a hot disk cache and ~860ms with a cold one.
The library relies on memory-mapped files, which is inherently unsafe. But we do not keep such files open forever. Instead, we are memory-mapping files only when needed.
A font database.
A single font face info.
A unique per database face ID.
A database query.
Specifies the weight of glyphs in the font, their degree of blackness or stroke thickness.
A font family.
A font source.
A font width.
Allows italic or oblique faces to be selected.