Related to #1768 but doesn't fix it properly.
This is a temporary hack to avoid some issues with fonts that have mixed
color/non-color glyphs. If there are mixed presentations and the font
does not have emoji codepoints, then we assume it is text. This fixes
the typical scenarios.
This is not a long term solution. A proper long term solution is to
detect this scenario and on a per-glyph basis handle colorization (or
the lack thereof) correctly. It looks like to do this we'll have to
parse some font tables which is considerably more work so I wanted to do
this first.
Fixes#707
Our scoring algorithm previously did not take into account symbolic
traits, so when `bold = false and italic = false`, regular, bold, italic
would all be equally likely to appear first.
This modifies our scoring algorithm to prioritize matching symbolic
traits. Further, we have a special case for no symbolic traits to
prioritize "Regular" named styles. We can expand this to other styles
too but we do not do this here.
We also modified the algorithm to always prefer fonts with more glyphs
over fonts with less, hopeful that we can load fewer fonts for other
glyphs later.
Fixes#668
We were previously only checking the first font result in the search.
This also fixes our CoreText scoring algorithm to prioritize faces that
have the codepoint we're searching for.
This implements font discovery so the `--font-family` flag works for macOS. Fonts are looked up using the Core Text API so any installed font on the Mac system can be used.
We still use FreeType for rendering, and CoreText doesn't _quite_ give us all the information we need to build the exact face in FreeType. So a TODO after this is to now implement glyph _rendering_ using Core Text and Core Graphics. Until then, a couple fonts don't quite work (i.e. Monaco, a big one!) but many do!
