Currently, when a character cannot be found in a CSS-defined font group (the list of fonts in the font-family for a particular element), Servo will get a list of fallback fonts in the web content process. This list is determined by looking at the Unicode properties of the character in question (and maybe the one after it), plus the emoji preference. This list is static and isn't influenced at all by the fonts on the system. Then, Servo will walk one by one through this list, creating fonts and checking to see if they have the character in question.

Yet, many system font APIs allow requesting a suitable font given a string, which would be a more efficient operation since it would skip creating font data for fonts that might not contain the character. This would happen in the SystemFontService as that is the only place (currently) allowed to access system font lists. In addition:

1. On macOS "supplemental" fonts are only available this way. The other alternative is to manually register the fonts in the supplemental directory which takes about 100 milliseconds. Gecko does this, but on a thread. It's probably better to use the right API for this instead as Chromium and WebKit do.
2. On Android, it's possible to list system fonts, but not get their family names. This is bizarre, but Android does support the "find a font for this character" API.

This bug tracks modifying Servo's font fallback system to support the "find a font for this character" APIs, which are available at least on macOS, FontConfig (desktop Linux), and Android systems.