Emoji and variation selectors (VS15 / VS16)

[christianparpart]

i see you are supporting also ZWJ emoji, so it seems.

Maybe you also want to support U+FE0E and U+FE0F VS15/VS16 variation selectors?

• U+FE0E overrides width to Narrow and changes emoji presentation to text (standard glyph rendering)
• U+FE0F overrides width to Wide and changes emoji presentation to emoji (square colored bitmaps)

I just checked, Kitty also seems to do that, so I'll now allow width changes to.

There is only a little number of TEs doing proper text shaping but I think the list is slowly growing and thus, maybe you want to consider supporting VS15/16 too.

[wez]

wezterm defers to harfbuzz for shaping, so I'm not sure what more is needed.
Is there a test case that contrasts these behaviors?

[christianparpart]

I am sorry, I do not know your source code internals. But do you forward all the necessary codepoints? I am sorry if I'm giving superfluous information here (apologizing ahead of time :) ), but maybe U+FE0F is not landing in the same grid cell as U+00A9 for example?

echo -ne "\u00A9\uFE0F"

On top of that, U+00A9 should be rendered using regular font, but U+00A9 followed by a U+FE0F represents one grapheme cluster whose emoji presentation is "emoji" (i.e. not "text") and therefore should use the emoji font instead of the non-emoji font (e.g. regular).

Have a look here maybe for a hopefully self-explaining illustration:

https://github.com/contour-terminal/libunicode/blob/master/src/unicode/emoji_segmenter_test.cpp#L136-L145

[khaledhosny]

If the font supports both text and emoji presentation and can switch between them internally (e.g. using ligatures) then Hard buzz would help. I haven't seen any fonts do this, though, most systems handle it by switching fonts based on what presentation is required.

[christianparpart]

most systems handle it by switching fonts based on what presentation is required.

Exactly. This is what I was trying to say. And it look like wezterm isn't doing that. Or did i miss something?

[wez]

From the commit message in 76b72e4:

These don't affect font choice as wezterm doesn't know whether a given
font in the fallback has a textual vs. an emoji version of a given
glyph, or whether a later font in the fallback has one or the other
because we can't know until we fall back, and that has a very high
cost--we perform fallback asynchronously in another thread because
of its high cost.

AFAIK, there isn't a concept of "this font is a text font" or "this font is an emoji presentation font" which means that a dedicated emoji font fallback list option would need to be introduced for this in order for wezterm to choose a font to match the selected presentation. I'm not sure how I feel about that at the moment, but I'll give it some thought.

[khaledhosny]

I think heuristics can be used to detects color fonts, e,g. using https://harfbuzz.github.io/harfbuzz-hb-ot-color.html#hb-ot-color-has-layers, https://harfbuzz.github.io/harfbuzz-hb-ot-color.html#hb-ot-color-has-png, etc. and assume these have emoji presentation by default. Since there are not that many emoji fonts, a list of known emoji font names can be used in addition to/instead of such checks.

[wez]

as of 0866e5d the behavior is now:

; wezterm ls-fonts
Primary font:
wezterm.font_with_fallback({
  -- /home/wez/.fonts/OperatorMonoSSmLig-Medium.otf, FontDirs
  {family="Operator Mono SSm Lig", weight="DemiLight"},

  -- /home/wez/.fonts/OperatorMonoSSmLig-Medium.otf, FontConfig
  {family="Operator Mono SSm Lig", weight="DemiLight"},

  -- /home/wez/.fonts/MaterialDesignIconsDesktop.ttf, FontDirs
  "Material Design Icons Desktop",

  -- /home/wez/.fonts/MaterialDesignIconsDesktop.ttf, FontConfig
  "Material Design Icons Desktop",

  -- /usr/share/fonts/google-noto-emoji/NotoColorEmoji.ttf, FontConfig
  -- Assumed to have Emoji Presentation
  "Noto Color Emoji",

  -- <built-in>, BuiltIn
  "JetBrains Mono",

  -- <built-in>, BuiltIn
  "Last Resort High-Efficiency",

})

[christianparpart]

Hey @wez

thanks for also taking care of VS15/VS16, but I had some findings ->

while looking for terminals that do support VS15/VS16 (again), I was also trying your TE (again :) ).

echo -e "\U0001f600\ufe0e"

yields to the following notification

No fonts contain glyphs for these codepoints: \u{fe0e}.
Placeholder glyphs are being displayed instead.

and that visual:

but should look like (gnome-terminal screenshot):

I did not look into your source code, but maybe there is no grapheme cluster segmentation happening and that's why this grapheme cluster) is split and passed into two separate hb_shape() calls, which it shouldn't?

(p.s.: I actually came here to see what cell width your apply to VS15 overrides, as I think there is no common consensus in the TE dev community.)

[wez]

I think that notification is showing the wrong information (it infers the grapheme from something that's lost information on its journey to harfbuzz). I think what's really happening is that the presentation mode is preventing wezterm from finding any matching font. I'll dig into that.

Regarding your question about widths, the logic I settled on is:

• If VS specifies Emoji, use 2
• If VS specifies Text, use 1
• If default presentation is Emoji, use 2
• if default presentation is Text, use the unicode width algorithm on grapheme but clamp its maximum value to 2, because the crate that implements that algorithm is unaware of emoji combining sequences (ugh!)

[4cm4k1]

Here are 2 test cases, if this helps, I found while running zplug update and yarn test (using jest), both of which have emoji in their output. Since these examples have the Unicode codepoint for emoji presentation variation selector, I think it has to do with this issue and the fact that these particular symbols default to text presentation:

• ✔️ "\U2714\UFE0F"
• ✖️ "\U2716\UFE0F"

Here is a screenshot illustrating various echo statements of the first example listed:

Version: wezterm 20210816-234431-24d971c8

[wez]

@christianparpart FWIW, I get the same results as gnome terminal when I echo -e "\U0001f600\ufe0e" on my system. I think there might be something a bit wonky about the font resolution for you (wezterm ls-fonts --text "😀︎" might be interesting to see)

I pushed a commit that avoids claiming that VS15 or VS16 are missing glyphs; that was just a simplistic oversight in the error reporting path.

That same commit will make a second pass through the fallback list and ignore the selected presentation so that in the case where we couldn't find the glyph in the requested presentation, we'll accept any presentation. We'll still proceed to try loading fallbacks from the system and re-evaluate once they load, so hopefully that makes things look a bit better for @4cm4k1

[4cm4k1]

@wez Pulled down the newly built nightly; LGTM! Thanks.

[SlySven]

Might I make an observation in that whether a colour emoji presentation is a narrow or wide one does depend on (I think) the version of Unicode that it it was introduced in. You may find https://github.com/ridiculousfish/widecharwidth/ of interest - which is keep up to date (unlike Markus Kuhn's mk_wcwidth()/mk_wcwidth_cjk() which have not been updated since Unicode 5.0!)

[github-actions]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.