p10k prompt is not displayed correctly with AtlasEngine

[Mystic8b]

Windows Terminal version

1.19.10302.0

Windows build number

22631.3085

Other Software

WSL Ubuntu latest
ZSH
p10k (rainbow theme)
MesloLGS Nerd Font (from p10k repo)
9px font size

Steps to reproduce

Setup zsh, p10k, set rainbow theme by using p10k configure
Select MesloLGS NF with a font size of 9px in the terminal settings with AtlasEngine enabled.

Expected Behavior

Smooth borders of the prompt, like in this screenshot with AtlasEngine disabled

Actual Behavior

Incorrect prompt rendering

[lhecker]

Given your font size of 9pt (FYI: not px - our font sizes are in pt) and an apparent line height of 15 pixels, I'm assuming that you're using a display scale of 100%, right?

In that case, please delete your Meslo NF font and then download and install the latest version here: https://www.nerdfonts.com/font-downloads (At the time of writing the direct link is: https://github.com/ryanoasis/nerd-fonts/releases/download/v3.1.1/Meslo.zip)

This is because I found that the issue you've described does not occur on my PC in that case:

But you can see there that the "s" in ssh has the exact same pixel height as yours and the white box is also 15px tall. BTW this is super opinionated, but I personally definitely recommend enabling ClearType if you're using a 100% scale monitor. It'll add a somewhat ugly blue line in the rounded box, but it'll make the text a lot more legible in my opinion.

That aside, you can set fractional font sizes which allows you to solve this issue under most circumstances.

Lastly, I consider this an issue with the font itself, as we simply draw the glyphs exactly as they were designed. The only text renderer simply didn't have this issue because it cut off any overly large glyphs or distorted them if necessary. That has caused a ton of issues in the past and I personally don't wish to open that can of worms again. 😟 But this is a common issue with a lot of fonts (including our own Cascadia Code), and we intend to ship this workaround at some point: #5897

As such I'll close this issue for now and I'd suggest upvoting and following #5897 if you're interested in seeing this resolved properly in the future (we loosely use upvotes to see what features to implement in the future).

[Mystic8b]

This is because I found that the issue you've described does not occur on my PC in that case:

Your example has the same problem. One pixel bottom part is missing

I have already tried all variations of this font, there are problems everywhere. And the problems are only when using AtlasEngine. And you released it with the default renderer. You must fix this.

P10k uses its own version of the font and the developer says that the problem is in the terminal.

[lhecker]

I believe it's important to mention that your screenshot is exactly how DirectWrite renders that glyph and there's no missing pixel on our end:

I do think it's weird though that the last row of pixels seems like it gets cut off by DirectWrite. I'll investigate why that occurs and if it's something we do wrong, I'll reopen this issue and use it to track a fix for the missing pixels.

---

That aside, I always agreed that this is an issue with Windows Terminal and that it needs to be fixed urgently, if possible. But in my opinion #5897 presents the best path towards fixing the issue and that's why I closed your issue, as I considered it to be a duplicate. I don't mean to ignore your issue and I apologize if it felt that way.

It's correct that we used to special case powerline glyphs in the past, but the way we did it was to "scale" glyphs to perfectly fit their box. This had a lot of subtle problems: "pixel perfect" fonts failed to work, font fallback didn't work correctly, and sometimes glyphs were misaligned. A lot of people complained about it over the years. Here's some: #8993, #13527, #13662, #14877

Scaling glyphs like that is something no other terminal did. If anything, they all use a technique as described in #5897 as it has none of the issues above, so I'll use #5897 to track a fix for this. I'll see if I can get it done sooner rather than later.

[lhecker]

The bottom pixels are cut off because DirectWrite defaults to DWRITE_RENDERING_MODE_DEFAULT which seems to ignore the GASP table at small font sizes. If I explicitly use DWRITE_RENDERING_MODE_NATURAL_SYMMETRIC it works as expected:

If more people would be interested in making this configurable, we could consider adding it as a setting. Right now, I'm not sure whether there's any benefit to making this configurable, since it doesn't address the powerline issue.