Some glyphs stretched vertically in 1.2.2

[japhb]

Issue Description

After doing a fresh install of Ghostty 1.2.2 from https://github.com/mkasberg/ghostty-ubuntu?tab=readme-ov-file#manual-installation I ran the terminal-quicktest from https://github.com/japhb/Terminal-Tests in each of Ghostty, kitty, and gnome-terminal for comparison (left to right in the image below):

All three are using default configurations for the Cinnamon desktop under Linux Mint 22.2 (Zora), which is based on Ubuntu 24.04 LTS (Noble).

Note that not only has Ghostty chosen a font with a taller cell aspect ratio than the others -- it's a bit hard to see, but the windows are approximately the same width but the Ghostty one is much taller -- but the automatic font resizing seems to do some unexpected additional stretching.

If you look at the basic symbols block in the upper right (sampled from Latin-1, CP1252, W1G, WGL4, and MES-2), note that the "eighths" have been stretched to overlapping their cells, the card suits appear different sizes, and predominately "portrait orientation" glyphs are outsized with respect to related glyphs of different orientations. For example, FEMALE SIGN is much larger than MALE SIGN, INTERSECTION and UNION are larger than SUBSET OF and SUPERSET OF, and UP DOWN ARROW is larger than LEFT RIGHT ARROW.

Similarly, the rotating arrows below the basic symbols block show strongly varying lengths (and widths, in the case of the double arrows).

More oddly, in the row of corner glyphs, WHITE CIRCLE WITH LOWER RIGHT QUADRANT is much smaller than the other WHITE CIRCLE WITH * QUADRANT glyphs.

Finally, the outlined corner triangles in the rightmost "compass rose" layout are all stretched vertically; I assume they are filling their cells vertically, rather than being isosceles right triangles as the other two terminals show.

Note that the same rightmost compass rose layout has an offset center EIGHT POINTED PINWHEEL STAR. I'm not sure if this is caused by the stretching as well or is just a bug in whatever font was chosen as Ghostty's default.

Expected Behavior

Glyph sizes of related glyphs should be more consistent and glyphs should not be stretched or overlapping.

Actual Behavior

See Issue Description.

Reproduction Steps

To just display the glyphs and SGR codes of the test without installing anything:

1. Open Ghostty.
2. Download the attached terminal-quick-test-ansi.txt file.
3. cat terminal-quick-test-ansi.txt

terminal-quick-test-ansi.txt

To do the test "for real", by actually running the test program:

1. Install Rakudo (or Rakudo-Star) however is most convenient for you to get a Raku compiler.
2. Open Ghostty.
3. git clone https://github.com/japhb/Terminal-Tests.git
4. cd Terminal-Tests
5. zef install --deps-only .
6. raku -I. bin/terminal-quick-test --ruler

Ghostty Logs

No relevant Ghostty logs.

Ghostty Version

Ghostty 1.2.2

Version
  - version: 1.2.2
  - channel: stable
Build Config
  - Zig version   : 0.14.1
  - build mode    : builtin.OptimizeMode.ReleaseFast
  - app runtime   : apprt.Runtime.gtk
  - font engine   : font.main.Backend.fontconfig_freetype
  - renderer      : renderer.generic.Renderer(renderer.OpenGL)
  - libxev        : io_uring
  - kernel version: 6.8.0-79-generic
  - desktop env   : other
  - GTK version   :
    build         : 4.14.5
    runtime       : 4.14.5
  - libadwaita    : enabled
    build         : 1.5.0
    runtime       : 1.5.0
  - libX11        : enabled
  - libwayland    : enabled

OS Version Information

Linux Mint 22.2 (Zora), based on Ubuntu 24.04 LTS (Noble)

(Linux only) Display Server

X11

(Linux only) Desktop Environment/Window Manager

Cinnamon 6.4.8

Minimal Ghostty Configuration

No configuration (fresh install).

Additional Relevant Configuration

No relevant configuration, just using defaults.

I acknowledge that:

• I have reviewed the FAQ and confirm that my issue is NOT among them.
• I have searched the Ghostty repository (both open and closed Discussions and Issues) and confirm this is not a duplicate of an existing issue or discussion.
• I have checked the "Preview" tab on all text fields to ensure that everything looks right, and have wrapped all configuration and code in code blocks with a group of three backticks (```) on separate lines.

[danielwe]

I think the short answer here is that most things you're observing is just due to the terminals using different fonts, both as primary font and as fallbacks loaded for any codepoints not defined in the primary font.

• The female sign and male are presumably loaded from a fallback font with a wider advance than the primary font (JetBrains Mono), or one where certain symbols are designed to span two cells (e.g., Iosevka). Thus, they are nominally too large to fit in a single cell, but since they are followed by non-whitespace, Ghostty scales them down such that they do. Since the male symbol is wider, it needs to be scaled down more, leading to the relative size mismatch. If you type out the two glyphs with a space between and after, you'll see that their sizes are better matched, but if you remove the space they shrink down to what you're seeing in the test.
• The pinwheel star is basically the same story, but since it's followed by whitespace, it's allowed to extend into the next cell and is not scaled down. That's why it ends up offset. (The secret trick to avoid this is to follow it by U+00A0 No-Break Space instead of a regular space.)
• The vulgar fractions are probably also an example of a loading a wider fallback font. However, these codepoints are not among the symbols that are subject to the downscaling explained above, which is why they end up overlapping each other. I suppose they could be added to the list.
• The outlined triangles are not loaded from any font, but drawn by Ghostty's internal sprites. That way, they always match up with the grid and can be used for terminal graphics that need the glyphs to match up across cell boundaries, even if you use the adjust-cell-height and adjust-cell-width config options to increase or decrease the margin around your glyphs. This is by design.
• The double arrows are probably just designed like this in whatever font they're loaded from.
• The WHITE CIRCLE WITH LOWER RIGHT QUADRANT is the truly odd case. I don't know what's going on there. It may be that it's loaded from a different fallback font than the other circles with quadrants. To check, run the following:

  ghostty +show-face --string="◶◵◷◴"
  

  You can use the same command to investigate any other glyph you're curious about. As an alternative to pasting the actual glyphs, you can just pass their codepoints as follows: ghostty +show-face --cp=0x25F6.

[japhb]

Something really weird is going on:

U+25F6 « ◶ » found in face “JetBrains Mono”.
U+25F5 « ◵ » found in face “DejaVu Sans Mono”.
U+25F7 « ◷ » found in face “DejaVu Sans Mono”.
U+25F4 « ◴ » found in face “DejaVu Sans Mono”.

U+2033 « ″ » found in face “JetBrains Mono”.
U+215B « ⅛ » found in face “DejaVu Sans Mono”.
U+215C « ⅜ » found in face “DejaVu Sans Mono”.
U+215D « ⅝ » found in face “DejaVu Sans Mono”.
U+215E « ⅞ » found in face “DejaVu Sans Mono”.
U+2206 « ∆ » found in face “JetBrains Mono”.

U+221A « √ » found in face “JetBrains Mono”.
U+207F « ⁿ » found in face “DejaVu Sans Mono”.
U+2190 « ← » found in face “JetBrains Mono”.

U+2660 « ♠ » found in face “Noto Emoji”.
U+2663 « ♣ » found in face “Noto Emoji”.
U+2665 « ♥ » found in face “Symbols Nerd Font”.
U+2666 « ♦ » found in face “Noto Emoji”.
U+266A « ♪ » found in face “DejaVu Sans Mono”.
U+266B « ♫ » found in face “DejaVu Sans Mono”.
U+263A « ☺ » found in face “Noto Emoji”.
U+263B « ☻ » found in face “DejaVu Sans Mono”.
U+2302 « ⌂ » found in face “JetBrains Mono”.
U+263C « ☼ » found in face “DejaVu Sans Mono”.
U+2640 « ♀ » found in face “Noto Emoji”.
U+2642 « ♂ » found in face “Noto Emoji”.
U+2200 « ∀ » found in face “JetBrains Mono”.

U+21D2 « ⇒ » found in face “JetBrains Mono”.
U+21D7 « ⇗ » found in face “DejaVu Sans Mono”.
U+21D1 « ⇑ » found in face “JetBrains Mono”.
U+21D6 « ⇖ » found in face “DejaVu Sans Mono”.
U+21D0 « ⇐ » found in face “JetBrains Mono”.
U+21D9 « ⇙ » found in face “DejaVu Sans Mono”.
U+21D3 « ⇓ » found in face “JetBrains Mono”.
U+21D8 « ⇘ » found in face “DejaVu Sans Mono”.

I see four different fonts picked just within the WGL4 symbol set, and that set has been required by any font that works on Windows (which I have to assume JetBrains does) for the last quarter century or so.

So either JetBrains Mono is filled with glyph holes for symbols that really ought to be there (in which case JetBrains Mono probably shouldn't be the default font), or the font-for-glyph selection is doing something really weird (in which case that's probably a bug to be fixed).

It makes sense that the outline triangles are generated internally, for exactly the reason you're talking about, but I don't think those particular codepoints are supposed to be stretched to full cell height. See the sample glyphs in https://www.unicode.org/charts/PDF/U25A0.pdf . (NOTE: Unicode sample glyph charts are explicitly not prescriptive, so the shape there is no guarantee. It is a strong hint, though.)

[danielwe]

So either JetBrains Mono is filled with glyph holes

This is indeed the case. Screenshot from fontforge:

I don't think those particular codepoints are supposed to be stretched to full cell height

Paging @qwerasd205 in case they have a comment on this.

[danielwe]

Btw. on the four different fonts: Noto Emoji and Symbols Nerd Font are always loaded, so it makes sense that they appear and fill in whatever holes in JetBrains Mono they're able to. The only font here that's loaded through the fallback mechanism is DejaVu Sans Mono.

[danielwe]

(To be more precise, Noto Emoji is always loaded on Linux, while Apple Color Emoji is always loaded on macOS.)

[japhb]

Given the odd choices of holes in JetBrains Mono, it seems that's practically guaranteed to cause glyph appearance mismatches. :-P

[danielwe]

Yeah it's especially surprising that they only added one out of a family like the circles with quadrants. Maybe the lower right one is used by some JetBrains IDE UI element and the others aren't, but that would be a pretty bad excuse considering that adding the three others is completely trivial once you've designed (as in, chosen the bearings for) one of them.

[japhb]

Adding a little more thought to the triangle question, it seems to me that the Unicode triangle codepoints may have a functionality hole. There are (at least) two needs:

1. Isosceles triangles that can be used visually for corners, pointers, bevels, etc.
2. Stretched triangles that allow combined shapes to flow between cells without "pieces cut out".

The first need seems to be satisfied by the original unstretched triangles in Unicode versions prior to 17.0. I don't think the second one gets satisfied until the Symbols For Legacy Computing block introduced in Unicode 17.0: https://www.unicode.org/charts/PDF/U1FB00.pdf . It's not clear that all the variants that you'd want are there, but certainly a lot of them.

(FWIW, if there are any codepoints whose glyphs absolutely should be generated internally, the Symbols For Legacy Computing block has 'em.)

[danielwe]

(FWIW, if there are any codepoints whose glyphs absolutely should be generated internally, the Symbols For Legacy Computing block has 'em.)

Yep:
https://github.com/ghostty-org/ghostty/blob/main/src/font/sprite/draw/symbols_for_legacy_computing.zig
https://github.com/ghostty-org/ghostty/blob/main/src/font/sprite/draw/symbols_for_legacy_computing_supplement.zig

[japhb]

I've updated the test pattern to show more features and possible errors; here is a comparison screenshot of four different terminal configs:

That's default Ghostty 1.2.2 in the upper left, Ghostty 1.2.2 with --font-family="DejaVu Sans Mono" in the upper right, and then default kitty and gnome-terminal respectively on the second row.

I find the upper right one the most generally readable and consistent overall, though it is a tad annoying that setting the base font-family disabled programming ligatures (see the row just above the emoji faces).

There are of course still some weird bits; see below.

Playing card glyphs

Ghostty chooses completely different glyphs for playing cards than the other two do, and choice of Ghostty base font doesn't seem to matter.

kitty --debug-font-fallback has this to say:

U+1f0b1 Face(family=DejaVu Sans, style=Book, ps_name=DejaVuSans, path=/usr/share/fonts/truetype/dejavu/DejaVuSans.ttf, index=0, is_scalable=True, has_color=False, ascender=1901, descender=-483, height=2384, underline_position=-85, underline_thickness=90, strikethrough_position=530, strikethrough_thickness=102) (new face)

ghostty +show-face similarly says:

U+1F0B1 « 🂱 » found in face “DejaVu Sans”.

(Note that the glyph shown above may not match the one Ghostty actually uses, because of GitHub's font choices; that's a textual paste, not a screenshot.)

In any case, both kitty and Ghostty claim to be using the same font for PLAYING CARD ACE OF HEARTS, but are showing different glyphs. Why?

Emoji oddness

There are two strange things going on in Ghostty's emoji rows:

• The spacing within the last ZWJ of the bottom row is wildly wide; what's going on there?
• Regional flag support seems to be partial, showing divisions of Great Britain but not US states; any particular reason?

Ligature debugging

How do I debug ligature choices, as +show-face does for non-joined glyphs?

I'd like to figure out how to enable programming ligatures even with a non-default base font, but I'm not sure how to see what needs to be fixed.

Non-obvious drawing glyph differences

Ghostty has a couple differences for the drawing glyphs versus the other two terminals, and I'm not sure which is actually correct:

• Ghostty draws REVERSE CHECKER BOARD narrow, but widens most other cramped glyphs such as ASTERISM when followed by a space. The three terminals all disagree on the handling of those; kitty is also inconsistent but in the opposite way, and gnome-terminal goes consistently wide for both.
• I still think the outline triangles should NOT be stretched; none of the other terminals I've come across do this, regardless of OS.

[japhb]

Responding to the parts I have a meaningful comment on.

One can expect nothing more. ;-)

both kitty and Ghostty claim to be using the same font for PLAYING CARD ACE OF HEARTS, but are showing different glyphs. Why?

No idea, have you checked which one is telling the truth? That is, what does the glyph actually look like in DejaVu Sans?

According to Character Map, DejaVu Sans has the more readable playing card glyphs shown in kitty and gnome-terminal (as determined by selecting "DejaVu Sans Mono" as Character Map's preferred font, searching for PLAYING CARD, and then right clicking on the glyph to get a zoomed-in version with font reference).

It's not clear to me where the more detailed playing card glyphs used by Ghostty are coming from.

Ghostty draws REVERSE CHECKER BOARD narrow, but widens most other cramped glyphs such as ASTERISM when followed by a space.

Ghostty never stretches glyphs (except emoji and nerd font glyphs in certain cases). It only shrinks them if needed.

What algorithm is used to determine whether it should shrink them?

FWIW, In reference to ASTERISM I was using "widens" here in the particular sense of "Unicode declares this codepoint to have width 'N', but it has been rendered into two cells". Is there a better term of art for this?

In reference to the outline corner triangles, I used "stretched" as a visual description because they look twice as tall as I think they should, based on the behavior of most other terminals I've checked. You said in a previous comment that these glyphs are rendered internally by design, so I'm not sure how I should describe this look. "Tall" maybe?

(And it only does this to symbol-like glyphs. You can see certain arrows, particularly circular ones, overlapping your screenshot, because they're not currently included in the symbols-like category. In Ghostty 1.3 they will be.)

\o/ Something wonderful to look forward to. :-D

So the reverse checkerboard must be small in whatever font it's loaded from. What does ghostty +show-face --cp=0x1f67f say?

U+1F67F « 🙿 » found in face “Noto Sans Mono”.

Both CHECKER BOARD and REVERSE CHECKER BOARD appear full size (two cells wide) in Character Map's right-click zoom. I don't know how reliable that is.

Your screenshot also has a large reverse checkerboard next to it, what glyph is that?

The one on the left is actually two half-block glyphs, specifically used for size comparison.

Here's the decoded version of that little section (again a text paste, not a screenshot):

$ u decode "▀▄ 🙿  🮕🮕"
 2580  ▀   1   1.1  So     Common       UPPER HALF BLOCK
 2584  ▄   1   1.1  So     Common       LOWER HALF BLOCK
   20      1   1.1  Zs     Common       SPACE
1F67F  🙿   1   7.0  So     Common       REVERSE CHECKER BOARD
   20      1   1.1  Zs     Common       SPACE
   20      1   1.1  Zs     Common       SPACE
1FB95  🮕   1  13.0  So     Common       CHECKER BOARD FILL
1FB95  🮕   1  13.0  So     Common       CHECKER BOARD FILL

[danielwe]

DejaVu Sans has the more readable playing card glyphs shown in kitty and gnome-terminal (as determined by selecting "DejaVu Sans Mono" as Character Map's preferred font

Note that DejaVu Sans and DejaVu Sans Mono are different fonts. But I can confirm that the same is true for DejaVu Sans. Here's fontforge:

But... that's also how it renders for me:

(I'm explicitly setting DejaVu Sans as the second font in my config here, otherwise Ghostty would fall back on a different font for me.)

In reference to the outline corner triangles, I used "stretched" as a visual description

Oh I was just referring to the checkerboard/asterism part, i.e., the (re)sizing of outline glyphs loaded from fonts. I agree that Ghostty's sprite triangles stand out because they cover the entire cell rather than maintaining a 1:1 aspect ratio. I can only defer to the maintainers for questions about those, though. I'm just a contributor who has interacted with certain parts of the font rendering stack, but not the sprite part.

What algorithm is used to determine whether it should shrink them?

FWIW, In reference to ASTERISM I was using "widens" here in the particular sense of "Unicode declares this codepoint to have width 'N', but it has been rendered into two cells". Is there a better term of art for this?

Can you tell me more about Unicode's declared width? Are you referring to East Asian Width, where N means Not East Asian/Neutral? I'm more familiar with the stuff that happens between font outlines and rendering than with Unicode glyph properties.

In any case, here's what happens in Ghostty:

• The font is loaded at a certain ppem size. If it's the primary font, that's the size you've specified in your config with font-size. If it's a fallback font, we may tweak that number to make the font metrics match better. For example, if your primary font is on the narrow side (like Iosevka), a fallback CJK font may be loaded at a slightly smaller ppem size such that its ideograph width is no larger than twice the primary font's advance width.

• Given the ppem and the monitor DPI, glyph outlines/bearings can be mapped from font design units to physical pixel units. Usually, the glyph is rendered just like that, without further adjustments on Ghostty's part (the font rendering backend may do some hinting, but that won't change the overall size by much if at all).

• However, if the glyph is in a code block currently considered symbol-ish, and it is followed by something other than whitespace, we make sure it does not protrude outside its character cell. This is a two-step process:

  • Scale down (but never up), preserving aspect ratio, only as much as needed to make the bounding box fit within a character cell (only considering size, not placement).
  • Translate left or right, only as much as needed to not protrude outside the character cell.

  This means that wide glyphs will be shrunk to exactly one cell width. A glyph whose bounding box is narrower than one cell, but that has a large horizontal bearing because it's meant to be centered across two cells, will not be resized, but will be pulled back so the right edge of its bounding box is flush with the right edge of the character cell. (I only discuss width here to keep it simple, but in reality, both steps consider both the horizontal and vertical dimension.)

  The character cell is always the one defined by the primary font, regardless of which font the glyph was loaded from.

I think the important takeaway here is that it's primarily the font designer's responsibility to abide by Unicode's glyph size prescriptions, if any. Ghostty only does a final sense check and possibly the minimal adjustment to ensure the glyph behaves OK in a monospace grid (keep in mind that many of these glyphs may be loaded from non-monospace fonts, like DejaVu Sans in your case, so it's not a surprise that some adjustment may be necessary).

Both CHECKER BOARD and REVERSE CHECKER BOARD appear full size (two cells wide) in Character Map's right-click zoom. I don't know how reliable that is.

Confirmed with fontforge that they are two cells wide, at least in the variable font I got when I installed Noto Sans Mono on macOS just now. But then it also renders as two cells wide in Ghostty for me.

Any idea if your Noto Sans Mono is static or variable, and whether it's recent?

[danielwe]

• However, if the glyph is in a code block currently considered symbol-ish, and it is followed by something other than whitespace, we make sure it does not protrude outside its character cell.

Small correction: Symbol-ish glyphs are in fact always subject to the fitting process, regardless of the content of the subsequent cell. However, if that content is whitespace, the width constraint is two cell widths, not one, so in most cases no adjustment is needed and the glyph passes through unchanged.

[japhb]

DejaVu Sans has the more readable playing card glyphs shown in kitty and gnome-terminal (as determined by selecting "DejaVu Sans Mono" as Character Map's preferred font

Note that DejaVu Sans and DejaVu Sans Mono are different fonts.

Oh yes, I'm aware. I meant that I had set Character Map's default font to "DejaVu Sans Mono", but when I zoomed that particular glyph, it told me it had fallen back to "DejaVu Sans" instead. Apologies for the confusion there.

But I can confirm that the same is true for DejaVu Sans. Here's fontforge:

It's beginning to look like I need to shave another yak of the "learning FontForge" variety. ;-)

But... that's also how it renders for me: (I'm explicitly setting DejaVu Sans as the second font in my config here, otherwise Ghostty would fall back on a different font for me.)

Could the problem be that +show-face and the actual glyph choice are not agreeing in this particular case? Here's what I see:

In reference to the outline corner triangles, I used "stretched" as a visual description

Oh I was just referring to the checkerboard/asterism part, i.e., the (re)sizing of outline glyphs loaded from fonts.

Ah, gotcha.

I agree that Ghostty's sprite triangles stand out because they cover the entire cell rather than maintaining a 1:1 aspect ratio. I can only defer to the maintainers for questions about those, though. I'm just a contributor who has interacted with certain parts of the font rendering stack, but not the sprite part.

Understood.

What algorithm is used to determine whether it should shrink them?
FWIW, In reference to ASTERISM I was using "widens" here in the particular sense of "Unicode declares this codepoint to have width 'N', but it has been rendered into two cells". Is there a better term of art for this?

Can you tell me more about Unicode's declared width? Are you referring to East Asian Width, where N means Not East Asian/Neutral? I'm more familiar with the stuff that happens between font outlines and rendering than with Unicode glyph properties.

Yeah, I'm referring to East Asian Width. The details are in https://www.unicode.org/reports/tr11/tr11-44.html but this line from that document is a quick summary:

In a broad sense, wide characters include W, F, and A (when in East Asian context), and narrow characters include N, Na, H, and A (when not in East Asian context).

The difference between the individual codes partially comes down to whether the character was ever part of the repertoire of a legacy character set, and if so whether the legacy sets in question included one for East Asian characters.

In any case, here's what happens in Ghostty:
[... lots of details ...]

Thank you, that's very helpful in getting a proper mental model of the process!

I think the important takeaway here is that it's primarily the font designer's responsibility to abide by Unicode's glyph size prescriptions, if any. Ghostty only does a final sense check and possibly the minimal adjustment to ensure the glyph behaves OK in a monospace grid (keep in mind that many of these glyphs may be loaded from non-monospace fonts, like DejaVu Sans in your case, so it's not a surprise that some adjustment may be necessary).

Yeah, makes sense.

Both CHECKER BOARD and REVERSE CHECKER BOARD appear full size (two cells wide) in Character Map's right-click zoom. I don't know how reliable that is.

Confirmed with fontforge that they are two cells wide, at least in the variable font I got when I installed Noto Sans Mono on macOS just now. But then it also renders as two cells wide in Ghostty for me.

I tried the same:

It looks like for me the glyph is ~1.5 cells wide, which sounds like the behavior you were talking about in your correction for a symbol-ish glyph taken from a proportional font:

Small correction: Symbol-ish glyphs are in fact always subject to the fitting process, regardless of the content of the subsequent cell. However, if that content is whitespace, the width constraint is two cell widths, not one, so in most cases no adjustment is needed and the glyph passes through unchanged.

Which leaves these questions:

Any idea if your Noto Sans Mono is static or variable, and whether it's recent?

About 5 years old, though I'm not sure how often that font family is reissued:

$ apt show fonts-noto-mono
Package: fonts-noto-mono
Version: 20201225-2

I've got FontForge installed now, and I opened /usr/share/fonts/truetype/noto/NotoSansMono-Regular.ttf, but I'm not sure where to look. How do I find the answer to your static/variable question?

[danielwe]

Does the size of the checkerboard change if you specify the font explicitly? That is, if you use the following Ghostty config:

font-family = DejaVu Sans Mono
font-family = Noto Sans Mono

There's currently a quirk where the matching of font metrics I mentioned (potentially altering the ppem size of fallback fonts relative to the primary) works differently depending on whether its an automatic fallback vs. one specified explicitly in your config. So I'm curious whether the glyph size is noticeably different with a config like this.

I'm not sure how often that font family is reissued

Not too infrequently, actually, see the release history since 2022 here: https://github.com/notofonts/latin-greek-cyrillic/releases.

/usr/share/fonts/truetype/noto/NotoSansMono-Regular.ttf

The file name NotoSansMono-Regular.ttf means that it's a static font. Variable font files have names like NotoSansMono[wdth,wght].ttf.

Could be worth trying to grab the latest version, maybe in the variable version, and see if the size of the checkerboard is any different.

[ldemailly]

Thanks for having noticed these issues - I had reported the playing card one a while ago #7204 (with the heart being the single double width as a result)