Increase Powerline rounded overlap

[Finii]

Description

Similar to

• Increase Powerline glyph overlap #1419

this increases the overlap of the rounded Powerline glyphs to 6%

Patch result with the PR applied, note the increased overlap into next/previous 'cell'
Green outline is new glyph

Fixes: #1547

Requirements / Checklist

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

What does this Pull Request (PR) do?

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]

@luebking Do you want to try this out? I can patch you a font for that... (please tell me which you prefer)

[luebking]

I was already looking which branch holds the change and will happily be your guinea-pig, out of pure altruism and totally not to get the rounded caps to work for at least myself ;)

I have fontforge installed and can probably run the patcher locally, if that helps you anything.

Edit: SauceCode - there's exactly one thing Adobe is actually really good at.

[Finii]

Running, will upload the result here.

[Finii]

Some subset?

[luebking]

cat fonts.zip | curl -F 'file=@-' 0x0.st

[Finii]

I guess I don't get it...?

[luebking]

This would upload "fonts.zip" to https://0x0.st and get you a tiny URL in return.
The quota is 512 MB and the uptime size dependent (bigger files are deleted earlier)

It's the universal weapon of the archlinux forum :)

[Finii]

It's the universal weapon of the archlinux forum :)

Nice thing, good to know.

Anyhow, here just the basic RIBBI set(s)

SauceCodeProNF-Rounded.tar.gz

[luebking]

Good news ahead, it's much better.

urxvt (main testcase because of the more precise size control and main TE)

Even w/ lcddefault there's no subpixel line in even pixel sizes.
Odd pixelsizes retain them until 15px
(this can be a problem because the font is "flatter" for even pixels sizes, at least on small ones)

lcdlight shows the same behavior, but more faint
(esp. on dark backgrounds tolerable, but not perfect. Still what one might opt for for smaller fonts because the filter is, subjectively, superior to lcdlegacy and for small sizes the odd height looks better)

I was unable to get any subpixel line on lcdlegacy or lcdnone

The artifact btw. seems a bit more pronounced on e0b6 "(]" than e0b4 "[)" (but that could be color psychology because they'll expose differently colored subpixels)

urxvt at 11px and lcddefault (on the bottom you can just about spot the subpixel line in the blue prompt)

A bigger problem on xterm and alacritty

… turns out to be centereing the glyph - for many sizes it'll be offset by one px or not be "round"
(this is almost not a problem w/ urxvt except for some very small sizes)
On 8.5pt alacritty has the glyph 2px too small

=> I'd have to restore the previous fonts to see whether that was a problem there as well, but it also exists for the triangular caps.
This problem vanishes at 19pt what at 96dpi should be ~25px what means ~11pt at 160dpi
Otoh I don't get subpixel lines there.

In conclusion

HiDPI users will probably not face any problems w/ this variant, on lower resolutions it takes some fiddling but it's possible to edge out solutions.

[luebking]

The vertical centering of the glyph is actually an antialiasing problem, only.
These are on alacritty for 8.5pt and 9pt at 96 DPI:

The indention/offset is because of the faint/asymmetric corner pixels.
Removing the antialising etc. it looks like the glpyh is rendered too small (8.5pt):

I'll revert to the release version and report on the difference in a couple of hours.

[luebking]

The release version exhibits the exact same problem in alacritty (plus the subpixel line) - so the situation hasn't gotten any worse wrt the antialiasing but better wrt subpixel rendering in that case.

Looking close at the triangular glpyh

it probably has the exact same "problem" but going from the square into the 45° angle just doesn't look off from a distance (the left-outmost pixels should probably be interpolated but are in fact the background of the adjacent block.
Blue and pink for better visualization of what actually happens in alacritty (MR font):

[Finii]

I guess we now look into specific alacritty problems.
This looks like it assumes the 'cell' height to be different from what the font wants.

Some problems are not solvable with some clients. For example we have a bit of 'overhang' into previous/next cell to paint over the faint line. But some clients shrink glyphs that are bigger than the expected cell size to exactly fit, and then we end up with a not-tall-enough glyph that still has a faint line 😬

These clients that handle the font rendering all on their own, to be faster or better than the system... Sigh.
I would test this with Writer and some dumb (font rendering wise) client like tilix. If it works there the problem is the idiosyncrasies of that particular client.

A good way to check for cell size problems are Powerline glyphs E0B8 and E0BA:

[Finii]

Blue and pink for better visualization

I like that!

[luebking]

I mostly wanted to make sure that there're no regressions w/ other (popular) TEs (where afaict there are not)

I also was gonna say that xterm/st have the same problem, but actually they don't - the moment you configure their fonts using the pixelsize freetype syntax, they behave exactly like urxvt.
It's mostly about giving the dpi calculations free reign that the results become hard to control but usually "wrong".

---

Wrt alacritty, I could get better results when running "alacritty -v" and fiddling w/ the size variable until I had odd font and cell heights (which however doesn't seem to be always possible, at least not with single-digit precision)

[Finii]

Testing this now (playing around), with this output:

test.sh

#!/usr/bin/env bash

COL_A='\033[48;5;51m\033[38;5;200m'
COL_B='\033[48;5;200m\033[38;5;51m'

COL_A='\033[48;5;238m\033[38;5;253m'
COL_B='\033[48;5;253m\033[38;5;238m'

printf "\
${COL_A}                                                         \n\
Under \ue0b2${COL_B} lap ${COL_A}\ue0b0 and \ue0b6${COL_B} top ${COL_A}\ue0b4 mop\n\
${COL_A}Over \ue0b2${COL_B} lap ${COL_A}\ue0b0 and \ue0b6${COL_B} top ${COL_A}\ue0b4 mop trop lop klop\n\
                         \n"

which looks like this

with this settings (for the top image, afterwards is greyscale and none)

And the font is Delugia v2111.01.2, sorry ;-)
Terminal tilix.

---

Now taking the colors from this

• Thin vertical blue line on my prompt #156

The vertical centering of the glyph is actually an antialiasing problem, only.

Hmm, that is not the case for me 🤔
here see the output for antialiasing = LCD and varying hinting:

antialiasing LCD, hinting none

antialiasing LCD, hinting slight

antialiasing LCD, hinting full

Hinting moves (especially) the horizontal 'borders' of letters to pixel borders, to make them more sharp.
Obviously it moves the border of the powerline glyph down instead of up to be exactly on a pixel border (in my example).
If it moves up or down depends on font size and so on. Sometimes it is the lower edge that is moved.

Anyhow, I do not see the vertical antialiasing line; I know tilix is much less picky more forgiving than these super-terminal-emulators that do the font rendering on their own 🙄 , but I know I can see the line on my other machine with the same setup, investigating.

---

AHHH, I know why I prefer Delugia over Caskaydia Cove :-D
That already has the vertical line fixed since ancient times

• Adapt to new Cascadia release scheme adam7/delugia-code#34

tbc

[Finii]

This is Caskaydia Cove Nerd Font Mono v2.1.0 in tilix, no hinting, RGB antialiasing

This is Caskaydia Cove Nerd Font Mono v3.1.1 in tilix, no hinting, RGB antialiasing

This is Caskaydia Cove Nerd Font Mono v3.2.0RC in tilix, no hinting, RGB antialiasing

This looks clean. I always imagine faint lines, but that seems an optical illusion, even more magnification (click to enlarge)

I believe this PR successfully does what it sets out to do.

[Finii]

@allcontributors please add @luebking for bug

[allcontributors]

@Finii

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

[Finii]

@allcontributors please add @luebking for bug and review

[allcontributors]

@Finii

I've updated the pull request to add @luebking! 🎉

[Finii]

Thanks for all the input! I am very grateful for this / the discussions! 💚

[luebking]

Many thanks for fixing this, wrt.

The vertical centering of the glyph is actually an antialiasing problem, only.

I meant to say that the visual perception of the shift or indention is caused by the antialiasing effect, ie. it's not really that the glyph is misplaced but the illusion is caused by the uneven density applied by the antialiasing.
But as mentioned before, that's entirely not related to this change and strongly related to rasterizer and font settings and only became more apparent once the subpixel line was gone.

tilix is btw. just a wrapper around VTE3, so all terminal emulators wrapping that should get the same behavior, see eg. https://archlinux.org/packages/extra/x86_64/vte3/