Emoji appear as silhouettes

[1ec5]

As of #6640, we get support for some emoji “for free”. #50 would add support for a few hundred more emoji via variation selectors. However, TinySDF is only capable of rendering silhouettes of emoji, even if we fall back to a color emoji font such as Apple Color Emoji.

The silhouettes are consistent with other map renderers, such as Mapnik. Some style designers may consider color emoji to be an intrusion on their designs. On the other hand, the silhouettes may be surprising and disappointing to emoji fans who take color for granted. They also raise the potential for miscommunication: some OpenStreetMap contributors choose specific emoji on the basis of their colors.

1ec5/tiny-sdf#1 demonstrates extracting color channels from TinySDF. Putting these color channels in the glyph atlas and rendering them would be more challenging, especially since we probably don’t encounter emoji frequently enough to justify extra parallel glyph atlases.

[1ec5]

Until we add support for color emoji, we may want to force any emoji back to text presentation forms. This will prevent situations like #6640 (comment) where it’s difficult to tell which emoji are behind those silhouettes.

We can insert variation selectors around where we verticalize punctuation:

maplibre-gl-js/src/symbol/shaping.ts

Lines 127 to 129 in 550cf3a

	if (writingMode === WritingMode.vertical) {
	logicalInput.verticalizePunctuation();
	}

logicalInput.replace(/\p{Emoji_Presentation}/gu, "$0\ufe0e"); // variation selector for text presentation

This will only have the intended effect once we fix #50, to break the strong coupling between codepoints and graphemes.

We’d remove this workaround as part of adding support for color emoji, then introduce a layout property to opt in or out of emoji presentation forms, along the lines of font-variant-emoji in CSS.

[1ec5]

This feature would probably unlock support for color fonts as well.

[HarelM]

I think a temporary solution to show emoji as text would be fine for now.

[1ec5]

Unfortunately, there’s nothing we can do about this until we implement support for ligatures and combining characters: #2384. (That’s the first half of #50.)

Some Unicode codepoints default to a text presentation form, so U+FE0F VARIATION SELECTOR-16 forces the emoji presentation form. Conversely, some codepoints default to an emoji presentation form, so U+FE0E VARIATION SELECTOR-15 forces the text presentation form. Neither control character currently works, because we still isolate each Unicode character instead of rendering a whole grapheme at a time. In other words, we could strip out U+FE0F or add U+FE0E, but it won’t matter as long as we pass the previous character to TinySDF without the control character.

[1ec5]

On second thought, we could insert the U+FE0E in GlyphManager, just before sending the string to TinySDF, to temporarily work around the lack of ligature support. But there’s still no guarantee that a browser will honor this variation selector. WebKit on iOS is particularly aggressive about interpreting characters as emoji, but even Firefox on macOS sometimes ignores the variation selector.