Our blog post is live: We just published https://developer.chrome.com/blog/memory-safety-fonts sharing our journey on how we migrated from FreeType to Fontations in Chrome to improve memory safety and development velocity in our cross-platform open-source font stack. Shipping in Chrome 133. (Reposting with public visibility.)
Memory safety for web fonts  |  Blog  |  Chrome for Developers

Learn how and why the Chrome team has replaced FreeType with Skrifa.

Chrome for Developers

Replying to https://typo.social/@pixelambacht/114190022971359802 @pixelambacht :

We went through extreme testing, even implemented compatibility logic in Fontations to match FreeType.

For hinting mode (TrueType instructions, autohinting, off), subpixel/grayscale antialiasing, we performed pixel tests and drove down the pixel diffs to almost nothing (tiny difference in RGB filter width remains).

For metrics (advances, ascent, descent) and the contour path we had unit tests clamping results down to exactly match FT.

@drott @pixelambacht Interesting stuff. There’s a few things I’d be happy to know more about:

Is there a visual comparison accessible somewhere to see the visual differences mentioned?

Also, can you elaborate a bit about which fonts were used for the pixel tests? Do you know which hinting strategies were used in these files?

Thanks!

@bramboeck @pixelambacht For monochromatic rendering pixel comparison we used the Noto corpus, covering 78 scripts and running them in all relevant rendering modes. If you have access to gold.skia.org, you can find them under `fontations_compare_ft*` - Here's one example fontations_compare_ft_NotoSans_Deva_hint_slight - slight hinting for Devanagari, grayscale antialiased.

Other than the Skia tests, Chrome/Blink's virtual/text-antialiasing web tests cover a lot more.