Incorrect vue icon

[epszaw]

🎯 Subject of the issue

Incorrect vue icon rendering. Other icons work fine.

🔧 Your Setup

• Pragmata Pro Mono Liga Nerd Font.ttf, JetBrains Mono Nerd Font.ttf
• kitty, gnome
• Ubuntu 20.04

★ Optional

[epszaw]

@ryanoasis, any info here?

[corporal9736]

I meet the same problem here, the vue icon just cannot show properly. Are there any solutions?

[ryanoasis]

do other glyphs show up for you? If so you may have an older Nerd Font. Try from the latest release.

Can you try this from your terminal and provide a screenshot: echo -e "\ufd42".

[USLTD]

Hello @ryanoasis,
I also have this issue. Should I continue in this thread or create new?

Just in case here is information about font and terminal:

Terminal: Termux v0.118.0 (F-Droid version) with Termux:Styling v0.29 (also from F-Droid). Both are at LATEST STABLE versions at the time of writing.

Font: Fira Code Regular Nerd Font Complete.ttf. Latest file at the time of writing in repository, meaning commit df6d602 (https://github.com/ryanoasis/nerd-fonts/blob/df6d602440f06695d3db372b45465632de264cc2/patched-fonts/FiraCode/Regular/complete/Fira%20Code%20Regular%20Nerd%20Font%20Complete.ttf)

Here is how it should look:

And how it looks:

[Finii]

The font you linked to (great!) does have the glyph:

and at least with tilix it does show up:

Maybe it is a terminal problem. Or a font problem, because the terminal does believe the meta information embedded into the font:

See, VUE is FD42 which is in Arab Presentation Forms A, which the font claims to not include (not highlighted). Which is a lie but most terminals just do not care.
Can you see any other of the glyphs in Form A? What about Form B (i.e. FEFF which should be displayed as blank)?

[Finii]

Hmm, original reporter's terminals (kitty and gnome-terminal) seem to find the glyph, as does

$ fc-list ':charset=fd42'
/home/fini/.local/share/fonts/Fira Code Regular Nerd Font Complete Mono.ttf: FiraCode Nerd Font Mono:style=Regular

[USLTD]

This is how it looks when checking with font viewer (UnicodePad). Marked place is where glyph is supposed to be

[USLTD]

What's more strange is that when viewing specific glyph (not previewing it on list but holding on it) it shows it correctly

[USLTD]

I tried to copy-pasting it:

But it shows same invalid glyph (question mark in diamond or whatever it is) as shown on terminal

[USLTD]

FEFF is blank in both viewer and terminal

[USLTD]

Also off topic question but ...

The font you linked to (great!) does have the glyph:

What do you mean by to (great!) ?

[Finii]

The font you linked to (great!) does have the glyph:

What do you mean by to (great!) ?

That I appreciate people that link to concrete stuff where I can check and not just let me poke around with 100 possible other versions of fonts with the same name :-) Read it as 'Great report, thank you!'

[USLTD]

Also I am curious about one thing — why do patched fonts overlap with for example arabic glyps? There are tons of free space in Private Area and if I am not wrong there is also second Private Area

[Finii]

why do patched fonts overlap with for example arabic glyps?

😭

Yes, that was a mistake long long ago, that is very hard to fix (because people rely on that codepoints now).
Compare #716 (Remap Glyphs) and a lot of Issues 😒

[Finii]

Regarding this screenshot

Interesting that the first 7 missing glyphs are one-slashed-out, while the following are crossed-out.
The first 7 should be filled, while the others are indeed empty.
Maybe the glyphs could not be rendered for some reason? I had that with other glyphs too, where they show up correct in one renderer but not in another.

Hmm, but the glyph looks trivial:

Can the terminal show that HDMI plug FD3F thing?

Edit: Add 'missing'

[USLTD]

Let's see...

Edit: Yep.

[Finii]

I tried on my phone

• downloaded same file you linked to above
• show in font viewer
• Because my keyboard does not allow to enter codepoints, send X ctrl + shift + U F D 4 2 enter X via signal desktop to phone
• Copy and paste text from signal to font viewer
• (Ok, that is not the font installed, so probably rendered by font viewer)

[Finii]

Hmm,

Termux doesn't implement own font renderer, it uses an instance of android.graphics.Paint with typeface being set.

termux/termux-styling#105 (comment)

Strange. I checked the font in the repo, and it contains the FD42 thing.

[Finii]

Well, installed this termux-style thing, and it is the same for all fonts (that I tried): FD3F is visible, FD42 is unknown:

[Finii]

All those glyphs, FD40 and upward, they are originally only ligatures. FD3F and below are normal glyphs.
Not that the ligatures table is filled, but the codepoints are intended to be for ligatures.
Maybe the font renderer thinks it smarter then the font data.

[Finii]

@lamartire Tried a lot with kitty and I can not reproduce the problem.

See details here: kovidgoyal/kitty#5156

Maybe you can do/show us a fc-list ':charset=fd42' and/or start kitty like this:
kitty --debug-font-fallback

[USLTD]

... and/or start kitty like this:
kitty --debug-font-fallback

I don't use kitty or GUI in general (except Termux).

Maybe you can do/show us a fc-list ':charset=fd42' ...

Here is output of fc-list ':charset=fd42':

❯ fc-list ':charset=fd42'
/data/data/com.termux/files/usr/share/fonts/TTF/IosevkaTermNerdFontComplete-Regular.ttf: Iosevka Term,Iosevka Nerd Font:style=Regular
/data/data/com.termux/files/usr/share/fonts/TTF/FiraCodeNerdFontComplete-Regular.ttf: FiraCode Nerd Font Mono:style=Regular

[Finii]

I don't use kitty or GUI in general (except Termux).

Yes. The question was for @lamartire who uses kitty (original Issue author).

[willchao612]

All those glyphs, FD40 and upward, they are originally only ligatures. FD3F and below are normal glyphs. Not that the ligatures table is filled, but the codepoints are intended to be for ligatures. Maybe the font renderer thinks it smarter then the font data.

Same here. Also using kitty. Is there any possible workaround already?

[Finii]

Also using kitty. Is there any possible workaround already?

Hmm, for me it works with kitty:

(Bottom windows shows shift-ctrl-f2 settings)

[willchao612]

Weird. The glyph can show correctly when searched with ctrl + shift + u in kitty, but not with echo -e "\ufd42".

[Finii]

My echo is the zsh builtin...

[willchao612]

I am using zsh too. The problem is that fd40 and upwards cannot show correctly with echo, but with kitty's own unicode searcher it is fine.

[Finii]

What system are you using? shift-ctrl-u is the normal linux keyboard thing and has nothing to do with the shell or terminal, in my case. And as you can see, the echo works on my system.

I have kitty 0.21.2 created by Kovid Goyal

$ kitty --debug-font-fallback
[227 14:59:56.397158] Preloaded font faces:
[227 14:59:56.397197] normal face: /home/fini/.local/share/fonts/JetBrains Mono Regular Nerd Font Complete Mono.ttf:0
[227 14:59:56.397213] bold face: /home/fini/.local/share/fonts/JetBrains Mono Regular Nerd Font Complete Mono.ttf:0
[227 14:59:56.397227] italic face: /home/fini/.local/share/fonts/JetBrains Mono Regular Nerd Font Complete Mono.ttf:0
[227 14:59:56.397242] bi face: /home/fini/.local/share/fonts/JetBrains Mono Regular Nerd Font Complete Mono.ttf:0

Check this output while/after running echo in the started kitty.

Hmm, kitty --debug-config seems to be not there anymore?

Here it did work... #268 (comment)

Edit: Add link to old kitty issue

[willchao612]

Thanks for your response. Ubuntu 20.04 is what I am using. Here is the output of kitty --debug-font-fallback.

[227 22:06:31.694397] Preloaded font faces:
[227 22:06:31.694436] normal face: /usr/local/share/fonts/OperatorMono-Medium.otf:0
[227 22:06:31.694451] bold face: /usr/local/share/fonts/OperatorMono-Bold.otf:0
[227 22:06:31.694463] italic face: /usr/local/share/fonts/OperatorMono-MediumItalic.otf:0
[227 22:06:31.694481] bi face: /usr/local/share/fonts/OperatorMono-BoldItalic.otf:0
U+279c bold Face(family=DejaVu Sans Mono, style=Bold, ps_name=DejaVuSansMono-Bold, path=/usr/share/fonts/truetype/dejavu/DejaVuSansMono-Bold.ttf, index=0, is_scalable=True, has_color=False, ascender=1901, descender=-483, height=2384, underline_position=-175, underline_thickness=90, strikethrough_position=530, strikethrough_thickness=102) (new face)

I have kitty 0.25.2 created by Kovid Goyal.

[Finii]

OperatorMono ... is that self patched? Does not look like a NerdFont. Does not have the ugly font-patcher file names.

What does fc-cache -f && fc-list ':charset=fd42' show?
What is the contents of your kitty config?

[willchao612]

What does fc-cache -f && fc-list ':charset=fd42' show?

Operator Mono not in the list. Here is the font's repo. Maybe it is not patched with the glyph? But other glyphs like filetype icons can show correctly.

What is the contents of your kitty config?

include gruvbox_material_dark_hard.conf

font_family Operator Mono Medium
bold_font Operator Mono Bold
italic_font Operator Mono Medium Italic
bold_italic_font Operator Mono Bold Italic
font_size 22

disable_ligatures never
cursor_blink_interval 0
enable_audio_bell no
shell_integration no-cursor
copy_on_select no

Edit: I have just patched the font and it appears in the output of fc-cache -f && fc-list ':charset=fd42', but the problem still exists.

[willchao612]

@Finii I have mislocated the problem. All glyphs can show properly in kitty, but those above fd42 fail once I am under tmux.

[willchao612]

@Finii Is this a tmux issue or font issue? Cuz it doesn't seem to work with other patched fonts either...

[Finii]

For me, it works in tmux

even on kitty & tmux

Maybe you should raise a new Issue, as it seems distinct from the TO's.
Please add how your system exactly is set up, download links to the font you have installed etc

[willchao612]

Please add how your system exactly is set up, download links to the font you have installed etc

Thanks for your patience. Here's my setup:

• Ubuntu 20.04
• Kitty
• Tmux
• Font

[Finii]

This must be some local setting, maybe fontconfig. Works on all scenarios I checked.

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