font fallback for U+2387 is inconsistent with native macOS apps

[amusingimpala75]

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

macOS

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

No response

WezTerm version

wezterm 20240203-110809-5046fc22

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

Yes, and I updated the version box above to show the version of the nightly that I tried

Describe the bug

The wrong font is selected for a given symbol, in this case ' ⎇ '. Alacritty, set to use the JetBrains Mono font, yields:

whereas Wezterm, set to use that font setup renders it as . Asking wezterm to list the font applied for the symbol says that it is using the Apple Symbols font.

To Reproduce

No response

Configuration

font related parts of my wezterm config are below:

config.font = wezterm.font_with_fallback {
  { family = "JetBrainsMono Nerd Font", weight = "Medium" },
  -- ⎇ symbol is broken, but not on alacritty
  { family = "JetBrains Mono", weight = "Regular" },
  "DroidSansMono Nerd Font",
}

config.font_size = 16.0
config.bold_brightens_ansi_colors = true
config.dpi = 144.0
config.font_rules = {
  {
    intensity = "Bold",
    font = wezterm.font("JetBrainsMono Nerd Font", {weight = "ExtraBold"})
  },
  {
    italic = true,
    intensity = "Bold",
    font = wezterm.font("JetBrainsMono Nerd Font", {italic = true, weight = "ExtraBold"})
  },
  {
    italic = true,
    font = wezterm.font("JetBrainsMono Nerd Font", {italic = true, weight = "Medium"})
  },
}
config.harfbuzz_features = {"calt=1", "clig=1", "liga=1"}

Expected Behavior

Font behavior should be the same, and the JetBrains mono font should be used over the Apple symbols font.

Logs

No response

Anything else?

No response

[zevelix]

I don't think JetBrains has that character(U+2387) either and alacritty is falling back to some other font that has the glyph you want. Try running

alacritty -vvv

and see what fonts it is loading when that glyph is displayed.

[amusingimpala75]

When I paste the character in the new window I get this message in the old one:

[43.393167791s] [TRACE] [alacritty_terminal] Setting attribute: Foreground(Named(BrightRed))
[43.393330833s] [TRACE] [alacritty_terminal] Setting attribute: Foreground(Named(Black))
[43.393403958s] [TRACE] [alacritty_terminal] Configuring charset G0 as Ascii
[43.393450166s] [TRACE] [alacritty_terminal] Setting attribute: Reset
[43.393525625s] [TRACE] [alacritty_terminal] Carriage return
[43.393629666s] [TRACE] [alacritty_terminal] Moving forward: 100
[43.393657791s] [TRACE] [alacritty_terminal] Configuring charset G0 as Ascii
[43.393683166s] [TRACE] [alacritty_terminal] Setting attribute: Reset
[43.393703458s] [TRACE] [alacritty_terminal] Configuring charset G0 as Ascii
[43.393722291s] [TRACE] [alacritty_terminal] Setting attribute: Reset
[43.393740958s] [TRACE] [alacritty_terminal] Setting attribute: Foreground(Named(BrightBlack))
[43.393764166s] [TRACE] [alacritty_terminal] Configuring charset G0 as Ascii
[43.393784208s] [TRACE] [alacritty_terminal] Setting attribute: Reset
[43.393802291s] [TRACE] [alacritty_terminal] Carriage return
[43.393821250s] [TRACE] [alacritty_terminal] Moving forward: 100
[43.393842500s] [TRACE] [alacritty_terminal] Carriage return
[43.393860291s] [TRACE] [alacritty_terminal] Moving forward: 6

and at the top of the debug log is:

[0.051011125s] [DEBUG] [alacritty] Loading "JetBrainsMono Nerd Font" font

but no other fonts are listed.

I've attached the full log file.

Alacritty-7851.log

[wez]

This isn't alacritty; what it shows is not relevant to me. Please run through https://wezfurlong.org/wezterm/troubleshooting.html#debugging-font-display

[zevelix]

Not sure how pointing out that wezterm is not "selecting the wrong font" is off-topic, but to each their own! :)

[amusingimpala75]

I already tried debugging it (hence knowing that it was being printed using the Apple Symbols font), but I'll provide the full printout here:

wezterm ls-fonts --text ⎇: ls_fonts_char.txt

LeftToRight
 0 ⎇    \u{2387}     x_adv=25.330141129032256 cells=1  glyph=uni2387,3455 wezterm.font("Apple Symbols", {weight="Regular", stretch="Normal", style="Normal"})
                                      /System/Library/Fonts/Apple Symbols.ttf, CoreText

wezterm ls-fonts --list-system: ls_fonts_system.txt wezterm ls-fonts: ls_fonts.txt

[amusingimpala75]

And for the record, yes the font should be printing the character the way I expected, I checked with gucharmap.

[wez]

What this tells me is that U+2387 is not present in JetBrainsMono Nerd Font, so wezterm asks macOS where to find it and macOS says that it is present in /System/Library/Fonts/Apple Symbols.ttf.

The Font Book app also shows that the Apple Symbols font is a reasonable choice. If you look at the symbol on the mac keyboard, the Apple Symbol font glyph is in the same orientation, so it "feels right".

However, the macOS Terminal app picks a different font from that!

Looking deeper:

$ WEZTERM_LOG=wezterm_font=trace,info wezterm --config-file /tmp/5341.lua ls-fonts --text ⎇
...
18:16:07.085  TRACE  wezterm_font                     > Fallback fonts that match \u{2387} before sorting are: [
    ParsedFont {
        names: Names {
            full_name: "Apple Symbols Regular",
            family: "Apple Symbols",
            sub_family: Some(
                "Regular",
            ),
            postscript_name: Some(
                "AppleSymbols",
            ),
            aliases: [],
        },
        weight: FontWeight(
            400,
        ),
        stretch: Normal,
        style: Normal,
        handle: FontDataHandle {
            source: OnDisk {
                path: "/System/Library/Fonts/Apple Symbols.ttf",
            },
            index: 0,
            variation: 0,
            origin: CoreText,
            coverage: None,
        },
        cap_height: Some(
            0.54638671875,
        ),
        synthesize_italic: false,
        synthesize_bold: false,
        synthesize_dim: false,
        assume_emoji_presentation: false,
        pixel_sizes: [],
        harfbuzz_features: None,
        freetype_load_target: None,
        freetype_render_target: None,
        freetype_load_flags: None,
        scale: None,
    },
    ParsedFont {
        names: Names {
            full_name: "STIX Two Math Regular",
            family: "STIX Two Math",
            sub_family: Some(
                "Regular",
            ),
            postscript_name: Some(
                "STIXTwoMath-Regular",
            ),
            aliases: [],
        },
        weight: FontWeight(
            400,
        ),
        stretch: Normal,
        style: Normal,
        handle: FontDataHandle {
            source: OnDisk {
                path: "/System/Library/Fonts/Supplemental/STIXTwoMath.otf",
            },
            index: 0,
            variation: 0,
            origin: CoreText,
            coverage: None,
        },
        cap_height: Some(
            0.657,
        ),
        synthesize_italic: false,
        synthesize_bold: false,
        synthesize_dim: false,
        assume_emoji_presentation: false,
        pixel_sizes: [],
        harfbuzz_features: None,
        freetype_load_target: None,
        freetype_render_target: None,
        freetype_load_flags: None,
        scale: None,
    },
]

that STIX Two Math font is returned as a candidate as well, but since the Apple Symbols font satisfies the query we don't try it.

If you explicitly select that font, you also get a glyph that is consistent with Apple Symbols and the Apple Keyboard.

If you add Lucida Grande to the fallback list, then you get a glyph with the same orientation as the one that Terminal.app selects.

So, I'm not sure what I can do here; we're using the font that macOS tells us to use, which is not the same as the font as its own internal font resolver would use.

What I'd suggest in the meantime is adding either Lucida Grande or Fira Code to your fallback list to get the style of glyph that you're looking for.

[amusingimpala75]

Yeah using Fira Code solves the issues, thanks! Do you want me to leave this issue open or would you rather I closed it?

[wez]

We can keep it open; it does bother me that this inconsistency exists, and if you hit it, then someone else is likely to hit it in the future. I'm not sure if/when I'll be able to do anything about it, but this at least serves as documentation on what's happening.