Add inverse powerline arrow heads #1490
Conversation
|
Anyone interested to test the glyphs out? I can create patched fonts for your preferred sourcefont and you can try. |
Finii
force-pushed
the
feature/inverted-pl-arrowheads
branch
from
e02364c to
b65020d
Compare
|
Example:
Basic font-set to try out: CaskaydiaCoveInverse.zip (10MB) |
|
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 And isnt there an option in Windows Terminal to change the renderer? |
|
Ah, you see the individual glyphs do have sharp points. 
Here the "landing platform" left of the 'cell', that will cut off the arrow tip of the glyphs to the left of it... 
|
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. 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 While writing this comment @Finii sent a comment, wich is why I'll just reply here.
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... |
|
Maybe for your use-case we should also add those glyphs without landing platforms. That is a classical target conflict 🤔 |
|
We could also move the points a bit inward 🤔
|
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. 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 (?)
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 👍 |
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. :-( Example rules |
but does the Inverse Triangle even need a negative overlap? |
|
Ah sorry I edited your comment, trying to undo. |
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.
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 😬 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. |
I noticed, you got me really confused there 🤣 |
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. 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. |
|
That PR aimed at 4% overlap (from 2%), and was moved to ... parallel universe. And then later, we have this: 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. |
Could we clarify real quick in wich directions positive and negative overlap go respectively? I was imagining the following:
What I meant with that is wether u/E0D7 needed an overlap like this: If something like this would be sufficcient:
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.
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 |
Positive Overlap: Real overlap, resulting glyph overlaps other glyphs 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. |
Fixes: #1451 See also (merged but not released): ryanoasis/powerline-extra-symbols@eb6b972 Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
Finii
force-pushed
the
feature/inverted-pl-arrowheads
branch
from
b65020d to
7543e4a
Compare
|
Rebase on master, force push |
|
@allcontributors |
|
@allcontributors please add @trashner for review |
|
I've put up a pull request to add @trashner! 🎉 |
|
I've put up a pull request to add @a-usr! 🎉 We had trouble processing your request. Please try again later. |
and improve the script code in general Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
|
How it looks like without transparence (
|
|
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 |
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? 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. 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 |
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. I'll add the new patched font into this comment in a minute... Edit: 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 😬 ) |
[why] The inverse powerline glyphs have substantial parts of the glyph outline neighboring the line above and below. The overlap we introduce (1%) is clearly visible with Windows Terminal. [how] Experimentally reduce the vertical overlap for the inverse powerline glyphs to 0. Reference: #1490 in the comments below Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
|
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. 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
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, |
|
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)
In the font file there are three 'systems' to specify the baseline to baseline distance, and upon patching Nerd Fonts removes any But note, this is the font I use in
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. 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 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 |
Fixes: #1451
See also (merged but not released):
ryanoasis/powerline-extra-symbols@eb6b972
Requirements / Checklist
What does this Pull Request (PR) do?
Add the inverted arrow heads that PowerlineExtra inteded to be at
E0D6andE0D7but 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)