Memory safety for web fonts

&gt; Merely keeping up with the stream of issues found by fuzzing costs Google at least 0.25 full time software engineers<p>I like this way of measuring extra work. Is this standard at Google?

I hope that if we switch away from FreeType, we&#x27;ll still have a way to use TTF hinting instructions fully.<p>Windows&#x2F;macOS don&#x27;t seem to have a way to enable proper hinting anymore [0], and even FreeType (since 2.7 [1]) defaults to improper hinting (they call it &quot;subpixel hinting&quot;, which doesn&#x27;t make sense to me in theory, and practically still seems blurry, as if it&#x27;s unhinted).<p>In case anyone&#x27;s wondering what properly hinted text looks like, here&#x27;s a screenshot [2]. This currently relies on setting the environment variable `FREETYPE_PROPERTIES=truetype:interpreter-version=35`, possibly some other configuration through fontconfig, and using a font with good hinting instructions (eg, DejaVu Sans and DejaVu Sans Mono in the screenshot).<p>My suspicion is that Windows moved away from font hinting after XP because it&#x27;s very hard to create fonts with good sets of hinting instructions (aiui, OTF effectively only allows something like &quot;autohinting&quot;), so in the modern world of designer fonts it&#x27;s easier to just have everyone look at blurry text. Some other minor reasons would be that UI scaling in Windows sometimes (or always?) introduces blurring anyway, and viewing raster images on screens of varying resolutions also introduces scaling blur.<p>[0] Windows still has a way to enable it, but it disables antialiasing at the same time. This is using an option called &quot;Smooth edges of screen fonts&quot; in &quot;Performance Options&quot;). This basically makes it look like XP, which imo is an improvement, but not as good as FreeType which can do hinting and antialiasing at the same time.<p>[1] <a href="https:&#x2F;&#x2F;freetype.org&#x2F;freetype2&#x2F;docs&#x2F;hinting&#x2F;subpixel-hinting.html" rel="nofollow">https:&#x2F;&#x2F;freetype.org&#x2F;freetype2&#x2F;docs&#x2F;hinting&#x2F;subpixel-hinting...</a><p>[2] <a href="https:&#x2F;&#x2F;gist.githubusercontent.com&#x2F;Maxdamantus&#x2F;3a58d8e764b299e8b1eaa524aab8e1bd&#x2F;raw&#x2F;313997632ad81ddd06f625ca02aa14ab244cf67f&#x2F;hinted.png" rel="nofollow">https:&#x2F;&#x2F;gist.githubusercontent.com&#x2F;Maxdamantus&#x2F;3a58d8e764b29...</a>

This is the true power of Rust that many are missing (like Microsoft with its TypeScript rewrite in Go): a gradual migration towards safety and the capability of being embedded in existing project.<p>You don&#x27;t have to do the Big Rewrite™, you can simply migrate components one by one instead.

So, there&#x27;s Skia. Skia is a high-level library that converts texts to glyph indices, does high-level text layout, and caches glyphs (and it also makes GPU calls). But the actual parsing of the font file and converting glyphs to bitmaps happens below in FreeType.<p>Skia is made in C++. It&#x27;s made by Google.<p>There&#x27;s FreeType. It actually measures and renders glyphs, simultaneously supporting various antialiasing modes, hinting, kerning, interpreting TrueType bytecode and other things.<p>FreeType is made in C. It&#x27;s not made by Google.<p>Question: why was it FreeType that got a Rust rewrite first?

I&#x27;ve recently been learning about how fonts render based on subpixel layouts in monitor panels. Windows assumes that all panels use RGB layout, and their ClearType software will render fonts with that assumption in mind. Unfortunately, this leads to visible text fringing on new display types, like the alternative stripe pattern used on WOLED monitors, or the triangular pattern used on QD-OLED.<p>Some third-party tools exist to tweak how ClearType works, like MacType[1] or Better ClearType Tuner[2]. Unfortunately, these tools don&#x27;t work in Chrome&#x2F;electron, which seems to implement its own font rendering. Reading this, I guess that&#x27;s through FreeType.<p>I hope that as new panel technologies start becoming more prevalent, that somebody takes the initiative to help define a standard for communicating subpixel layouts from displays to the graphics layer, which text (or graphics) rendering engines can then make use of to improve type hinting. I do see some efforts in that area from Blur Busters[3] (the UFO Test guy), but still not much recognition from vendors.<p>Note I&#x27;m still learning about this topic, so please let me know if I&#x27;m mistaken about any points here.<p>[1] <a href="https:&#x2F;&#x2F;github.com&#x2F;snowie2000&#x2F;mactype" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;snowie2000&#x2F;mactype</a><p>[2] <a href="https:&#x2F;&#x2F;github.com&#x2F;bp2008&#x2F;BetterClearTypeTuner" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;bp2008&#x2F;BetterClearTypeTuner</a><p>[3] <a href="https:&#x2F;&#x2F;github.com&#x2F;microsoft&#x2F;PowerToys&#x2F;issues&#x2F;25595" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;microsoft&#x2F;PowerToys&#x2F;issues&#x2F;25595</a>

I appreciate the pun in the repository name <a href="https:&#x2F;&#x2F;github.com&#x2F;googlefonts&#x2F;fontations&#x2F;" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;googlefonts&#x2F;fontations&#x2F;</a>

This is a wonderful write up. Reminiscent of the old google

It looks like there is an extern C interface... I wonder if it is everything necessary for someone to use it via FFI.

TIL fonts have more than just a collection of vectorized glyphs in them

This is the kind of work that Brave et al will never do.

&gt; Fonts are passed through the OpenType Sanitizer prior to processing.<p>Are font formats so bad that the files need to be sanitized?<p>Also, note that the identified integer overflows as one of causes of vulnerabilities. It is sad that today many languages do not detect overflows, and even modern architectures like RISC-V do not include overflow traps although detecting an overflow doesn&#x27;t require many logic gates. C is old, ok, but why new languages like Rust do not have overflow traps, I cannot understand. Don&#x27;t Rust developers know about this thing?

I wonder what this means, if anything, for the future of WUFFS. TTF support is on their roadmap. If they can get acceptable performance and safety from Rust, will they still drive on with WUFFS?

Why don’t they just port it to WASM? It provides an extra memory safety layer and it’s already in chrome

You know what is even safer than all this? Not loading fonts from the web at all!

If fresh code in Rust truly reduces the number or severity of CVE in a massively tested and fuzzed C library like this one it will be a major blow to the “carefully written and tested C&#x2F;C++ is just as safe” perspective. Just need the resources and Rust performance to rewrite them all.

It&#x27;s very annoying that Google&#x27;s websites, including this blog, are automatically translated to my browser&#x27;s preferred language.<p>Sillicon Valley devs clearly believe that machine translation is a magical technology that completely solved internationalization, like in Star Trek. No, it&#x27;s far from it. Ever since internet has been flooded with automatically translated garbage, the experience of international users, at least bilingual ones, got much worse.

Look, a language that was conceived out of necessity to write a web browser in a safer way is being used just for that. It&#x27;s a different, unrelated browser, but the language still reaches its design goals beautifully.

I get it, but switching to Rust places the codebase on an Island I can&#x27;t easily get to. I am already switching between C++, Swift, Kotlin, and Python on an almost daily basis.

FreeType is a dinosaur that should be replaced regardless of Rust or not.