search

ryanoasis / nerd-fonts

Iconic font aggregator, collection, & patcher. 3,600+ icons, 50+ patched fonts: Hack, Source Code Pro, more. Glyph collections: Font Awesome, Material Design Icons, Octicons, & more
https://NerdFonts.com
Other
52.69k stars 3.59k forks source link

Increase Powerline rounded overlap #1551

Closed Finii closed 3 months ago

Finii commented 3 months ago

Description

Similar to

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

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

Fixes: #1547

Requirements / Checklist

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 commented 3 months ago

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

luebking commented 3 months ago

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 commented 3 months ago

Running, will upload the result here.

image

Finii commented 3 months ago

image

Some subset?

luebking commented 3 months ago

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

Finii commented 3 months ago

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

luebking commented 3 months ago

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 commented 3 months ago

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 commented 3 months ago

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

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 scrot_1710962226

=> 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 commented 3 months ago

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

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): scrot_1711010521

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

luebking commented 3 months ago

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 scrot_1711043465 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): scrot_1711044081

Finii commented 3 months ago

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

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:

image

Finii commented 3 months ago

Blue and pink for better visualization

I like that!

luebking commented 3 months ago

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 commented 3 months ago

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

test.sh

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

image

image

image

image

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

image

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

Now taking the colors from this

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

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

image

antialiasing LCD, hinting none

image

antialiasing LCD, hinting slight

image

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.

Kooha-2024-03-29-08-37-23

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 :roll_eyes: , 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

image

tbc

Finii commented 3 months ago

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

image

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

image

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

image

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

image

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

Finii commented 3 months ago

@allcontributors please add @luebking for bug

allcontributors[bot] commented 3 months ago

@Finii

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

Finii commented 3 months ago

@allcontributors please add @luebking for bug and review

allcontributors[bot] commented 3 months ago

@Finii

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

Finii commented 3 months ago

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

luebking commented 3 months ago

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/