Emoji is incorrectly rendered

jjpe commented 5 months ago

What Operating System(s) are you seeing this problem on?

Linux X11

Which Wayland compositor or X11 Window manager(s) are you using?

KDE/KWin

WezTerm version

20240203-110809-5046fc22

Did you try the latest nightly build to see if the issue is better (or worse!) than your current version?

No, and I'll explain why below

Describe the bug

When I want to print the 🖐 \u{1f590} emoji, I expect it to be rendered using the Noto Color Emoji font, which looks similar to how it's rendered here on GitHub, and is one of the default fonts according to this doc page. Instead, it is rendered using Noto Color Emoji font for a split second, and then altered to use Noto Sans Symbols 2 font , which looks like this: hand emoji

Meanwhile, if I try to print 👋 \u{1f44b}, that is rendered using Noto Color Emoji, as expected, without alteration afterwards.

Also interesting to note here is that KDE's Konsole does use the correct font for 🖐 \u{1f590}, so it's not a system issue.

To Reproduce

I'm not sure what is causing the issue in the first place, so reproduction is tricky.

Configuration

I do have a .wezterm.lua file, but no explicit font settings.

Expected Behavior

Correct and consistent font usage

Logs

Debug Overlay wezterm version: 20240203-110809-5046fc22 x86_64-unknown-linux-gnu Window Environment: X11 KWin Lua Version: Lua 5.4 OpenGL: NVIDIA GeForce RTX 4080/PCIe/SSE2 4.6.0 NVIDIA 550.78 Enter lua statements or expressions and hit Enter. Press ESC or CTRL-D to exit

Anything else?

No response

wez commented 4 months ago

Might be a fontconfig issue, maybe?

What does wezterm ls-fonts --codepoints 1f44b output for you?

Note that unicode version settings can impact emoji rendering, as can presentation selectors. Are you sure that it is exactly the 1f44b codepoint that is being emitted, and not some larger sequence?

jjpe commented 3 months ago

Might be a fontconfig issue, maybe?

Well, I'm using nixos, and the relevant font config looks like

fonts = {
    enableDefaultPackages = true;
    packages = with pkgs; [
      fira
      fira-code
      fira-code-symbols
      fira-mono
      (nerdfonts.override {
        fonts = [
          "FiraCode"
          "DroidSansMono"
        ];
      })
      noto-fonts-color-emoji
      noto-fonts
      corefonts # Microsoft free fonts
      source-code-pro
      source-sans-pro
      source-serif-pro
    ];
    fontconfig = {
      enable = true;
      antialias = true;
      cache32Bit = true;
      hinting.enable = true;
      hinting.autohint = true;
      defaultFonts = {
        monospace = [ "Source Code Pro" ];
        sansSerif = [ "Source Sans Pro" ];
        serif = [ "Source Serif Pro" ];
        emoji = [ "Noto Color Emoji" ];  # <- explicitly set the default emoji font to here
      };
    };
  };

So I'm even explicitly setting the emoji font to "Noto Color Emoji". And yet it's overridden somehow.

What does wezterm ls-fonts --codepoints 1f44b output for you?

❯ wezterm ls-fonts --codepoints 1f44b                                                                                     00:19:12.017369411
LeftToRight
 0 👋    \u{1f44b}    x_adv=22.440045475959778 cells=2  glyph=567  wezterm.font("Noto Color Emoji", {weight="Regular", stretch="Normal", style="Normal"})
                                      /nix/store/4f2slp0a6fsf46pv7yp5j9sbxbb5n6q3-noto-fonts-color-emoji-2.042/share/fonts/noto/NotoColorEmoji.ttf, FontConfig

And then for 1f590

❯ wezterm ls-fonts --codepoints 1f590                                                                                     00:22:05.716969461
LeftToRight
 0 🖐    \u{1f590}    x_adv=12.5 cells=1  glyph=u1F590,1179 wezterm.font("Noto Sans Symbols 2", {weight="Regular", stretch="Normal", style="Normal"})
                                      /nix/store/gvl6p8iv2b4p9sv70yqd4kfhj2yvr7m8-noto-fonts-24.3.1/share/fonts/noto/NotoSansSymbols2-Regular.otf, FontConfig

Note that unicode version settings can impact emoji rendering, as can presentation selectors. Are you sure that it is exactly the 1f44b codepoint that is being emitted, and not some larger sequence?

In the case of 1f590 it's part of the message 🖐 Press Ctrl-D to exit. i.e. it's directly followed by a space. Perhaps I'm wrong but it seems like that shouldn't alter the visuals of an emoji.

wez / wezterm