Add inverse powerline arrow heads

[Finii]

Fixes: #1451

See also (merged but not released): https://github.com/ryanoasis/powerline-extra-symbols/commit/eb6b9721a893bf97268dfed507680467ef91c189

Requirements / Checklist

• [x] Read the Contributing Guidelines
• [x] Verified the license of any newly added font, glyph, or glyph set

What does this Pull Request (PR) do?

Add the inverted arrow heads that PowerlineExtra inteded to be at E0D6 and E0D7 but never released.

The glyphs are new/hand drawn.

How should this be manually tested?

Any background context you can provide?

What are the relevant tickets (if any)?

Screenshots (if appropriate or helpful)

[Finii]

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.

[Finii]

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

[trashner]

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!

[Finii]

Thanks for reporting!

[a-usr]

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

[Finii]

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?

[Finii]

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...

[a-usr]

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).

[Finii]

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...

• 1419

• 780

• 1245

[Finii]

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 :thinking:

[Finii]

We could also move the points a bit inward :thinking:

[a-usr]

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 👍

[Finii]

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

[a-usr]

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?

[Finii]

Ah sorry I edited your comment, trying to undo.

[Finii]

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 :grimacing: 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.

[a-usr]

Ah sorry I edited your comment, trying to undo.

I noticed, you got me really confused there 🤣

[Finii]

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).

[Finii]

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

And then later, we have this:

• 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 :woman_shrugging:

[Finii]

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....

[Finii]

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

[Finii]

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.

[a-usr]

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

[Finii]

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.

[a-usr]

~Also, I just noticed, there might be an issue with the u/e0b0 Triangle~ (This screenshot is taken from CMDer ( I will from now on start saying wich emulator the screenshots are from ) The yellow comes from the fact that i selected the normal triangle. I dont know why its specifically yellow, but it doesnt really matter) Ignore that, the Inverse Triangle doesnt have negative padding

[Finii]

Proposal: I will reduce the overlap to 3 or 4 %, and make a new test font set. Edit: Maybe even only 2? I believe now the 6% overlap should be reverted anyhow.

But that will take some hours, need to simulate some work for my real life job now ;-D

[Finii]

• It seems to be transparent for fore- and background, I can see the texture everywhere
• The landing platform is ... missing?

[a-usr]

• It seems to be transparent for fore- and background, I can see the texture everywhere
• The landing platform is ... missing?

I edited the comment this screenshot was from, sorry for the Confusion I may have caused.

By toying around I noticed that CMDer only crops unneccesary padding on the side of a glyph if the foreground of the glyph next to it doesnt match with the glyph whose padding is to be cropped

Proof (In CMDer):

Edit: This Info is probably useless, I dont really know what you could do with it

[a-usr]

Upon further Inspection, The Inverse Triangle should definetly be moved to the Left (in CMDer):

[a-usr]

Proposal: I will reduce the overlap to 3 or 4 %, and make a new test font set. Edit: Maybe even only 2? I believe now the 6% overlap should be reverted anyhow.

We could try that too.

But that will take some hours, need to simulate some work for my real life job now ;-D

Thats a good Idea, and I should probably do the same.

[Finii]

What is CMDer? Is that the old terminal one started with cmd? Is that not removed on Windows11? At least I had the impression Windows11 always has Windows Terminal instead of cmd?

The old cmd (based on conhost?) is a problem anyhow as it does not / can not support real unicode but is fixed to 2 byte chars. I linked a lot talk about the problems and why they (MS) want to kill it in other topics. Maybe we should ignore that thing if that is so. It is hard to chase all terminals idiosyncrasies. The WORST is VisualStudio that renders the font differently depending on the NAME :sob: So to get a working patched font you have to keep the NAME or VS will use a different renderer.

Will add a link to the VS behavior here if I find it:

• 1282

Edit: Add this link https://devblogs.microsoft.com/commandline/windows-command-line-unicode-and-utf-8-output-text-buffer/

[a-usr]

What is CMDer? Is that the old terminal one started with cmd? Is that not removed on Windows11? At least I had the impression Windows11 always has Windows Terminal instead of cmd?

CMDer is a (more or less) standalone and portable Console Emulator indipendent from Microsoft (I think)

Website GitHub

Official Image:

[a-usr]

What is CMDer? Is that the old terminal one started with cmd? Is that not removed on Windows11? At least I had the impression Windows11 always has Windows Terminal instead of cmd?

(unnecessary info, if you dont care just skip this)

The terminal (or Console Emulator, Terminal Emulator to be precise, if you want I can try to explain why it is a terminal EMULATOR and not a terminal / what terminal actually means) that you're talking about is conhost.exe. cmd is a so called Shell (like powershell). A Shell needs a Terminal Emulator (or an actual terminal) to interact with the user (because it usually doesnt have any GUI). When starting cmd.exe, by either double clicking on the file in the C:\system32 folder or using the windows run dialog, Windows first starts the default terminal Emulator and then connects the cmd.exe process to it. And as soon as the process is connected to the terminal emulator it can send characters to it.

useful info here:

on my windows 11 machine at least both cmd.exe and conhost are still existant, although i kind of agree with you that conhost.exe, the default terminal emultator up until windows 11, should have been removed. But you're right, Windows Terminal is the standard for Windows 11.

[a-usr]

Hey, any updates @Finii ?

[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. :thinking:

[a-usr]

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

[Finii]

Rebase on master, force push

[Finii]

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

[Finii]

@allcontributors please add @trashner for review

[allcontributors[bot]]

@Finii

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

[allcontributors[bot]]

@Finii

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

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

[Finii]

How it looks like without transparence (tilix)

no hinting, LCD antialiasing

full hinting, LCD antialiasing

[Finii]

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.