Anyone interested to test the glyphs out?

I can create patched fonts for your preferred sourcefont and you can try.
Please specify which font you'd like to test.

Example:

Basic font-set to try out:

CaskaydiaCoveInverse.zip (10MB)

Archive:  CaskaydiaCoveInverse.zip
  Length      Date    Time    Name
---------  ---------- -----   ----
  2198512  2024-01-20 10:01   CaskaydiaCoveNerdFont-BoldItalic.ttf
  2349184  2024-01-20 10:01   CaskaydiaCoveNerdFont-Bold.ttf
  2197532  2024-01-20 10:01   CaskaydiaCoveNerdFont-Italic.ttf
  2122672  2024-01-20 10:01   CaskaydiaCoveNerdFontMono-BoldItalic.ttf
  2270856  2024-01-20 10:02   CaskaydiaCoveNerdFontMono-Bold.ttf
  2121692  2024-01-20 10:01   CaskaydiaCoveNerdFontMono-Italic.ttf
  2269344  2024-01-20 10:02   CaskaydiaCoveNerdFontMono-Regular.ttf
  2347672  2024-01-20 10:01   CaskaydiaCoveNerdFont-Regular.ttf
---------                     -------
 17877464                     8 files

I tested the provided patched fonts in Windows Terminal/PowerShell.

The new glyphs are available at the given code points, they look seamlessly alongside other glyphs and the background transparency works as well!

Thanks for reporting!

I too have tested this, and the new glyphs look very good. The following two pictures are displaying Windows Terminal with Powershell Core and starship.rs

As you can see, the transparency works perfectly fine with this. Thank you so much. Also please do note that the weird corners are most likely caused by a known issue with the antialiasing (at least i thinkt it was the antialiasing) on windows terminal's side. However I would have to test it with a different terminal emulator, wich I will be doing in a minute or so

Now I get what you meant with transparency 🤦‍♀️ And I have something similar myself in the terminal I work with every day (it is semi-transparent so that I can see windows underneath it) but I failed to make the connection.

Thanks for testing!

That the corner gets rounded is indeed ... interresting :-D
But maybe the used point type is wrong (I need to check, I drew the glyphs with Fontforge, I should have used Glyphs3 😬).

And isnt there an option in Windows Terminal to change the renderer?

Ah, you see the individual glyphs do have sharp points.
I believe the reason is that the next glyph has overlap (to avoid the ugly gaps between the glyphs, the dreaded thin vertical lines that result in color subpixel rendering...

Here the "landing platform" left of the 'cell', that will cut off the arrow tip of the glyphs to the left of it...

And isnt there an option in Windows Terminal to change the renderer?

Yes, but that doesnt really change anything. Also I would add some more information with a link to a comment by one of the Windows Terminal Devs explaining why, but i dont have the link rn, so maybe I'll add that later.
Furthermore, there might actually be an issue with the glyph.
I did a quick test with CMDer:

With E0B0 and inverted Colors:

With E0D7:

Also pleaso note that while CMDer doesnt have any issues with transparency, as it jsut makes the entire window transparent, the support for truecolor is absolutely the worst (sorry CMDer). Also apparently there is an issue with the antialiasing, as the three symbols u/02591 , u/02592 and u/02593 get displayed as full blocks. ( These three: ░▒▓ )

While writing this comment @Finii sent a comment, wich is why I'll just reply here.

Ah, you see the individual glyphs do have sharp points.
I believe the reason is that the next glyph has overlap (to avoid the ugly gaps between the glyphs, the dreaded thin vertical lines that result in color subpixel rendering...

That might be the reason for the overlap. Windows Terminals Renderer, and maybe also ConEmu (The underlying program used by CMDer) dont crop glyphs to the correct size (as far as I remember).

Cascadia Cove has even bigger landling platforms:

Maybe we should decrease ours a bit - but if they are too small other people will complain about the faint vertical subpixel lines...

• Increase Powerline glyph overlap #1419
• Bugfix vertical lines in powerline prompts #780
• nf-hack behaves differently than the original hack-font #1245

Maybe for your use-case we should also add those glyphs without landing platforms.
That could be also automated as CALTs; but maybe just to have the glyphs with different codepoints would be enough.

That is a classical target conflict 🤔

We could also move the points a bit inward 🤔

Maybe for your use-case we should also add those glyphs without landing platforms. That could be also automated as CALTs; but maybe just to have the glyphs with different codepoints would be enough.
I don't have that much knowledge regarding fonts and glyphs, could you please ellaborate on the term CALT ?

That is a classical target conflict 🤔

Sadly yes..

However I might have a solution, although it might be a rather dirty and tedious one.

You see, as far as I know, (please do correct me if I'm wrong) Windows Terminal is having the most issues with the overlap on powerline glyphs provided by nerd font.

The reason for that,, is that WT uses the so called "glyph advane width" to determine the width that a glyph should be.
This is better explained by this comment

As per my understanding, this glyph advance width is determined using the width of the character "0".

So, I propose to either manually, or automatically change the widtht of the 0 character in all nerd fonts. As I said, this feels wrong.

I believe that with the correct width this problem would be kind of solved (?)
However youre the expert on this, so I would love to hear your opinion on my Idea

We could also move the points a bit inward 🤔

That would work too!

Edit (Fini): Accidentially edited this instead of quote-reply. Tried to recreate the original comment

Edit (a-usr): I was on it too. Thanks for your help though 👍

We could also move the points a bit inward

Well, that would break the current glyph scaling algorithm; it has no possibility to have a positive overlap on one side and a negative on the other. :-(
And the scaling algo is already very complex with a lot rules for special cases that can be selected

0xe0cc: {'align': 'l', 'valign': 'c', 'stretch': 'xy2', 'params': {'overlap': 0.02, 'xy-ratio': 0.85}},
0xe0ce: {'align': 'l', 'valign': 'c', 'stretch': 'pa', 'params': {}},
'trig': {'align': 'c', 'valign': 'c', 'stretch': 'pa1!', 'params': {'overlap': -0.10, 'careful': True}}

Example rules

Well, that would break the current glyph scaling algorithm; it has no possibility to have a positive overlap on one side and a negative on the other. :-( And the scaling algo is already very complex with a lot rules for special cases that can be selected

but does the Inverse Triangle even need a negative overlap?

Ah sorry I edited your comment, trying to undo.

The reason for that,, is that WT uses the so called "glyph advane width" to determine the width that a glyph should be.

Thanks for linking the Windows Terminal Issue.

Well, all terminals base their cell width on the advance width, that is the "width of the cell", there is no other measure in the font for that purpose.

Differing from the claims in the linked Issue the powerline glyphs in Nerd Fonts are "perfectly scaled". They are bigger than the cell specifically to avoid the thin vertical lines that are due to LCD subpixel rendering. On todays displays everyone should be able to use grayscale subpixel rendering and THAT would work flawlessly. That is the reason why Apple ditched LCD rendering some years ago and now only uses greyscale - it just avoids so many problems.

change the widths of the 0 character in all nerd fonts

Well, a lot people will complain that the patched font does not look exactly as the unpatched font - as the cell width and with that the line length will differ 😬
Anyhow we can scale the powerline glyphs as we want. We could scale them to exactly fit one cell (without overlap), but that will create thin color lines (on all platforms btw) when LCD subpixel rendering is active.

Windows is especially bad in this regard because (at least to my knowledge) there are no clear settings, but one has to walk through this obscure ClearType settings sequence where no clear indication is given which subpixel rendering will be the result. Apart from the fact that ClearType itself is broken even when that settings dialogue has been mastered.

But that is in principle no Windows problem but a general LCD subpixel rendering problem.

Ah sorry I edited your comment, trying to undo.

I noticed, you got me really confused there 🤣

but does the Inverse Triangle even need a negative overlap?

That is a good question. The overlaps are needed if you switch background and foreground color to continue a colored line that starts with a Triangle.. like...:

Imagine you do not want the coffee icon and all the grey stuff on the left side.
The line will start with some (transparent) blanks, than a inverse triangle in blue, then ... a blue full block or a space with background blue, then the tilde with background blue ...
I have no clue how this transparent background color works ;)

But if you have something you might get a thin colored line between the inverse triangle and the full-block / blank, if there is no overlap.

Is that even possible with transparency?

And then. Assuming the Inverse Triangle does not need an overlap because it is used solely in transparent contexts where never ever a overlap is needed.
We still have the problem with the ordinary Triangle overlap hanging into the Inverse Triangle cell and making the point blunt. (see my hand drawn images above).

That PR aimed at 4% overlap (from 2%), and was moved to ... parallel universe.

And then later, we have this:

• Increase Powerline glyph overlap #1419

where the overlap is increased to even 6% !!!

Maybe we should unroll that all and use 2% as decided before, people with vertical lines need to change to greyscale 🤷‍♀️

I guess if we go back to 2% the issue you see is still there but by far less pronounced. Maybe then you can live with that, as all solutions are compromises. What do you think, is that worth a try? (I would need to edit all the glyphs to reduce the landing and then change the percentages in the patcher itself - that takes some time so I want to avoid it if that has not even a change to be fruitful....

BTW, personally I really like the rounded tips :-D

I would revert/change #1419 anyhow, to 4%. It is just that a lot other fonts with their own powerline glyphs have a very big landing patch, Hack, Cascadia Code PL, ... up to 12% iirc; and I thought if they can successfully live with that ... but now I see again the downsides of such a big overlap.
Maybe 3% is good, it covers a bit more LCD subpixel rendering problems (i.e. vertical lines) and still be less obvious in your setting. The 3% was almost invisible lines with most colors iirc, so the vertical line situation would be improved nonetheless.

but does the Inverse Triangle even need a negative overlap?

That is a good question. The overlaps are needed if you switch background and foreground color to continue a colored line that starts with a Triangle.. like...:

Imagine you do not want the coffee icon and all the grey stuff on the left side. The line will start with some (transparent) blanks, than a inverse triangle in blue, then ... a blue full block or a space with background blue, then the tilde with background blue ... I have no clue how this transparent background color works ;)

But if you have something you might get a thin colored line between the inverse triangle and the full-block / blank, if there is no overlap.

Could we clarify real quick in wich directions positive and negative overlap go respectively? I was imagining the following:

Negative Overlap | Glyph | Positive Overlap

but does the Inverse Triangle even need a negative overlap?

What I meant with that is wether u/E0D7 needed an overlap like this:
Overlap | u/E0D7 | Overlap

If something like this would be sufficcient:
No Overlap | u/E0D7 | Overlap

I have no clue how this transparent background color works ;)

Its not that difficult really, and I have even tested this behaviour just now. If a glyph that needs to be rendered has no background color associated with it, the background is made transparent. If the glyph has any background color associated, the background has that color, regardless of wether it matches the background or not. At least Windows Terminal behaves like this at the time of writing this comment. And the transparency Is set within the Windows Terminal Settings, either for all profiles (that dont specify their own), or per profile.

BTW, personally I really like the rounded tips :-D

Have to agree with you on that one, its just that its less round and more cut-off. But I tink I could manipulate that by forcing a different cell width

Could we clarify real quick in wich directions positive and negative overlap go respectively?

Positive Overlap: Real overlap, resulting glyph overlaps other glyphs cell
Negative Overlap: Glyph has an empty border to the other cell, the opposite of "being bigger than the cell we should fit in": "be smaller than the cell".

The Overlap works in all 4 directions up/down/left/right. Well, with exceptions and specials, but that is the general concept.

Have 1% of overlap into all (top buttom left right) cells to cover up all these round-error-LCD-rendering problems.

Hey, any updates @Finii ?

Hey, any updates @Finii ?

With the upcoming release it would be good to have this in.
I need to pencil this down on paper to find some solution that does not break the 'ordinary' / normal Powerline glyphs and still solves the overlapping problem with the new ones. 🤔

With the upcoming release it would be good to have this in. I need to pencil this down on paper to find some solution that does not break the 'ordinary' / normal Powerline glyphs and still solves the overlapping problem with the new ones. 🤔

I have been using the new glyphs for the past 2 months now, and if I'm being honest, I quite like the Horizontal overlap now. As you said earlier, the round-ish look has something unique. Sadly not everyone likes that look. But I think it would be nice to keep the PL glyphs with the overlapping problem somewhere in the repo so that people could use them instead of the fixed PL glyphs to patch their fonts if they want

Rebase on master, force push

@allcontributors
please add @a-usr for review and idea
please add @trashner for review

@allcontributors please add @trashner for review

@Finii

I've put up a pull request to add @trashner! 🎉

@Finii

I've put up a pull request to add @a-usr! 🎉

We had trouble processing your request. Please try again later.

How it looks like without transparence (tilix)

no hinting, LCD antialiasing

full hinting, LCD antialiasing

I think we should use this PR for now, and can develop further over time. If this is in the release maybe more people will feedback.

Thank you so much for adding this Icon. Absolute life savior (wish there was an easier way to find out about it than this PR). I have noticed a minor problem which is that it seems that the icon is 2px too tall:

Does that also happen with the non-inverse arrow head? I dont think the inverse version gives you any benefits in this use case, but feel free to correct me

@a-usr it does not happen with the regular arrow head (as far as I can tell). The inverse arrow does give me a deciding benefit since I do use the transparency (just outside these screenshots). It also keeps all of my separators consistent

@a-usr it does not happen with the regular arrow head (as far as I can tell). The inverse arrow does give me a deciding benefit since I do use the transparency (just outside these screenshots). It also keeps all of my separators consistent

I see. In that case you'll have to wait until @Finii finds time to check on his GitHub account. But since that might take some time, if the overlap really annoys you I recommend that you use the non-inverted arrow as much as possible for the time being

Hmm, what is your OS and terminal emulator?
And which font do you use (if possible where did you download it, exact version number would also be great).

The problem is that the 'top' of the glyph is defined by two different means, the normal arrow just is as high as one line; while the inverted arrow ends in a outline on top. The coordinates are handled differently by font renderers usually - they need to be rounded and maybe subpixel rendered.

If you are on a system where you can select the subpixel rendering it might be an idea to change that.

But lets check for some random current font...

The top outline is at vertical position 1912 and the bottom (not shown) at -492.

And the line coordinates are:

Ah yes!

There is a 12 unit difference which is about 0.5%, and we see about 1% (i.e. 1 pixel) in your screenshot.

Vertical overlap is designed as 1% in the code:

Are you willing/available to try a variant here, with 0% overlap? I am not sure that will introduce a subpixel problem 🤔

Happy to try out a variant with 0% overlap. I wonder if that will help fix my problem.
I also noticed that the inverse regular don't line up correctly such that they form a perfect arrow:

As for my font I use the FiraCode variant of NerdFont. I believe I have the latest version installed (I use Scoop and it claims 3.2.1). As for my Terminal Emulator I use Windows Terminal V1.20.11781.0 using Powershell as my shell with Starship for the Prompt

also noticed that the inverse regular don't line up correctly such that they form a perfect arrow

That problem is already mentioned right in the top of this thread/PR, with a possible fix given in #1490 (comment) above (I sketched exactly that image on paper there ;)

The culprit are the 'landing platforms' on the left resp right that help avoid the vertical colored lines problem.
Are these adjacent triangular things a common setup?

I'll add the new patched font into this comment in a minute...

Edit:

FiraCodeNerdFont-Regular.zip

Green is the new outline:

--- a/font-patcher
    b/font-patcher
@@ -853,8  853,8 @@ class font_patcher:
                 box_enabled = False # Cowardly not scaling existing glyphs, although the code would allow this
 
         # Stretch 'xz' or 'pa' (preserve aspect ratio)
-        # Supported params: overlap | careful | xy-ratio | dont_copy | ypadding
-        # Overlap value is used horizontally but vertically limited to 0.01
         # Supported params: overlap | voverlap | careful | xy-ratio | dont_copy | ypadding
         # Overlap value is used horizontally but vertically limited to 0.01 (or specified by voverlap)
         # Careful does not overwrite/modify existing glyphs
         # The xy-ratio limits the x-scale for a given y-scale to make the ratio <= this value (to prevent over-wide glyphs)
         # '1' means occupu 1 cell (default for 'xy')
@@ -878,8  878,8 @@ class font_patcher:
             0xe0b3: {'align': 'r', 'valign': 'c', 'stretch': '^xy', 'params': {'xy-ratio': 0.7}},
 
             # Inverse arrow tips
-            0xe0d6: {'align': 'l', 'valign': 'c', 'stretch': '^xy', 'params': {'overlap': 0.05, 'xy-ratio': 0.7}},
-            0xe0d7: {'align': 'r', 'valign': 'c', 'stretch': '^xy', 'params': {'overlap': 0.05, 'xy-ratio': 0.7}},
             0xe0d6: {'align': 'l', 'valign': 'c', 'stretch': '^xy', 'params': {'overlap': 0.05, 'xy-ratio': 0.7, 'voverlap': 0.0}},
             0xe0d7: {'align': 'r', 'valign': 'c', 'stretch': '^xy', 'params': {'overlap': 0.05, 'xy-ratio': 0.7, 'voverlap': 0.0}},
 
             # Rounded arcs
             0xe0b4: {'align': 'l', 'valign': 'c', 'stretch': '^xy', 'params': {'overlap': 0.06, 'xy-ratio': 0.59}},
@@ -1502,8  1502,9 @@ class font_patcher:
                 logger.critical("Conflicting params: overlap and ypadding")
                 sys.exit(1)
             if overlap:
                 voverlap = sym_attr['params'].get('voverlap')
                 scale_ratio_x *= 1.0   (self.font_dim['width'] / (sym_dim['width'] * scale_ratio_x)) * overlap
-                y_overlap = min(0.01, overlap) # never aggressive vertical overlap
                 y_overlap = voverlap if voverlap is not None else min(0.01, overlap) # never aggressive vertical overlap
                 scale_ratio_y *= 1.0   (self.font_dim['height'] / (sym_dim['height'] * scale_ratio_y)) * y_overlap
 
             # Size in x to size in y ratio limit (to prevent over-wide glyphs)

(Took actually not 'a minute' but 40 😬 )

Just tried the patched font. It is a big improvement over the previous in that it has very little offset. However there seems to still be 1 subpixel that is wrong. It feels offset downwards by .5 of a pixel:

This is 1 physical pixel too low vertically on a 4k monitor so its far better and barely noticable. But its existence is messing with me.

Overall a success though.

This does make the Powerline arrow stand out with its offset though and clearly shows the box you were talking about:

Hmm. The overlap is there to prevent the subpixel-rendering issues.
I must admit that I never saw any problem with horizontal lines that show up. As a result I decreased the vertical overlap to 1% some time back. Maybe it is even not needed at all. The overlap has been there since ... ancient times. Buit changing that would require a broad survey of terminal emulators and how they would handle the font without vertical overlaps.
🤔
Windows Terminal is one of the easier terminals to generate fonts for; kitty for example has much stronger opinions how fonts shall look like and squashes the glyphs into submission if one of their assumptions is violated 😬

Well, if I look at my current text size here, with the release font, I spot some small problems but they seem to have too little overlap

Tilix on X Windows

With a bigger font size the effects change

Possibly this is because the line 'boundaries' are always on a pixel boundary (i.e. it's either yellow or white, no subpixel rendering), while the glyphs outline is subpixel rendered to fall exactly on a specified coordinate and rendered lighter if it does not match.

But you can clearly see, tilix seems to render the inverted triangle rather too small albeit the 1% overlap is still in place in the font I have installed. So without it it would look even more ugly - on tilix. So this is a compromise how the powerline glyphs that have a filled border to the line above/below behave and can not be solved perfectly for all.

Shouldn't the glyph simply be the height if 1em (or whatever term there is for the bounding box for a char in a font). The same amount of vertical space that a space takes up.

I have never created a font before so I have no idea how it works but I am surprised with how much difference there is between font renderers in the various terminal applications

The 'problem' with the powerline glyphs is that they are supposed to fill exactly "one line".

In the usual fonts here we have a 'advance width' for each glyph, that indicates how far the cursor moves to the right to draw the next glyph. There is no such easy thing for the baseline to baseline distance, as the line height is called.

As I showed above here: #1490 (comment)

The top outline is at vertical position 1912 and the bottom (not shown) at -492.

In the font file there are three 'systems' to specify the baseline to baseline distance, and upon patching Nerd Fonts removes any gap (as that complicates everything beyond any reasonable reason;) and makes the 3 systems all alike. Usually they are NOT in the unpatched fonts.

=== patched-fonts/CascadiaCode/Regular/CaskaydiaCoveNerdFontMono-Regular.ttf ===
Version 2111.001; VTT 6.35;Nerd Fonts 3.2.1
SHA1: 380a8c3bd92efda8e7ac47959244a996bcf5578d

::::::::::::::::::::::::::::::::::::::::::::::::::
  Metrics
::::::::::::::::::::::::::::::::::::::::::::::::::
[head] Units per Em:   2048
[head] yMax:           2304
[head] yMin:          -989
[OS/2] CapHeight:      1420
[OS/2] xHeight:        1060
[OS/2] TypoAscender:   1900
[OS/2] TypoDescender: -480
[OS/2] WinAscent:      1900
[OS/2] WinDescent:     480
[hhea] Ascent:         1900
[hhea] Descent:       -480

[hhea] LineGap:        0
[OS/2] TypoLineGap:    0

::::::::::::::::::::::::::::::::::::::::::::::::::
  Ascent to Descent Calculations
::::::::::::::::::::::::::::::::::::::::::::::::::
[hhea] Ascent to Descent:              2380
[OS/2] TypoAscender to TypoDescender:  2380
[OS/2] WinAscent to WinDescent:        2380

::::::::::::::::::::::::::::::::::::::::::::::::::
  Delta Values
::::::::::::::::::::::::::::::::::::::::::::::::::
[hhea] Ascent to [OS/2] TypoAscender:       0
[hhea] Descent to [OS/2] TypoDescender:     0
[OS/2] WinAscent to [OS/2] TypoAscender:    0
[OS/2] WinDescent to [OS/2] TypoDescender:  0

::::::::::::::::::::::::::::::::::::::::::::::::::
  Baseline to Baseline Distances
::::::::::::::::::::::::::::::::::::::::::::::::::
hhea metrics: 2380
typo metrics: 2380
win metrics:  2380

But note, this is the font I use in tilix.

• The b2b is for all 3 systems 2380
• The bounding box height of E0D7 is 2404 (see linked comment)
• And still it is rendered smaller than the colored line distance

I believe the problem is that the actual font renderer does not care about lines as such - it does work also with glyphs that span multiple 'lines' with swashes, like this:

All parts of the glyph, the outline, this is drawn, and it is drawn with a resolution higher than one pixel. Using only the pixel resolution make the font look very jagged so noone nowadays does not use subpixel rendering. It makes pixel more or less black/grey to create a visually pleasing round form perceptionally.

But then terminal emulators have the concept of 'cells' (that we also use here, but that is nonexisting in fonts). And they for example want to fill one line with a yellow and one line with a white background. The emulator can calculate the exact baseline boundary, but that will be on some partial pixel, like 10.213 pixels down. What to do now? I have never seen subpixel rendering for background coloring, so it just fills all background pixels in pixel line 0 to 10 with yellow and from 11 to 20 with white. Obviously that does not coincide with the glyph subpixel exact boundaries. The glyph says it shall fill from 0 to 10.213 with black, and it renders this as 0-10 in black and 11 in some light grey, 21% grey presumably. And now you have the effect you see, the glyph seems to be too tall.

I would guess the terminal emulators push the line distances to be an exact integer number of pixels, to get very sharp boundaries if the background color changes. It then places the glyphs into THAT lines, more or less ignoring what the font's baseline to baseline distance is, because it can not possibly match.
Tilix seems to round that up typically (to be never too narrow), while Windows Terminal maybe rounds exactly or always down, or whatever.

If one thinks about fonts one has to forget 'cells'. This is not how fonts work. And font rendering is always designed to work in a 'proportional' environment like for example Writer or Word. With terminal emulators the "lines" and such is just bolted on top and is implemented by the terminal emulator differently everywhere.
Some for example do not allow the glyphs to extrude outside the 'cell' and they just scale the glyph down until it fits. This breaks any alignment of course and looks more or less ugly if glyphs extrude into the neighboring 'cells' like the powerline glyph landing platforms (that are needed to prevent the vertical colored lines that come from the subpixel rendering 😬 )

Btw I have (almost) no clue how terminal emulators really do their job; all what I know is by observing their behavior to different font details. Occasionally I look into code but I try to avoid it. I come from a publishing background so I know rather well how the font renderer works - on a blank canvas like a sheet of paper ;-)

Edit: Typo