wez / wezterm

A GPU-accelerated cross-platform terminal emulator and multiplexer written by @wez and implemented in Rust
https://wezfurlong.org/wezterm/
Other
17.17k stars 774 forks source link

No fonts contain glyphs for those codepoints: \u{1d4d2} #4768

Open ZouDongj opened 9 months ago

ZouDongj commented 9 months ago

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

Windows

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

No response

WezTerm version

wezterm 20240108-182230-b6faedf3

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 𝓒 is broken in wezterm image

but it does work correctly in Windows Terminal image

❯ wezterm ls-fonts
Primary font:
wezterm.font_with_fallback({
  -- <imported to RAM>, Gdi
  {family="JetBrainsMonoNL NF", weight="Medium"},

  -- C:\USERS\Z\APPDATA\LOCAL\MICROSOFT\WINDOWS\FONTS\MSYH_0.TTC, DirectWrite
  -- AKA: "微软雅黑"
  "Microsoft YaHei",

  -- C:\USERS\Z\APPDATA\LOCAL\MICROSOFT\WINDOWS\FONTS\MATERIALICONSROUND-REGULAR.OTF, DirectWrite
  "Material Icons Round",

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

  -- <built-in>, BuiltIn
  -- Assumed to have Emoji Presentation
  "Noto Color Emoji",

  -- <built-in>, BuiltIn
  "Symbols Nerd Font Mono",

})

To Reproduce

No response

Configuration

no config

Expected Behavior

No response

Logs

No response

Anything else?

No response

crides commented 8 months ago

Works for me just fine:

maim-2024 01 22 22 28 29

I guess the hard part would be to find out what font Windows Terminal used to render that

wez commented 8 months ago

This is a bit of a weird outcome because wezterm asks DirectWrite which font it should use in this fallback scenario. For this to error out means that DirectWrite didn't tell wezterm about any suitable fonts. I would have expected it to return the same font used in windows terminal.

ZouDongj commented 8 months ago

This is a bit of a weird outcome because wezterm asks DirectWrite which font it should use in this fallback scenario. For this to error out means that DirectWrite didn't tell wezterm about any suitable fonts. I would have expected it to return the same font used in windows terminal.

This is really weird, this problem occurs when I use the symbols_outline plugin in nvim to view the symbols of a python file, but when I use the same plugin to view the symbols of another larger C file which contain more symbols, the font becomes normal again as the cursor scrolls in the symbols table, and it also shows up normally in other windows in the wezterm that opened this time, but when I close and reopen the wezterm, this font become broken again.

starifly commented 7 months ago

I also encountered this problem and solved it using the following method Add a math font to the font_with_fallback

local font = wezterm.font_with_fallback({
  { family = "Hack Nerd Font", style = "Normal", scale = 1 },
  { family = "Cambria Math", scale = 1.0 },
})