Emoji Rules

[typkrft]

I am wondering if I can edit how emojis are displayed. Comparing the two screenshots below (wezterm and kitty) you can see that in wezterm the emojis appear below the horizontal line that the text sits on. They also seem larger and I'm not sure why but the two snake emojis are different. I tried looking through font related settings and fallback rules, but couldn't find any settings which might resolve this.

[kar1]

The snake emoji is clearly from two different fonts. Can you post your font settings from Kitty and Wezterm and the output from wezterm ls-fonts. That would help diagnose the problem.

You can get the name of the font Wezterm is using by running the command:

wezterm ls-fonts --text '🐍'

[wez]

Shouldn't it use the font specified in my config for emojis?

Noto Color Emoji is bundled with wezterm and is used as an implied fallback font, so it is using the fonts specified in your config (as revealed by wezterm ls-fonts) to lookup the snake.

If you try to display a glyph that isn't found in the explicit + implicit fallback fonts, wezterm will ask the system for its list of fallback fonts and then analyze those to figure out whether they contain the glyph. That initial system fallback resolve is not cheap (we run it async in another thread and it can take visible fractions of a second to produce a match), but that is where wezterm would otherwise discover the Apple Color Emoji font.

If you prefer the apple font, then you can explicitly list it in your config to have it take precedence over the implied Noto font.

Re: line height: that's a tricky area. You may want to try setting use_cap_height_to_scale_fallback_fonts = true in your config to see if things line up better. Whether they do or not depends on how accurate the cap-height metric is for both your base font and the emoji font. If you want to understand what influences that, take a look at https://tonsky.me/blog/font-size/

Another wrinkle with emoji fonts, aside from not having easily relatable font metrics, is that the glyphs are typically square and oversized relative to monospace terminals and need to be scaled to fit the box, and that scaling can mess with the line height.

So far no one has been sufficiently bothered by it to do something about it, but it may not be that much effort to reconcile for someone with the motivation and the time!

[typkrft]

Hey thanks for the response, I had never even realized that I guess that terminals we're even using separate emoji fonts. I realized shortly after I said that I was an idiot again lol. I tried the use_cap_height_to_scale_fallback_fonts = true to no avail. It would seem to me that they scale is appropriate, but where the character start at the very bottom of the line even lower than the descenders of the letters. Though this may be what your referring to when you say scaling messes with line height. I don't have the skill, but I definitely have the time. Let's see if I can acquire the skill and contribute something. Thanks for post, I'll do some research.

[wez]

Don't worry, I didn't know anything useful about fonts until I started this project :-p
If you wanted to tool around with the code to get a feel, this is a good place to start:

https://github.com/wez/wezterm/blob/main/wezterm-gui/src/glyphcache.rs#L420-L431

That logic sets a scale for the glyph based on the ratio of metrics of the emoji font vs. the main font you specified.
If scale == 1.0 then we don't change the size, but if we do, this bit of code is triggered:

https://github.com/wez/wezterm/blob/main/wezterm-gui/src/glyphcache.rs#L505-L516

The data produced there is eventually used over here in the renderer:

https://github.com/wez/wezterm/blob/main/wezterm-gui/src/termwindow/render.rs#L1163-L1179

It's possible/probable that this particular line may need to be tweaked in a different way to accommodate
the scaling and get a more reasonable line height; right now it scales based solely on the cell size:

https://github.com/wez/wezterm/blob/main/wezterm-gui/src/termwindow/render.rs#L1176

but it may make sense to somehow account for differences in the descender metric that is also
available in those render metrics:

https://github.com/wez/wezterm/blob/main/wezterm-gui/src/utilsprites.rs#L13

For more information on what the font metrics terminology means, this page is pretty good:
https://www.freetype.org/freetype2/docs/tutorial/step2.html

[wez]

btw: one thing I found surprising when I first got exposed to this stuff was that emoji fonts are typically bitmap fonts that use fixed size 128x128 pixel images. Re: my commentary about the descender metric, I think the top/bottom position might need to be adjusted so that the descender value for the emoji font, with the scaling/font size adjustment accounted for, matches the descender value for the base font. I think the math is probably trivial if you have the time to sit down and play with it and figure it out.

[typkrft]

Awesome, Thanks for the write up and references! I will see what I can do.