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.
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.