Esfahbod: State of Text Rendering 2024

[Posted July 9, 2024 by jake]

On his blog, Behdad Esfahbod has published a lengthy and detailed look at the state of open-source text rendering. It looks at the libraries available, application support, future directions, and gives a summary analysis of the ecosystem.

In broad strokes, OpenType added support for color fonts, variable fonts, and the Universal Shaping Engine. The Free & Open Source stack supports all of these advances at the lower level, but application UI support has been slower to arrive. The Open Source text stack also gained enormous market-share when Android and Google Chrome fully embraced it.
Looking forward, there is a Rust migration of the text stack underway, which will unify font compilation and consumption under a safe programming language. Incremental Font Transfer will enable streaming fonts to web browsers. And my proposed Wasm-fonts will enable more expressive fonts.

TW: Meme language

Posted Jul 9, 2024 10:20 UTC (Tue) by Deleted user 129183 (guest, #129183) [Link] (7 responses)

> While the Rust migration is beneficial to the ecosystem in the long term, in the short term it has the potential to fragment the ecosystem

This will definitely fragment the ‘ecosystem’ and not only in the short term.

For example, KDE does not want to force Rust as a hard dependency of the Frameworks:

https://invent.kde.org/frameworks/kiconthemes/-/merge_req...

TW: Meme language

Posted Jul 9, 2024 10:45 UTC (Tue) by atnot (subscriber, #124910) [Link] (2 responses)

I think I'd want to see a bit more evidence for that than some off-hand comment about a mild concern from one person 4 years ago

TW: Meme language

Posted Jul 9, 2024 11:33 UTC (Tue) by ArkansasTraveler (guest, #171756) [Link] (1 responses)

Well, you can read about people complaining about forcing a dependency on Rust also in those articles:

https://lwn.net/Articles/771355/
https://lwn.net/Articles/845535/

One of it is pretty much prophetic:

> We saw a problem similar to that of Gentoo's back in 2018 with Debian and librsvg and we are likely to see it recur—frequently—over the coming years.

TW: Meme language

Posted Jul 9, 2024 12:55 UTC (Tue) by atnot (subscriber, #124910) [Link]

So a few people moaning in 2018 (6 years ago), and again in 2021 (3 years ago). And since then, despite the complaints, both of them appear to have just went ahead and depended on Rust code since anyway?

I do genuinely understand the objections there fwiw. Fewer architectures and longer bootstrap chains can be annoying. I agree with the KDE contributor, it's a thing that should be discussed.[1]

However today any distro that wants to package GNOME (or even just have working nvidia or opencl drivers) needs to package a bunch of rust code anyway. You say it's prescient, but I personally haven't heard any of those complaints since the pyca fiasco. I'm not terribly convinced using it in something like text shaping would actually be a big deal at this point.[2]

[1] Although I do wish we discussed it regarding build time dependencies on e.g. Perl too
[2] Or at least, not as big as a deal as people who title threads things like "TW: Meme language" want it to be.

TW: Meme language

Posted Jul 9, 2024 13:37 UTC (Tue) by xophos (subscriber, #75267) [Link] (3 responses)

I would have thought that a few people could be nervous because they plan to add support for WASM in a f*ing font rendering engine.
At this point switching to rust for the added safety is just about the least they need to do...

TW: Meme language

Posted Jul 9, 2024 15:38 UTC (Tue) by flussence (guest, #85566) [Link]

Compared to how fonts have been constructed and shaped historically... I'd very much prefer the WASM at this point. The Rust requirement isn't a big ask if it can be built with gccrs.

TW: Meme language

Posted Jul 9, 2024 15:43 UTC (Tue) by lunaryorn (subscriber, #111088) [Link] (1 responses)

I guess it's probably not that big a step from true type byte code to WASM.

TW: Meme language

Posted Jul 9, 2024 18:26 UTC (Tue) by excors (subscriber, #95769) [Link]

In addition to the old hinting bytecode, there's also Graphite (https://graphite.sil.org/) with its own custom programming language and stack machine interpreter, which has been known to have security vulnerabilities (https://www.mozilla.org/en-US/security/advisories/mfsa201...). If that could be replaced with a well-tested widely-used WASM runtime, it might be a net benefit to security, in addition to providing more flexibility and better performance.

(https://github.com/harfbuzz/harfbuzz-wasm-examples has some examples of where the flexibility is useful for real languages.)

LLM in TrueType

Posted Jul 9, 2024 18:11 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]

OK, the real question is, how soon is TrueType renderer going to become conscious? Here's an LLM implemented as a freaking font: https://fuglede.github.io/llama.ttf/

what would this Rust thing bring in terms of dependency

Posted Jul 9, 2024 18:18 UTC (Tue) by atai (subscriber, #10977) [Link] (3 responses)

For a typical C or C++ program, or just a C application using the gtk/gnome framework, would the Rust implementation bring extra needed libraries?

If so, maybe it is time for someone to keep the C implementation in feature parity with the Rust version so fonts render the same, for example.

what would this Rust thing bring in terms of dependency

Posted Jul 10, 2024 5:27 UTC (Wed) by raof (subscriber, #57409) [Link] (2 responses)

No; one of the reasons that Rust is appropriate for this is that it's easy to expose a C-ABI library.

librsvg (part of the GNOME platform) has been progressively rewritten in Rust since 2018; it hasn't changed ABI since 2002.

what would this Rust thing bring in terms of dependency

Posted Jul 11, 2024 9:07 UTC (Thu) by LtWorf (subscriber, #124958) [Link] (1 responses)

The main problem with rust for distributions is the endless recompilations I think.

Setting aside the fact that it restricts the amount of architectures that can be supported.

what would this Rust thing bring in terms of dependency

Posted Jul 11, 2024 12:25 UTC (Thu) by pizza (subscriber, #46) [Link]

> Setting aside the fact that it restricts the amount of architectures that can be supported.

Is this still true for anything that hasn't been obsolete for a couple of decades? (ie where full system emulation is both vastly faster (raw MHz) and more capable (RAM, I/O) than the highest-end hardware ever produced?)

> The main problem with rust for distributions is the endless recompilations I think.

Better tooling helps here, but.. yeah, this is still a real problem for anyone that has to support a *system* rather than a single *application*

But I think the bigger problem with rust (wrt many distributions) is that it effectively locks them into a single toolchain, undoing a decade or so's worth of efforts to not depend on a single (different) one.

Harfbuzz in Go

Posted Jul 9, 2024 20:34 UTC (Tue) by taintedbit (subscriber, #108080) [Link] (3 responses)

Since I didn't see it mentioned in the report: Harfbuzz has also been ported to Go, where it is used by multiple Go UI toolkits including Fyne, Gio, and Ebitengine. I'm impressed that the community was able to achieve a port, given the complexity of Harfbuzz and the challenge of font rendering in general!

Harfbuzz in Go

Posted Jul 10, 2024 16:09 UTC (Wed) by Wol (subscriber, #4433) [Link] (2 responses)

So long as they've fixed harfbuzz's damn circular dependency!

It's an absolute pain to install/update in gentoo on occasion, because harfbuzz depends on - I think - truetype, and truetype on harfbuzz, so neither will install until after the other one. Like most things, it's pretty easy to fix (just force-install one with the dependency disabled, then the other will install, then the first one will update).

But if you don't know about it, it's a nightmare ...

Cheers,
Wol

Harfbuzz in Go

Posted Jul 10, 2024 21:23 UTC (Wed) by Clozure (guest, #125255) [Link] (1 responses)

Proper package managers just install them together when any is requested for install.

Harfbuzz in Go

Posted Jul 11, 2024 15:21 UTC (Thu) by Wol (subscriber, #4433) [Link]

And?

Proper packages shouldn't have circular dependencies.

Or are you saying emerge isn't a proper package manager? :-)

Cheers,
Wol

Variable fonts

Posted Jul 10, 2024 12:00 UTC (Wed) by rsidd (subscriber, #2582) [Link] (1 responses)

The variable fonts thing is very interesting and Esfahbod mentions Knuth's METAFONT precedent (which works at font generation time). But METAFONT could do more: it could actually interpolate between a serif and sans-serif font. He demonstrated it by typesetting Psalm 23 in a font that gradually varied from an old-fashioned serif appearance to a modern sans-serif appearance (on page 15 of The Concept Of A Meta-Font).

Probably a totally useless thing, but interesting to think about.

Variable fonts

Posted Jul 10, 2024 12:55 UTC (Wed) by anselm (subscriber, #2796) [Link]

But METAFONT could do more: it could actually interpolate between a serif and sans-serif font.

This is probably less to do with METAFONT (which after all is a Turing-complete, if quirky, programming language) and more with the clever and intricate design of Knuth's “Computer Modern” font family, which uses the same (large-ish) set of parameters to tweak bespoke programs which generate letters and other characters. In effect, in Computer Modern, an old-fashioned serif “A” and a modern sans-serif “A” differ only in the specific parameter values used to calculate their appearance from the same abstract program for the letter “A”, and so on, while the same set of parameters applied to all the programs for a whole font will result in a set of glyphs that look reasonably similar and coherent.

This method of specifying fonts via mathematical equations unfortunately (?) doesn't seem to have caught on among font designers …