-
Notifications
You must be signed in to change notification settings - Fork 8
2025 Hackathon: Browser integration of Fontations Rust font stack
- GitHub issue: https://github.com/Igalia/webengineshackfest/issues/46
- URL: https://meet.jit.si/WEH2025-Fontations
- Blog post: https://developer.chrome.com/blog/memory-safety-fonts
Several reasons for people to attend this session:
- integrate with other engines (Gecko, Servo, ...)
- get some information abouto the project
Reasons for Chrome team to do this:
- wanted something quick for Google Fonts
- many security bugs on freetype
Set of 3 Rust libraries, see https://github.com/googlefonts/fontations/:
- Skrifa
- Read-fonts
- Font-types
Skia already had several backends, so they added another one for Fontations. Functionalities: countours, font metrics, setting the rendering configuration, etc. Chrome started 1.5 years ago, and then in ~Chrome 128 Fontations was enabled for not very used font formats. Then in Chrome 136 it was enabled for all formats on Linux, Android, ChromeOS, ... (all the systems that had OS font stack).
Release dates in Blog post: https://developer.chrome.com/blog/memory-safety-fonts
Freetype has a rasterizer, fontations doesn't. It just extract the vector information, which is then rendered by skia. It needed lots of testing:
- are we getting the same information from freetype and Fontations?
- pixel comparison (which was difficult because of antialiasing, 3 vs. 4 px)
Q: What about performances? A: Freetype rasterizer is specific for font countours and it's a bit faster, Skia's is more generic and therefore slightly slower. However, they compensate with Rust code in Fontations. Also, Fontations has advantages in allocations and memory usage.
Steps to integrate (was this for Chrome?):
- Work out how to build Rust in your build system (For example, integrate with GN, Bazel, Meson, CMake, etc.)
- FFI: CXX.rs they define the FFI in a Rust module, and then you generate the C++ headers. Fontations is more modular and separated than Freetype, it also has less state. Fontations doesn't bring any C or C++ bindings, so you can use whatever you prefer. E.g., Firefox uses cbindgen
What's the scope of fontations? Is it possible to integrate it with harfbuzz?
- HarfBuzz has a set of font functions to read font data, based on a) HarfBuzz own impl b) FreeType-based ones c) now has Fontations font funcs.
HarfRust (previously called HarfRuzz): port of HarfBuzz to Rust, which uses Fontations (https://github.com/harfbuzz/harfrust)
What about fontconfig? Fontconfig is still there. Fontconfig reads which fonts are available and provide some information in the form of a database. It uses FreeType to do it, but the goal is to completely remove FreeType from Chrome, so there's code in upstream fontconfig to use Fontations (except that fontations doesn't support some of the formats freetype does, such as Type 1 forms).
Q: Is the plan to keep using fontconfig? A: Yes, no plans to remove it at the moment. It's very used on Linux desktop, and they don't have time/resources to provide a replacement. Interesting questions: RPC vs. memory-mapped database file.
Q: A lot of the font stack is becoming platform independent. How far can we go with this? How much of the OS provided parts are we going to reimplement in third-party libraries? In particular DirectWrite and CoreText. A: DirectWrite could traditionally not really be trusted to be secure. However, recently the security has improved after MS rewrote DWrite in Rust). CoreText still has some security issues from time to time.
Fontations could be a backup option, in case security issues aren't addressed quickly, or some issues aren't addressed at all.
Skia doesn't simulate OS settings for cleartype/antialiasing that DWrite provides.
System rasterizer has the advantage that it can share some memory usage with the font matcher, whereas with another rasterizer there will be a need to copy stuff in memory.