SixLabors.Fonts: the managed font engine

SixLabors.Fonts is the font engine of the ImageSharp ecosystem, and it makes an unusual promise: everything the classic C stack does (load a font, shape text, lay it out) in pure managed C#, with no native dependencies, behaving identically on every operating system. This post is a breakout from our text renderers survey, and it is based on reading the library’s source (517 C# files, current stable release v3.2.0) rather than its marketing: what it genuinely supports, what it verifiably does not, and where that leaves it against FreeType and SkiaSharp.

What it is

Fonts itself never touches a pixel. It loads font files, shapes strings into positioned glyphs, performs layout (line breaking, bidirectional ordering, justification, fallback), and walks the result emitting path and paint commands through an IGlyphRenderer interface. Its sibling library, SixLabors.ImageSharp.Drawing, implements that interface with a CPU scanline antialiasing rasterizer. The pair is the product; Fonts alone is three quarters of a renderer.

What it supports (verified in the code)

Formats: TrueType and TTC, OpenType with CFF1 and CFF2 outlines, WOFF, and WOFF2 (with its own glyph loader). If a font was made in the last thirty years for screen use, it opens.

Variable fonts, completely: fvar, gvar, cvar, avar, the variation metrics tables, CFF2 blending, named instances, and feature variations. This is the full OpenType variations model, not the read-the-axes subset some libraries ship.

Color fonts, the vector kind: COLR v0 and CPAL, and COLR v1 with its full paint graph (gradients, clips, composites) implemented as a real paint tree, plus the SVG-in-OpenType table (parsed and handed to the renderer). The current COLRv1 build of Noto Color Emoji renders through it.

Hinting, really: a complete TrueType bytecode interpreter executing fpgm, prep, and per-glyph programs. Its standard mode documents itself as matching FreeType’s v40 semantics (horizontal instruction moves suppressed, vertical processing kept), and its full mode matches v35 grayscale behavior. The common claim that this library “has no hinting” is years out of date; the interpreter is in the tree and shipped. CFF stem hinting is handled as well.

Shaping, its own: a GSUB/GPOS engine covering lookup types 1 to 9, the kern table, and dedicated shapers for Arabic, Indic, Hangul, Hebrew, Khmer, Myanmar (including Zawgyi), and Thai, plus the Universal Shaping Engine for everything else, with its own UAX 9 bidi implementation. Around shaping it adds what FreeType pointedly never offers: UAX 14 line breaking with wrapping, trimming, ellipsis, and hyphenation, vertical text layout, built-in font fallback that reports which font each glyph resolved to, and interaction metrics (advances, ink bounds, caret placement, hit testing, selection geometry) with a reusable prepared layout object.

The three real limitations

1. No bitmap fonts, of any kind, at all. Search the source tree for sbix, CBDT, CBLC, EBDT, or strike and you find nothing. The consequences are specific: Apple Color Emoji (sbix) cannot be rendered, and neither can CBDT builds of Noto Color Emoji. Vector color is fine; bitmap color does not exist. For a service that renders emoji specimens, this is the single biggest hole in the library.

2. No legacy formats. No Type 1 (PFA/PFB), no EOT, no BDF, PCF, or Windows FNT. FreeType loads all of them without blinking. Anything from the pre-OpenType era is out of scope by design, which matters more than it sounds: archives, old font CDs, and the long tail of 1990s files are exactly where Type 1 lives.

3. No pixels and no auto-hinter. The rasterizer belongs to the sibling library, is CPU scanline (competent, but no GPU path and no subpixel LCD text rendering), and there is no equivalent of FreeType’s auto-hinter: hinted fonts are handled properly by the interpreter, but unhinted fonts get nothing synthetic, which shows at small UI text sizes and hardly at all at specimen sizes. Throughput is the open question this post will not fake: a managed library with a CPU rasterizer should be expected to trail FreeType and Skia in raw rendering speed until your own benchmarks say otherwise.

There is also a maturity caveat rather than a missing feature: the shaping engine is genuinely complete on paper, but HarfBuzz carries roughly two more decades of per-script fixes and a far larger conformance corpus. Newer is cleaner; older is battle-tested.

Against the alternatives

Versus FreeType: Fonts wins on scope (shaping, bidi, fallback, and layout that FreeType refuses to do; you would otherwise add HarfBuzz, FriBidi, and your own glue) and loses on formats, bitmap color, the auto-hinter, and C throughput. As the font layer of a modern stack it is a substantial replacement; as a total replacement it is not, yet.

Versus SkiaSharp: not the same category. Skia is a full 2D engine with GPU rasterization, native platform font backends, bitmap color fonts, and HarfBuzz shaping; Fonts plus ImageSharp.Drawing replaces only the text-shaped slice of it, in exchange for zero native dependencies and identical behavior on every OS.

Versus the wrapper libraries (libraqm, Pango, cosmic-text, from the survey): those assemble the C or Rust commons; SixLabors reimplements the category in managed code. Same job description, opposite philosophy.

The licensing catch

Six Labors uses its own Split License: the libraries are Apache 2.0 when consumed by an open source project, as a transitive dependency, by a non-profit, or by a for-profit under 1M USD annual gross revenue as a direct dependency. Everyone else needs the paid Six Labors Commercial License. A commercial service taking Fonts as a direct dependency should assume it is in paid territory and price that in; it is the only entry in the survey whose “open source” status comes with a revenue clause.

Verdict

For a .NET rendering service (a specimen pipeline, a document generator, a font tool), SixLabors.Fonts is credible as the primary engine today: modern formats, variable fonts, COLRv1, real hinting, and real shaping in one managed codebase, with consistency across operating systems that native stacks cannot offer. Pair it with a FreeType or Skia path for the three things it cannot do: bitmap color fonts, Type 1 and other legacy files, and workloads where raster throughput is the whole game. That is a smaller list of exceptions than this library had any right to expect five years ago, and the honest summary of where it stands: not a curiosity anymore, and not quite the whole story.