1px line between powerline glyphs

[kaysond]

Environment

Windows build number: Microsoft Windows [Version 10.0.19042.746]
Windows Terminal version (if applicable): 1.5.10271.0 & 1.6.10272.0

Steps to reproduce

Install any nerdfont Set up anything that uses powerline glyphs (in my case, bobthefish plugin on fish shell)

Expected behavior

Clean rendering/placement of powerline glyphs (see Color schemes @ https://github.com/oh-my-fish/theme-bobthefish)

Actual behavior

The glyphs have a 1px line of the adjacent glyph color Funnily enough, you can see the same thing in the powerline setup tutorial: https://docs.microsoft.com/en-us/windows/terminal/tutorials/powerline-setup

Setting "useAcrylic": true and "acrylicOpacity" : 0.899 fixes one glyph, but not the other:

I've tried a variety of rendering options, fonts, sizes, etc, but none completely solve the problem. I also have the Windows text scaling set to 100%. I am on a high-dpi monitor (2560x1440) though.

I searched around and found #3626 #455 #4930 #633 #6669 but those aren't quite what's happening here. Sorry if I missed a dupe.

[zadjii-msft]

5897 and #373 both also look similar as well. I thought we were tracking this somewhere specifically, @miniksa might know where.

[miniksa]

There isn't a specific place. Those links and this issue are good enough.

[Ririshi]

I'm seeing the same issue with Cascadia Code PL, only when using cleartype antialiasing. I tested it on font sizes between 10 and 20 and it seems like all sizes suffer from it.

Example below with Powershell 7.1.2 using oh-my-posh v3 and the paradox theme:

It seems like the triangular shapes are shifted one pixel to the right when using cleartype AA, showing the background color. I'm unsure why the leftmost shape has a red line, though. If you look closely, you can also see the lines on the other triangular shapes. Upscaled 800% with nearest neighbour scaling:

[nitz]

I'm also seeing this issue with my setup, on preview 1.10.1933.0.

Config:

    "defaults": {
      "fontFace": "MesloLGS Nerd Font",
      "fontWeight": "normal",
      "useAcrylic": true,
      "acrylicOpacity": 0.4,
      "hidden": false,
      // also occurs worse with 'cleartype', but not with 'aliased'
      "antialiasingMode": "grayscale",
      "fontSize": 10
    },

Example of what I'm seeing, definitely with the  characters, but also with several other glyphs.

I thought, perhaps it's because I'm using the non-mono NF? Well, that produces even weirder issues switching to it.

"fontFace": "MesloLGS Nerd Font"	"fontFace": "MesloLGS Nerd Font Mono"
"Apple" glyph cut off, as are the triangle and cap characters showing issues.	Apple glyph no longer cut as all symbol glyphs appear smaller, but the caps are still showing issues. Additionally, the 'flame' glyphs appear to be doubled.

It definitely seems to be something related to the antialiasing, given that using "aliased" doesn't show the issue at all. Meanwhile, "cleartype" can make it appear worse. Additionally, it seems that the fontSize has an effect on it as well.

"aliased"	"cleartype"	"grayscale"
No rendering issues, but not lovely to look at.	Issues left round cap, as well as triangle glyphs.	Triangle issue gone, cap issue persists.

[miniksa]

Thank you for the investigation and various screenshots, @nitz. I'm wondering if @lhecker's plans to do #10461 will end up sorting this out since I believe it uses slightly different measurements and anti-aliasing phases than what we're currently doing.

[SHJordan]

Is there a way to disable cleartype within VS Code and IntelliJ Idea? It fixed my issue on windows terminal.

[MattBDev]

I just wanted to share that on 1.13.10983.0 with Windows 10 19043.1645 (21H1) and with experimental.useAtlasEngine enabled, the issue still occurs. I hope this issue will be fixed "soon". 😄

[SHJordan]

What fixed it for me, as a AMD GPU user, was disabling VSR(Virtual Super Resolution) and Integer Scaling. Both settings can be found on AMD SOFTWARE. Hope it helps.

[kaysond]

I'm now running Ubuntu 22.04 LTS on terminal version 1.13.11431.0 on Win10 Pro 19044.1766 (21H2) and with the following appearance settings, this seems to be fixed:

[kaysond]

@zadjii-msft - this looks like its back (or maybe it never went away...) on the right side only, though:

[lhecker]

@kaysond We use the so called "glyph advance width" of the character "0" to determine the width of the cells in the terminal. That value might not always match powerline glyphs exactly (down to the pixel), because many such fonts aren't designed perfectly either. I would definitely recommend trying out the latest version of your font first. Maybe it got improved already?

But if you open the settings.json file via the settings dialog you can explicitly override that cell width like so:

{
    "profiles":
    {
        "defaults":
        {
            "font":
            {
                "face": "...",
                "cellWidth": "10px"
            }
        },
    },
}

You'll have to experiment a little bit what value works best for you. The setting works just like CSS units so you can also use a relative value like 0.5ch.

[kaysond]

@kaysond We use the so called "glyph advance width" of the character "0" to determine the width of the cells in the terminal. That value might not always match powerline glyphs exactly (down to the pixel), because many such fonts aren't designed perfectly either. I would definitely recommend trying out the latest version of your font first. Maybe it got improved already?

I tried the latest version of the font from nerdfonts, and it didn't help. Presumably since the glyphs are added programmatically, they'd be the same width... I could be wrong though - how would I test this?

But if you open the settings.json file via the settings dialog you can explicitly override that cell width like so: You'll have to experiment a little bit what value works best for you. The setting works just like CSS units so you can also use a relative value like 0.5ch.

That doesn't really work - looks like the default is 9px; if I change it down to 8px, it compresses everything else in the terminal prompt, ruining the rest of the look. Seems fractional values aren't possible (I was wondering if it's a resolution thing)

[kaysond]

So I did some digging, and this is definitely a rendering issue.

The glyphs themselves are exactly the same width. You can see the source here:

• https://github.com/ryanoasis/powerline-extra-symbols/blob/master/src/uniE0B0_Powerline_normal-left.eps
• https://github.com/ryanoasis/powerline-extra-symbols/blob/master/src/uniE0B2_Powerline_normal-right.eps

I tried two different nerdfonts: Ubuntu Mono and Roboto Mono. These should both have the exact same glyph. Depending on the font size and the font, the issue appears or goes away:

We use the so called "glyph advance width" of the character "0" to determine the width of the cells in the terminal.

Given that this is the case, and that the font size matters and the problem only happens on one direction, I wonder if there's some kind of rounding/flooring error when the glyph is being scaled...

[lhecker]

Our terminal doesn't allow proportional font rendering (just like most other terminals), but Nerd Fonts are not "perfectly" monospace, visually speaking. They would need manual hinting to work correctly here. You can verify our renderer's behavior with Microsoft's reference text renderer "VisualTrueType" (VTT). In theory it should match it exactly (after pressing Alt+G / enabling GASP in VTT).

I've tested it with the NF (non-Mono) variant and the latest version 3.0.2 and the result looks immediately exactly like what you're reporting:

It's the same 21px tall as in your screenshot, has the same single, dark pixel at the bottom, and shows that the right border has been anti-aliased in the same, unfortunate way: It's tinted blue in this case, but with your current foreground color of #444444 this turns into a dark-ish gray.

Do you have a proposal what we could do better here?

[kaysond]

@lhecker - this is a cool tool, thanks! I tried to match your setup with ClearType settings (I did turn on GASP mode) and while it's not exacty the same, it seems to be close enough in terms of dimensions... Btw, I'm using UbuntuMonoNerdFontMono-Regular.ttf

Knowing nothing about font rendering, here are my observations:

• The width of the ClearType "0" is 10px. The width of non-CT is 8px.
• The left and right powerline glyphs are rendered exactly the same, just flipped, at 11px or 12px (non-CT, CT).
• The full height block is 10px or 12px

The most interesting thing to my eye, though, is that the space between the vertical blue lines, which I've marked, is always10px. I'm guessing maybe that's the glyph width?

If you look down a column, you'll see that all those glyphs line up very nicely. Even with the anti-aliasing, if a 10px wide column were used, corresponding to those lines, and the glyphs were rendered and positioned as in VTT, there would be no gaps in the rendering between powerline glyphs, right?

[kaysond]

Bump. @lhecker @zadjii-msft can you reopen this? Based on the above I don't think it's resolved.

[lhecker]

@kaysond I'm sorry, I forgot to respond last time.

The most interesting thing to my eye, though, is that the space between the vertical blue lines, which I've marked, is always10px. I'm guessing maybe that's the glyph width?

That's the advance width. It indicates how much the "cursor" moves when writing that glyph. For monospace fonts the advance width is usually always the same for all glyphs, but of course that's not a strict requirement. Glyphs might also be wider than the advance width. That's especially true for cursive/italic text. When you mix in font fallback however, almost no monospace text ends up being strictly monospace. (But Windows Terminal forces glyphs into a monospace grid.)

That width is not measured in pixels, but rather in "font design units". The header of each .ttf file includes a "units per em" (UPM) field, which indicates how many units result in 1em. Usually that value is 2048, but 1000 or similar are also common. All values in .ttf are expressed in "font design units". The advance width for Consolas for instance is 1126 and it has an UPM of 2048, which results in an advance width of about 0.55em. At a font size of 20pt, this results in an advance width of pretty much exactly 1126 / 2048 * 20 = 11pt. Ubuntu Mono NF has an advance width of 500 and a UPM of 1000 (= 10pt).

If you look down a column, you'll see that all those glyphs line up very nicely. Even with the anti-aliasing, if a 10px wide column were used, corresponding to those lines, and the glyphs were rendered and positioned as in VTT, there would be no gaps in the rendering between powerline glyphs, right?

Yep, there would be no gaps. (But there would be slightly visible red/blue lines when ClearType is used, because the glyphs do slightly overlap. This comment shows them: https://github.com/microsoft/terminal/issues/8993#issuecomment-790795815)

But the problem is that you set VTT to a font size of 20pt at a display resolution of 72 DPI (the default in VTT). 72 DPI is the resolution of "pt" but if you want "px" at 100% display scale you need to choose 96 DPI (150% display scale = 144 DPI, and so on).

For instance, the 0 glyph at 13pt and 96 DPI looks like this (17ppem, 8 dx (width), 11 dy (height), I forgot to enable GASP mode - it will look a bit different then):

The problem is the advance width there, which is "8 43/64 dx", or 8.67px. We currently round that value to the nearest pixel value which is 9px (as you've already found), but you've also said that 8px feels too squished.

If we were to support a technique called "subpixel positioning", we could probably solve the issue. It's a common technique in modern font rendering where you (for instance) have 3x the horizontal resolution for glyph positions. For every glyph you prepare 3 versions with a 0/3rd, 1/3rd and 2/3rd pixel offset. This will make them all 3 look a tiny bit different.

So, if you encounter a glyph coordinate like 8.67px you choose the 3rd variant with the 0.67px offset. If you have 15 "0"s in a row you're at coordinate 15*8.67 = 130px, so you chose the 1st variant. But significant parts of the Windows Terminal code base treat pixel coordinates as integers, so I personally don't intend to pursue that topic within the next year(s). There are areas that are in much worse shape than our text rendering (like our Unicode support for instance), so I need to focus on that. The same is true for the other team members. I would be extremely happy about PRs working towards that goal, however. I believe a request to support fractional advance widths would warrant a new issue since it would improve more than just powerline glyphs, so I'll open one now and put it on the backlog (#15805).

[kaysond]

@lhecker Thank you very much for the deep dive! Makes sense to me.

[reitowo]

Actually ENABLING AtlasEngine will cause JetBrain Mono to act like this:

[lhecker]

@cnSchwarzer AtlasEngine disabled, JetBrainsMono Nerd Font, 10pt:

Both, the old and new renderer have the exact same issue. Just at different font sizes. If you use 13pt with AtlasEngine enabled, instead of 12pt, the gaps will be gone.

[Kayzels]

@cnSchwarzer AtlasEngine disabled, JetBrainsMono Nerd Font, 10pt:

Both, the old and new renderer have the exact same issue. Just at different font sizes. If you use 13pt with AtlasEngine enabled, instead of 12pt, the gaps will be gone.

Encountered the same. With any font size except 10pt, JetBrains Mono Nerd Font seems fine. But at size 10 specifically, the glyph e0b6 has this line next to it whenever text follows.

Unfortunately, size 9 feels way too small, and size 11 too big. I'm wondering if there is any solution to fix this specifically for size 10? Closest solution I've found is to set the font size to 10.5.

[lhecker]

FYI #16729 was merged recently and it fixes this issue fundamentally. It will ship in 1.21 in a few months. In the meantime, you can find the Canary version that has it already here: https://aka.ms/terminal-canary-installer

If you find any issues with that version, please don't comment here, but open a new issue instead (a simple screenshot of the issue will be sufficient).