[kane50613]

LLM Contributions: Claude fact check + generates, Codex review.

Now font selection only checks for "who has the first char?". Variation selectors like U+FE0F are ignored, same for U+FE0E. It also happened in the downstream kane50613/takumi#1218.

Per candidate font, an exact cmap format 14 match for the whole sequence wins first. Otherwise U+FE0F prefers fonts with color tables and U+FE0E fonts without. When no font matches the requested presentation, the base character still renders from a mismatched font instead of tofu.

To check whether the font has color tables, I've mirrored ColorTableLookup from Blink.

#692 seems to be solving the same bug, but only by moving the emoji generic family to the front, which overrides user-selected fonts that have their own emoji glyphs. Checking each font's capability avoids that.
Suppressed by #811

#620 is the segmentation layer above this and complementary.

Changelog

• Adds fontique::Charmap::map_variant, with MapVariant re-exported from read-fonts.
• Adds FontInfo::has_color_tables().
• Adds public QueryFont.has_color_tables.
• [Breaking change:] QueryFont struct literals must provide the new has_color_tables field.

[DJMcNab]

I do expect this to be valuable, but we haven't had the bandwidth to review this yet.

[kane50613]

I've rebased from the latest main branch.

[nicoburns]

An initial AI-review is positive for correctness, but notes a 3-5% performance regression for non-emoji text.

Suggested causes and fixes:

1. CharmapIndex::charmap() now runs Cmap14::read(...) eagerly for every candidate font on every cluster (fontique/src/charmap.rs). For fonts that have a format 14 subtable (Noto CJK, many system fonts) that is a parse + validation per call. Suggest storing the data slice/offset in Charmap and parsing lazily inside map_variant, or caching the parsed Cmap14 alongside the cmap in the query.
2. select_font builds variation_sequences (windows scan + base_is_unique O(n²) scan) and, per candidate, a SmallVec plus variant_bases.contains(&ch) inside the hot coverage closure, even when the cluster has no selector. Add an early fast path: if no U+FE0E/U+FE0F in cluster.chars(), run the original closure/selection loop unchanged. select_font is called once per grapheme cluster, so this adds up on document-scale text.

[nicoburns]

The latest changes seem to have brought performance ~back to parity, although my LLM does have a note that:

If the author really wants to squeeze [performance]: the per-candidate SmallVec + variant_bases.contains(&ch) in the coverage closure still executes for every cluster. Guarding the closure with variation_sequences.is_empty() (or keeping the original closure for that case) would remove the last unconditional cost.

[kane50613]

I've asked opus to squeeze it to the extreme. He agrees this PR is 2% slower than main branch, and mentioned one possible architectural change:

select_font calls font.charmap() inside self.query.matches_with(...). So it runs once per candidate font, per cluster.

CharmapIndex is built once per font and cached. But CharmapIndex::charmap() still redoes the work every call: FontRef::from_index, the table lookup, and CmapSubtable::read. The list of candidate fonts does not change within a segment, so the result is always the same.

One problem is that Charmap<'a> borrows the blob that QueryFont owns. Caching it on QueryFont would make the type refer to itself. A cache on the FontSelector side, keyed by blob id and face index, avoids that. So would a cache held by fontique's Query.

Should I still aim for the extreme 🤔