Repository navigation
1px line between powerline glyphs #8993
Description
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.
Activity
zadjii-msft commentedon Feb 3, 2021
#5897 and #373 both also look similar as well. I thought we were tracking this somewhere specifically, Michael Niksa (@miniksa) might know where.
miniksa commentedon Feb 3, 2021
There isn't a specific place. Those links and this issue are good enough.
ririshi commentedon Mar 4, 2021
I'm seeing the same issue with
Cascadia Code PL, only when usingcleartypeantialiasing. 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
paradoxtheme:It seems like the triangular shapes are shifted one pixel to the right when using
cleartypeAA, 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 commentedon Aug 23, 2021
I'm also seeing this issue with my setup, on preview 1.10.1933.0.
Config:
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.
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.
miniksa commentedon Aug 26, 2021
Thank you for the investigation and various screenshots, Chris Dailey (@nitz). I'm wondering if Leonard Hecker (@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 commentedon Nov 28, 2021
5 remaining items
Rewrite AtlasEngine to allow arbitrary overhangs (#14959)
kaysond commentedon Jun 15, 2023
Mike Griese (@zadjii-msft) - this looks like its back (or maybe it never went away...) on the right side only, though:
lhecker commentedon Jun 15, 2023
Aram Akhavan (@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.jsonfile 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 commentedon Jun 15, 2023
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?
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 commentedon Jun 16, 2023
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:
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:
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 commentedon Jun 16, 2023
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
#444444this turns into a dark-ish gray.Do you have a proposal what we could do better here?
kaysond commentedon Jun 16, 2023
Leonard Hecker (@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.ttfKnowing nothing about font rendering, here are my observations:
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 commentedon Aug 7, 2023
Bump. Leonard Hecker (@lhecker) Mike Griese (@zadjii-msft) can you reopen this? Based on the above I don't think it's resolved.
lhecker commentedon Aug 7, 2023
Aram Akhavan (@kaysond) I'm sorry, I forgot to respond last time.
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).
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: #8993 (comment))
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 commentedon Aug 8, 2023
Leonard Hecker (@lhecker) Thank you very much for the deep dive! Makes sense to me.
reitowo commentedon Aug 26, 2023
Actually ENABLING AtlasEngine will cause
JetBrain Monoto act like this:lhecker commentedon Aug 26, 2023
@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 commentedon Mar 3, 2024
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 commentedon Mar 3, 2024
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).