Renderability axis would be useful in font selection

Nobody has claimed this yet.

Currently the font is selected based on family name, attributes like weight, width or style and cmap coverage (does the font even have the codepoints we need).

There is another factor that can lead to sub-optimal results though and that is if the rasterizer supports the format the font uses to describe the codepoint (COLRv0, COLRv1, CBDT,...). swash 0.2.9 does not support COLRv1 so it would be strictly better if it got a font that contains that codepoint described in another format it does support since it will otherwise just lead to a blank space where the character should be.

This could be relatively easily solved if the consumer of the font could tell the font selection logic which formats it supports (capabilities) or if a Query::matches_with style predicate supplied by the consumer would be consulted during the selection process, assuming of course that the actual FontInfo contained the information on the formats.

Start with the font-selection query and FontInfo paths, then trace how cmap coverage is matched. Compare the proposed consumer capability input with Query::matches_with and identify the format metadata and selection behavior that would need tests. Done should mean selecting a supported representation instead of a glyph that renders as blank.

Written by the indexing model from the issue text.