FreeType is a freely available software library to render fonts.

It is written in C, designed to be small, efficient, highly customizable, and portable while capable of producing high-quality output (glyph images) of most vector and bitmap font formats.

Some products that use FreeType for rendering fonts on screen or on paper, either exclusively or partially:

  • GNU/Linux and other free Unix operating system derivates like FreeBSD or NetBSD;
  • iOS, Apple's mobile operating system for iPhones and iPads;
  • Android, Google's operating system for smartphones and tablet computers;
  • ChromeOS, Google's operating system for laptop computers;
  • ReactOS, a free open source operating system based on the best design principles found in the Windows NT architecture;
  • Ghostscript, a PostScript interpreter used in many printers.

Counting the above products only, you get more than a billion devices that contain FreeType.

News & Updates

FreeType 2.6.3


FreeType 2.6.3 has been released. It brings support for four new Asian scripts in the auto-hinter (Khmer, Myanmar, Kannada, and Bengali), together with other, minor improvements and bug fixes.

See here for a detailed list of changes.

More on the 2.6.2 release for users and developers

2015-11-30, contributed by Nikolaus Waxweiler (with corrections from Graham Asher), updated 2015-12-08

FreeType 2.6.2 ships with three interesting details for users and developers of rendering libraries that deal with text.

(S)light hinting invokes the native hinter if possible

In the past, setting ‘slight’ hinting via FontConfig or configuration GUIs meant that native hints within a font were ignored; FreeType's auto-hinter would analyze the font on the fly and automatically do what the font designer would have to do at least semi-manually. Technically, the auto-hinter set to (s)light snaps glyphs to the pixel grid only vertically, just like Microsoft's DirectWrite/ClearType and Adobe's proprietary font engine. The result is a compromise between design fidelity and sharpness that preserves inter-glyph spacing, something very important for horizontal text such as what you are reading right now. The sharpness has usually been enhanced with ‘subpixel rendering’ (ClearType on Windows), exploiting the physical properties of modern but low-resolution LCD panels.

This worked out well so far, Ubuntu has been using this setting for every font for years now. Werner Lemberg is adding support for more and more scripts and has also spun off the code into ttfautohint, to help font designers ease the pain of manual hinting.

This also meant that the native hinting machinery of the font drivers went unused. Historically, this decision was sound because the native hinting mechanics for Postscript (.pfa, .pfb), TrueType (.ttf) and OpenType/CFF (.otf) were subpar for the longest time. The PostScript hinter still is, but with Adobe's high-quality OpenType/CFF engine contributed to FreeType and recent advances of the TrueType driver towards full ClearType support, things have changed.

Setting ‘slight’ hinting usually leads to FT_LOAD_TARGET_LIGHT. This mode implied the auto-hinter before and has now been changed to mean “Use native vertical-grid-only-snapping if driver and font supports it and vertical-grid-only auto-hinter otherwise”. Right now, only the OpenType/CFF driver is supported. In the future, this will hopefully include the TrueType engine once full support for ClearType arrives.

This decision was driven by my personal whim; I wanted native vertical grid-fitting if the font driver and font supports it, and the auto-hinter otherwise. I assume that native hints are made more carefully and take the (auto-hinting) guesswork out of the process. Instead of introducing per-format configuration in FontConfig and fighting GTK/GNOME that only support a single global hinting setting, it was found to make more sense to change the definition of light hinting in FreeType.

I also hope this change will make it easier for the non-Windows-and-Apple ecosystem to switch over to slight hinting as the default. Current full/medium native hinting, as is the default, tends to bring out the worst in many, many fonts that haven't seen the same insane dedication to on-screen display and hinting as many popular Microsoft fonts, for example. And since ClearType is still not fully supported, you usually get a very poor default experience. Slight hinting gives a much better one, as Ubuntu has proven over the years.

Experimental: Stem darkening for the auto-hinter
Demonstration and comparison of the emboldening

Stem darkening emboldens glyphs at smaller sizes to make them more readable on common low-DPI screens. If this sounds familiar to you, that's because Adobe's CFF engine has been doing it since it was contributed in 2013. You might have noticed that OpenType/CFF fonts (commonly suffixed .otf) like GNOME 3's default UI font Cantarell appear bolder and fuzzier than other fonts, at least until this release. The auto-hinter can do the exact same thing now, it is just disabled by default.

But why would you do this if small glyphs are already fairly readable? It turns out that font rendering in the Linux ecosystem has been wrong since scalable fonts were introduced to it. Text must be rendered with linear alpha blending and gamma correction, which no toolkit or rendering library do by default on X11, even though Qt5 and Skia (as used by Google Chrome and other browsers) can do it.


First, to understand why they are required, you must know that when FreeType outputs a grayscale glyph image, it really outputs a coverage bitmap. If a pixel is completely covered by a filled-in outline, the pixel is made 100% black (0% brightness, which is simply black). If a pixel is only 50% covered, the pixel is made 50% black (50% brightness or a middle shade of gray) and 0% covered means 0% black (100% brightness or white). On high-DPI screens like on smartphones and tablets, the pixels are so small that the chance of being completely covered and therefore completely black is fairly good. On low-DPI screens most of us are sadly stuck with, the situation is different. The pixels are too large for most of the details of a glyph and shades of gray are the norm rather than the exception.

This is relevant because all our screens have a second problem: they are not linear. 1 + 1 is not 2. Twice the value does not result in twice the brightness. When a pixel is only 50% covered, the coverage map says 50% black, and this translates to a pixel value of 128 when you use 8 bits per channel (0-255). However, this does not translate to 50% brightness for that pixel on our sRGB and gamma 2.2 screens. Due to their non-linearity, they dwell longer in the darks and only a pixel value of about 186 results in 50% brightness – 128 ends up too dark on both bright and dark backgrounds. The net result is that dark text looks burnt-out, pixely and blotchy on bright background, bright text too frail on dark backgrounds, and colored text on colored background (for example, red on green) seems to have dark halos or ‘dirt’ around it. The situation is especially ugly for diagonal stems like in glyph ‘w’, where the quality of FreeType's anti-aliasing depends on the correct display of grays. On high-DPI screens where smaller, fully black pixels reign supreme, this doesn't matter, but on our low-DPI screens with all the gray shades, it does. 0% and 100% brightness are the same things in linear and non-linear space, just all the shades in-between are not.

The correct way of rendering a glyph image on a surface is to alpha blend it onto the surface in linear space and then apply gamma correction to translate the linear coverage map to something that is correct for our screens.[1] No toolkit in the Linux ecosystem does it by default, even though Qt5 and Skia can and will do it on other platforms. Windows and Mac OS X do it natively. This procedure is especially important if glyphs should be subpixel-rendered (ClearType and Mac OS X) with as few color fringes as possible.

Back to stem darkening

Assume we render fonts correctly. Gamma correction essentially lightens fonts since shades of gray are shifted to higher pixel values (corresponding to higher brightness) to match the original intention to the reality of our screens. The side-effect is that glyphs that were rendered incorrectly but fairly readable suddenly thin out. Correctly rendered but hard-to-read text doesn't do anyone a favor. So Mac OS X and Adobe's proprietary font engine implement a counter-measure: stem darkening at smaller sizes where shades of gray dominate. By emboldening a glyph slightly in relation to its pixel size, individual pixels get higher coverage of filled-in outlines and are therefore blacker. This increases contrast and prevents thinning out of glyphs. Text remains readable at smaller sizes.

Comparison of different ways of blending.

“Gamma 1.0” shows what happens when you take a grayscale coverage bitmap from FreeType and blend it onto a surface in linear space. Black-on-white is heavier than white-on-black and red-on-green has dark halos or dirt around it. Note that this picture is unrealistic in the sense that no rendering system on X11 does linear alpha blending, so imagine something worse. “Gamma 1.8” is the result of linear alpha blending and gamma correction. It is much better, but text thins out, making it harder to read. Adding stem darkening gets us to “Gamma 1.8, darkened”. Note how it is the cleanest rendering of all. “Gamma 1.0, darkened”, meaning linear alpha blending without gamma correction but with stem darkening, exaggerates the effects of “Gamma 1.0”. Stem darkening should only be enabled when doing gamma correction, so ideally it should always be done.

Waterfall comparison of non-emboldening and
                      emboldening autohinter.

The autohinter has a new toggleable stem darkening property that works like the stem darkener in Adobe's CFF engine. Note how it makes text slightly bolder with the default parameters, down to small pixel sizes. Gamma correction is active to demonstrate the thinning out of text especially at smaller pixel sizes with lots of gray pixels.

And that is the story behind this feature.

Disabled stem darkening for the autohinter and Adobe's CFF (.otf) engine

No library supports linear alpha blending and gamma correction out of the box on X11. Turning on stem darkening leads to heavy and fuzzy looking glyphs as in “Gamma 1.0, darkened” above, so it's better to disable it.

Qt5 actually had gamma correction enabled for a short time while until someone complained that text was too light and unlike rendering in other toolkits, so the maintainers disabled it for the XCB-backend. Skia (Chrome) can do gamma-correction, but turns it off for X11.

I see autohinter stem darkening as a technology preview for playing around with until we get stem darkening generic within FreeType. The plan is to provide it for all font drivers and make it toggleable per FT_Library just like FT_Library_SetLcdFilter. Libraries that support linear alpha blending and gamma correction can then just flip the switch and get appropriate glyphs no matter the font.

A notable side-effect of disabling all stem darkening by default is that natively hinted .otf fonts will render remarkably similar to the auto-hinter and are no longer heavy and fuzzy. Slight hinting will result in consistent font rendering.

The default LCD filter for subpixel rendering has been changed
Comparison of the old and new filter.

When you look at subpixel-rendered text, no matter whether it is on some kind of Unix, Windows, or Mac OS X, you might notice that it is slightly colored. Using subpixel rendering on LCD panels is a trade-off; you get three times higher resolution in the direction of the pixel-substripe (usually horizontal RGB) in exchange for color artifacts, also called color fringes. For this reason it is necessary to filter a subpixel-rendered glyph to reduce those color fringes before putting it somewhere on the screen. The filter distributes the values of a subpixel to its neighbors, sacrificing some of the higher resolution and making the resulting glyph image blurrier, but the positioning improvement remains! The ideal filter for you depends on your screen (gamma curves), the capabilities of the rendering system (linear alpha blending and gamma correction), your vision and your taste, probably in that order.

A filter should have two properties: it should be normalized, meaning the values used in the filter should sum up to a figurative 1 (here: 0x100 or 256) and it should be color-balanced, meaning that values for one subpixel are equally distributed to all other subpixels of a pixel to sacrifice some of the higher resolution to drastically reduce color fringes.

Previously, FreeType's default LCD filter was neither normalized nor color-balanced. That was a deliberate choice because there is still no rendering system on Unix-like operating systems that does linear alpha blending and gamma correction by default to render glyphs correctly. Going above a filter sum of 1 increased contrast somewhat at the expense of slight distortions and increased color-fringing, so this can be seen as a hack. You might have noticed that thumbnails in various places on your computer that show text could be quite colorful. Now you know why.

The new default filter is both normalized and color-balanced. It is indeed ever so slightly blurrier than the previous default one, but also lacks its harshness and is less color-happy. The blurriness also means higher tolerance for non-ideal screen gamma (viewing angles) and rendering systems without linear alpha blending. Note that color fringes can only be really minimized when the rendering system will do linear alpha blending of text.

The ‘light’ filter that has accompanied the default one for so long stays unchanged: it already is normalized and color-balanced. It is sharper than the default one but less tolerant of uncalibrated screens and rendering systems without linear alpha blending, producing more color fringes.

[1] This process can cost performance. There is an approximation that does not need to know about the background color. See and for details. There is a proof-of-concept pixman hack for cairo.

FreeType 2.6.2


FreeType 2.6.2 has been released. This is a minor release that mainly provides better handling of malformed fonts. All users should upgrade.

A new feature is stem darkening support for the auto-hinter. Note, however, that it is off by default, since most graphic systems don't provide correct linear alpha blending with gamma correction, which is crucial for a good appearance. For the same reason, stem darkening for the CFF engine is now off by default, too.

See here for a more detailed list of changes.

FreeType 2.6.1


FreeType 2.6.1 has been released. This is a minor release that corrects problems with CFF metrics, and that provides better handling of malformed fonts. Two notably new features are auto-hinting support for the Lao script and a simple interface for accessing named instances in GX TrueType variation fonts.

See here for a list of changes.

FreeType 2.6


FreeType 2.6 has been released. This is a new major release that provides a better (and simpler) thread-safety model. Among other new features we now have auto-hinting support for Arabic and Thai, together with much improved handling of Apple's GX TrueType variation font format.

See here for a list of changes.

FreeType 2.5.5


FreeType 2.5.5 has been released. This is a minor bug fix release: All users of PCF fonts should update, since version 2.5.4 introduced a bug that prevented reading of such font files if not compressed.

FreeType 2.5.4


FreeType 2.5.4 has been released. All users should upgrade due to another fix for vulnerability CVE-2014-2240 in the CFF driver. The library also contains a new round of patches for better protection against malformed fonts.

The main new feature, which is also one of the targets mentioned in the pledgie roadmap below, is auto-hinting support for Devanagari and Telugu, two widely used Indic scripts. A more detailed description of the remaining changes and fixes can be found here.

New Pledgie Campaign


This is a call for a new Pledgie campaign to support my (Werner Lemberg) expenses in 2014. Thanks to all donors, the last campaign was successful, and all goals have been reached!

If your company is using FreeType in your product, and you care about continuing support and further development, please contribute to my funding effort so I can continue to bring the best text rendering to your devices!

Alternatively, direct donations to my PayPal account are also highly welcome :-)


Besides user support and fixing bugs, your money will help me implement the following issues.

  • Setting up a test framework for FreeType. This is a huge, long-term undertaking that will ensure both stability and reliability of the library. The idea is to collect test cases (mainly broken fonts) that cover as much source code as possible. Another idea to investigate is the development of scripts that can generate both valid and invalid input data to systematically increase the coverage of executed library code, including the unlikely cases. Finally, images of valid, well-rendered input fonts could be collected: As soon as a change to the rendering image gets applied, a comparison run with those images should detect rendering regressions.
  • Further improvements to the auto-hinter. Right now, the module for Indic support is a dummy, and support for the family of Arabic scripts is completely missing. [FreeType 2.6.1 comes with auto-hinting support for Devanagari, Telugu, Arabic, Thai, and Lao.] Both investigation and research is necessary to find out how much auto-hinting is possible and useful, and whether other, completely different scripts can be supported at all.
  • Right now, rendering Type 1 and CID-keyed fonts is the weakest part of FreeType. However, we now have a brand-new module for handling CFF. Given that CFF is very similar to Type 1, it should be not too difficult to use and/or extend the CFF code so that Type 1 fonts can be handled, too.
  • Explore whether it makes sense to merge FreeType with (parts of) the HarfBuzz library. Since version 2.5.3, FreeType already links to HarfBuzz to use its abilities for scanning OpenType layout features, and more integration might be sensible for both libraries.
  • More improvements to this website. Last year I’ve redesigned the FreeType website. However, a large bunch of documents are still using the old design, and some of them are also no longer up to date. [As with version 2.6.0, the FreeType Tutorial has been updated.]

FreeType 2.5.3


FreeType 2.5.3 has been released. All users should upgrade due to fixed vulnerability in the CFF driver (CVE-2014-2240).

Its main new feature is much enhanced support of auto-hinting SFNT fonts (i.e., TrueType and CFF fonts) due to the use of the HarfBuzz library. A more detailed description of this and other changes can be found here.

FreeType 2.5.2


FreeType 2.5.2 has been released. It fixes a serious bug introduced in version 2.5.1; all users should upgrade.

A listing of the changes can be found here.

FreeType 2.5.1


FreeType 2.5.1 has been released, providing three major new features.

  • Support for the WOFF font format, contributed by Behdad Esfahbod.
  • The auto-hinter now supports Hebrew, together with improved support for Cyrillic and Greek.
  • The directory layout of the (installed) FreeType header files has been simplified.

Among other changes I want to mention that FreeType's TrueType debugger (ttdebug) has been made more versatile. An exhaustive list of changes can be found here.

Pledgie Campaign Was Successful!


Thanks to a very generous donation by Pierre Arnaud from Epsitec, the pledgie campaign for FreeType has reached its goal. I want to say thank you again to all donors! Of course, noone stops you from further donating to the campaign :-)

After integration of Adobe's CFF module and Google's color emoji support, I will use the next months to work on the remaining issues that I've promised to implement. Stay tuned!

FreeType 2.5


FreeType 2.5 has been released. A major new feature is support for color embedded bitmaps (eg. color emoji), contributed by Behdad Esfahbod on behalf of Google. Additionally, Adobe's CFF engine is now the default, which makes a good reason to change from the 2.4.x to the 2.5.x series.

On the technical side, the property API to access FreeType module parameters (FT_Property_Set and FT_Property_Get) is now declared as stable.

As usual, see this file for the complete release notes, which give more details. And we have again blog entries from Adobe and Google.

[Please download the bundle of the FreeType library, which fixes a packaging error.]

FreeType 2.4.12


FreeType 2.4.12 has been released. A major new feature is a new parsing and hinting engine for CFF fonts, contributed by Adobe in collaboration with Google. It was my job the last few months to fully adapt the code to FreeType, and we are very pleased with the results. You might also read the blog entries from Adobe and Google.

In connection with the new CFF engine, the demo programs, especially ftview and ftdiff, have been improved a lot; as usual, more details on the changes can be found in the release notes.

I also want to say a big thank you to all the people who have already donated to the campaign! In particular I want to thank Adobe, which has contributed to half the total pledgie amount.

Pledgie Campaign for Development and Maintainance


Click here to lend your support to the FreeType project and make a donation at!

I've started a pledgie campaign for FreeType development and maintainance. While no single company employs me (Werner Lemberg) directly to work on it, I am constantly improving it, adding new features, relentlessly driving up quality, and responding to other developers’ requests.

If you or your company is using FreeType in your product, and you care about continuing support and further development, please contribute to my funding effort so I can continue to bring the best text rendering to your devices!

Besides user support and fixing bugs, your money will help me implement the WOFF font format and extending FreeType's auto-hinter to support more scripts, together with other issues as outlined in the roadmap.

FreeType 2.4.11


FreeType 2.4.11 has been released. This is partly a security release (for users of fonts in BDF format), but it also contains important improvements:

  • experimental support for TrueType subpixel hinting support, as documented in Microsoft's whitepaper
  • support for OpenType Collections

See this file for the complete release notes, which give more details.

Redesigned Homepage


The website has been redesigned, giving it a more recent look to enhance readability and to make navigation easier. Note that only the two topmost levels have been changed yet; the remaining pages will follow.

FreeType 2.4.10


FreeType 2.4.10 has been released. This is minor release, fixing mainly a problem for GhostScript. See this file for the release notes, which give more details.

FreeType 2.4.9


FreeType 2.4.9 has been released. This is mainly a security release, fixing many potential vulnerabilities. All users should upgrade. See this file for the release notes, which give more details.

FreeType 2.4.8


FreeType 2.4.8 has been released. This is a security release, also providing a new API for accessing dictionary data in Type 1 fonts. All users should upgrade. See this file for the release notes, which give more details.

FreeType 2.4.7


FreeType 2.4.7 has been released. This is a security release. All users should upgrade. See this file for the release notes, which give more details.

FreeType 2.4.6


FreeType 2.4.6 has been released. This is a security release. All users should upgrade. See this file for the release notes, which give more details.

FreeType 2.4.5


FreeType 2.4.5 has been released. This is a maintainance release. All users should upgrade, especially if you still experience rendering degradations with version 2.4.4. See this file for the release notes, which give more details.

This page is maintained by Werner Lemberg. The FreeType logo has been designed by Manuel Colom.