font-kit

font-kit gives Rust developers a single API for the font tasks that are normally locked behind incompatible platform frameworks: finding installed fonts, matching them against CSS-style family/weight/stretch/style queries, loading TrueType/OpenType files from disk or memory, and rasterizing glyphs to a canvas. It ships loader and source backends for Core Text (macOS/iOS), DirectWrite (Windows), FreeType (cross-platform), and Fontconfig (Unix), which can be freely mixed at runtime — for example, looking a font up through the Windows system database and then rendering it with FreeType.

Originally built for Mozilla’s Pathfinder and Servo browser engine projects, font-kit implements the CSS Fonts Module Level 3 matching algorithm so font selection behaves the way a browser would, and exposes hinting, outline extraction, and metrics APIs for anyone building text rendering, layout, or design tooling in Rust. It’s a systems-level binding crate rather than a pure-Rust font stack, so fontconfig and FreeType support are opt-in via Cargo feature flags to keep default builds lean on macOS and Windows.

What You Get

• System font discovery via SystemSource, enumerating and querying every font installed on the host OS
• CSS Fonts Level 3-compliant font matching by family name, weight, stretch, and style
• Font loading from files, byte buffers, or native platform font handles, including TrueType/OpenType collections
• Glyph rasterization to a Canvas with optional hinting, plus glyph metrics and vector outline extraction
• Pluggable loader/source backends (Core Text, DirectWrite, FreeType, Fontconfig, filesystem, memory, multi-source) selectable via Cargo features

Common Use Cases

• Text rendering engines - projects like Pathfinder and Servo use font-kit to locate and rasterize glyphs without hand-rolling platform-specific font code
• Design and typography tools - apps that need to list installed fonts and preview them by family, weight, and style
• PDF and document generators - tools that embed or rasterize glyphs from system or bundled fonts for output
• Cross-platform GUI toolkits - frameworks that need consistent font lookup and rendering behavior across macOS, Windows, and Linux without per-platform branching

Under The Hood

Architecture font-kit separates concerns into two backend abstractions — a Loader trait (src/loader.rs) for parsing and rasterizing font files, and a Source trait (src/source.rs) for querying installed system fonts — with platform-specific implementations chosen at compile time via #[cfg] attributes in src/loaders/{core_text,directwrite,freetype}.rs and src/sources/{core_text,directwrite,fontconfig,fs,mem,multi}.rs. The public API funnels through Font (src/font.rs), which wraps whichever platform loader is active behind a common trait so callers write platform-agnostic code, while SystemSource in source.rs resolves to a concrete backend type per-platform. Font matching is kept independent of any backend: find_best_match in src/matching.rs implements the CSS Fonts Level 3 algorithm purely against Properties (weight/stretch/style) structs, and family_name.rs/family_handle.rs decouple family lookup from resolution. Because backend selection is compile-time cfg-based rather than a runtime trait object, changing the core Loader/Source trait shapes would ripple through every platform implementation, the examples, and the test suite.

Tech Stack Written in Rust (edition 2018, minimum Rust 1.77). Core dependencies are bitflags, byteorder, float-ord, libc, log, and Mozilla’s pathfinder_geometry/pathfinder_simd crates for vector math; freetype-sys and yeslogic-fontconfig-sys are pulled in as optional cross-platform backends. Platform-specific bindings add dwrote and winapi on Windows for DirectWrite, and core-foundation/core-graphics/core-text on macOS and iOS. There’s no async runtime or web framework here — this is a low-level FFI-heavy binding crate that shells out to native OS font APIs. CI builds and tests on Linux (with fontconfig/freetype and Microsoft core fonts installed via apt), macOS, and Windows runners, and enforces cargo fmt --check on Linux.

Code Quality Tests live in tests/tests.rs and tests/select_font.rs and exercise font loading, matching, rasterization, and metrics against real bundled font fixtures (EB Garamond, Inconsolata) rather than mocks, with platform- and feature-gated cases via #[cfg]. Error handling is explicit and typed throughout src/error.rs, with dedicated FontLoadingError, GlyphLoadingError, and SelectionError enums and a macro-generated Display impl rather than panics or string errors. Naming follows idiomatic Rust conventions, and #![warn(missing_docs)] plus #![warn(missing_debug_implementations)] lint attributes in lib.rs push extensive documentation and Debug coverage across the crate — comment density in src/ is high. CI enforces formatting but does not run clippy.

API Design font-kit’s core value is unifying four incompatible native font stacks behind one Rust API with loader/source combinations that can be freely mixed at runtime — looking a font up via DirectWrite and rendering it via FreeType, for instance — which is unusual among font crates that typically wrap a single backend. Its matching implementation follows the CSS Fonts Module Level 3 spec directly, giving browser-compatible nearest-match behavior for family/weight/stretch/style queries. The public surface reads naturally (SystemSource::new().select_best_match(...).load()), with Handle abstracting over path- and memory-backed fonts and Properties providing one struct for style matching. The tradeoff is real: consumers must reason about Cargo feature flags (source-fontconfig, loader-freetype, etc.) to get the backend combination they want on each platform, and it deliberately stays out of font shaping, leaving that to other crates.