Odd gap between glyphs and text

[mhartington]

Not sure what happened, but since updating my fonts to include the new icons, I'm getting some weird spacing between the powerline glyphs and regular text.

Using other fonts that have powerline support do not have this issue.

[ryanoasis]

I've been away but I will look into this. I think one thing that needs to happen is to detect if the powerline characters are present in the font being patched and to not add (override) the already existing powerline glyphs.

per: #28 (comment)

[sethamclean]

I have the same issue using the pre-patched source code pro fonts

[kiranps]

@mhartington i think you are using tmux separator as | change it to "" blank

[dritter]

@kiranps I don't think so. I have the same issue without using tmux..

[sethamclean]

I have the same problem with "Sauce Code Powerline Plus Nerd File Types Mono Plus Font Awesome Plus Octicons Plus Pomicons.otf". My terminal is urxvt and I am seeing the gap in VIM with lightline.

[mudox]

I can reproduce the gap by increasing the horizontal character spacing in iTerm2, maybe it's a editor/terminal font rendering issue.

[dritter]

@mudox I left the character spacing untouched. And like @sethamclean I have it with "Sauce Code"-Font only. So this is definitely a font issue.

[sethamclean]

@mudox reducing the font spacing can remove the gap but the arrows are vertically too small as well. This results in a "road cone" like shape.

[mhartington]

Yeah, using source code pro or hack, which has powerline support already, there isn't an issue.
So this is an issue where the glyphs that get patched are off by a pixel or two.

[ryanoasis]

I am working on not overwriting powerline glyphs if they are already present in the font to be patched.

I thought this actually may have been fixed for recently patched Sauce Code but ryanoasis/vim-devicons#126 seems to suggest otherwise. I have not tested yet.

[mhartington]

Looking good! Happy to be closing this.

[voiprodrigo]

I have this problem, commented in #26

[ryanoasis]

@voiprodrigo thanks

[astrolemonade]

2019, the issue is still present

[ryanoasis]

@cata0309 Could you attach a screenshot and give some more details (os, terminal, font and font size)?

I know it seems frustrating that this seemingly small issue may not be solved 100% for all scenarios but this is actually difficult to look perfect for all terms and fonts at all sizes. It seemed like this was solved and furthermore it made sense to spend time on the lower hanging fruit. Thanks

[astrolemonade]

I am using Solus Linux Fortitude
Terminal: Gnome-terminal, tilda, tilix
font: Furacode NF Regular size 12
Name a terminal that shows the fonts right, I will install right away.

[spinnau]

@cata0309 I also see this effect in GNOME-Terminal 3.32.2 running on GNOME desktop. Testing different nerd fonts (DejaVu Sans Mono Regular, Fura Code Regular, Meslo LG L Regular, Sauce Code Pro) and font sizes from 9 to 14 doesn't solve the problem.

After testing some hinting and anti-aliasing settings in GNOME Tweak Tool I have found that the gaps disappear by changing the anti-aliasing from Subpixel to Grayscale.

With Subpixel anti-aliasing:

With Standard (grayscale) anti-aliasing:

GNOME Tweak Tool settings:

[astrolemonade]

Thank you, I will try that out ? What are you using ? Powerline 10k ? mar., 2 iul. 2019, 22:55 spinnau <notifications@github.com> a scris:

…

@cata0309 <https://github.com/cata0309> I also see this effect in GNOME-Terminal 3.32.2 running on GNOME desktop. Testing different fonts (DejaVu Sans Mono Regular, Fura Code Regular, Meslo LG L Regular, Sauce Code Pro) and font sizes from 9 to 14 doesn't solve the problem. After testing some hinting and anti-aliasing settings in GNOME Tweak Tool I have found that the gaps disappear by changing the anti-aliasing from Subpixel to Grayscale. With Subpixel anti-aliasing: [image: subpixel_antialiasing] <https://user-images.githubusercontent.com/2995937/60541930-e6e12e00-9d12-11e9-8597-f891f5bb85e6.png> With Standard (grayscale) anti-aliasing: [image: grayscale_antialiasing] <https://user-images.githubusercontent.com/2995937/60541975-09734700-9d13-11e9-8008-ad82c714bcf8.png> GNOME Tweak Tool settings: [image: Gnome_antialiasing_settings] <https://user-images.githubusercontent.com/2995937/60541999-1a23bd00-9d13-11e9-9e31-d265bf97c5f9.png> — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#29?email_source=notifications&email_token=AIPZH4JUEYPSWQFE47HLFK3P5OXCJA5CNFSM4BPB6QA2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZCL5XI#issuecomment-507821789>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AIPZH4IUW4JW5XRVEKNDINDP5OXCJANCNFSM4BPB6QAQ> .

[spinnau]

The theme used in the screenshots is powerlevel9k.

I have tried this on another computer, also with GNOME-Terminal 3.32.2 on GNOME desktop. The effect can be reproduced. With subpixel anti-aliasing the small gaps can be seen, but they are gone if the anti-aliasing is switched to grayscale. @ryanoasis so maybe this is just a rendering problem?

Both computers are running on arch linux with the same GNOME desktop version but with different graphics hardware and drivers. One computer uses nvidia drivers on X11 and a monitor with 110 ppi. The other computer runs intel graphics with modesetting driver on wayland and a monitor with 92 ppi.

[MIvanchev]

I have just hit this issue in 2021 (on Ubuntu MATE):

[Finii]

@MIvanchev do you mean the faint line, circled yellow?

We would need exact font name (and if you self patched or where you did download it, to examine the exact same file), terminal used, terminal font settings,
Maybe you can try if turning antialiasing to 'greyscale' fixes it? (See Tweak tool some comments furter up.)

Edit: Note: Gnome Tweak tool updates the setting only after you close the tool!

[MIvanchev]

Hey @Finii, this line is exactly what I mean yes. This is Literation Mono size 12 downloaded directly from https://www.nerdfonts.com/. I use neovim-qt, default Gnome settings but changing them has no effect. Grayscale has no effect. The only thing that fixes this is disabling anti-aliasing completely.

[Finii]

I see it in Tilix:

But it is gone when greyscale.

• Need to change to greyscale and close tweaks
• Need to focus on tilix (which obviously only redraws if active)

Anyhow, that is just kind of hotfix for you, possibly.

Just found out #779 (comment)
Let's see (ponder) what we can do in that manner.

[MIvanchev]

@Finii Could you try the triangle characters back to back? Just tried again, grayscale has absolutely no effect.

[Finii]

Can you copy and paste the chars, then I do not need to find out which comes first in your setup? The whole line if possible, as text.

[Finii]

Cascadia Code again with extra neg. bearing on problematic (right in this case) side.

[Finii]

I use ordinary neovim running in tilix. Installed this Qt thing... where do I change the font 😬

If it does not work for you I bet it is some Qt font rendering blah... 🙄

[MIvanchev]

You change the font using :GuiFont in the ginit.vim file or in the editor itself. Try this text: 

[Finii]

Hmm, in tilix (running neovim) the glyphs are too wide (as one also would have anticipated by the fontforge outline windows above (unchanged 2446 width 😒 )

Anyhow:

Do you use Literation Mono NF Mono instead?

[MIvanchev]

I think this error exists on any nerd font, just do :GuiFont! LiterationMono Nerd Font Mono:h12

[Finii]

Hmm, I see it with LCD antialias:

but not with greyscale:

• Change to greyscale
• Close tweaks
• restart neovim qt
• reload text file
• set GuiFont

Scaled up 400%:

(LCD antialias has these colored edges color fringes, i.e. left)

It's still there but very faint, can not see it without magnification.

[Finii]

Oh, and I'm on X11 not Wayland, if that is a difference 🤔

[Finii]

Hmm, our overlap code seems to be broken?

No negative bearing on left, but negative bearing on right.
Should be some overlap over the 'box' on both sides.

\me starts up editor

           if overlap != 0:
                overlap_width = self.font_dim['width'] * overlap
                if sym_attr['align'] == 'l':
                    x_align_distance -= overlap_width
                if sym_attr['align'] == 'r':
                    x_align_distance += overlap_width

            align_matrix = psMat.translate(x_align_distance, y_align_distance)
            self.sourceFont[currentSourceFontGlyph].transform(align_matrix)

            # Needed for setting 'advance width' on each glyph so they do not overlap,
            # also ensures the font is considered monospaced on Windows by setting the
            # same width for all character glyphs. This needs to be done for all glyphs,
            # even the ones that are empty and didn't go through the scaling operations.
            self.set_glyph_width_mono(self.sourceFont[currentSourceFontGlyph])

            # Ensure after horizontal adjustments and centering that the glyph
            # does not overlap the bearings (edges)
            self.remove_glyph_neg_bearings(self.sourceFont[currentSourceFontGlyph])

😭 First we methodically overlap and then we remove the negative bearings...

[MIvanchev]

Hey, thanks for the extensive testing. Unfortunately I do still have it with. Even forcing grayscale with in fonts.conf doesn't change it. The shading along the edge is different but still extremely noticeable.

<?xml version="1.0"?>
<!DOCTYPE fontconfig SYSTEM "urn:fontconfig:fonts.dtd">
<fontconfig>
  <match target="pattern">
    <test name="family" compare="eq">
      <string>LiterationMono Nerd Font Mono</string>
    </test>
    <edit name="rgba" mode="assign"><const>none</const></edit>
  </match>
</fontconfig>

I think I'm going to generate a bitmap grayscale font and work with that.

[Finii]

Some years back we added the 'overlap' to avoid the color lines, the overlap being much smaller than Cascadia Code's.
But now it seems the overlap is broken. I will try this out and possible come up with a PR; will inform you.

It still might be a problem with Qt's font rendering (I do not trust anything Qt 😬) or how neovim-Qt does it. All the different terminal emulators have all their own opinions how to render fonts, now yet another idea ;)

I think monochrome antialias is not a solution anyhow, there is a reason we have LCD specific antialias ;)

[MIvanchev]

Thanks, I'm really grateful for your insights!!! Btw this is not only in Qt, every tool on the system has it. It's some GNOME / FreeType weirdness. I was quick to blame Qt as well.

[Finii]

I guess this is solved now. Maybe you can check the font on your setup.
Can you self-patch from the PR or shall I put the font file somewhere to download?

[MIvanchev]

I can self-patch, will retest asap. Thank you so much btw!

[Finii]

Homeoffice sei dank ;-)

[MIvanchev]

Allerdings :)) Das ist echt großartig.

[MIvanchev]

Current result with --complete:

[Finii]

This looks like LiterationMono Nerd Font (non-Mono). The triangular things have double-width there.
*duh* it's written in your vim ini :-D

I did not check the overlap for the non-mono version 😬

Is it an improvement? I see faint lines. Do they bother? Maybe patch with 4% overlap 🙄

[MIvanchev]

Wait, what, it says mono in the name, I'm CONFUSED :D

[Finii]

Literartion Mono Nerd Font (not mono)
Literartion Mono Nerd Font Mono (real mono)

naming is hard...

[MIvanchev]

--mono plus 4% overlap worked :)

[github-actions]

This issue has been automatically locked since there has not been any recent activity (i.e. last half year) after it was closed. It helps our maintainers focus on the active issues. If you have found a problem that seems similar, please open a new issue, complete the issue template with all the details necessary to reproduce, and mention this issue as reference.