Bug 478549

Additional information:
fc-match --all monospace | nl | head
     1  Hack-Regular.ttf: "Hack" "Regular"
     2  SymbolsNerdFontMono-Regular.ttf: "Symbols Nerd Font Mono" "Regular"
     3  NotoColorEmoji.ttf: "Noto Color Emoji" "Regular"
     4  Hack-Bold.ttf: "Hack" "Bold"
     5  Hack-Italic.ttf: "Hack" "Italic"
     6  Hack-BoldItalic.ttf: "Hack" "Bold Italic"
     7  NotoSansCJK-Regular.ttc: "Noto Sans Mono CJK SC" "Regular"
     8  NotoSansCJK-Bold.ttc: "Noto Sans Mono CJK SC" "Bold"
     9  NotoSansCJK-Regular.ttc: "Noto Sans Mono CJK TC" "Regular"
    10  NotoSansCJK-Bold.ttc: "Noto Sans Mono CJK TC" "Bold"

Found this qt bug report https://bugreports.qt.io/browse/QTBUG-121816 reporter linked this other bug https://bugreports.qt.io/browse/QTBUG-110502 which was fixed by https://code.qt.io/cgit/qt/qtbase.git/commit/?id=a44b6950268214d802bc7ce7df09975261263e31 is that the reason this no longer works? It looks like it is to me

Any updates on this? I meet the same problem after upgrading to Plasma 6 with Konsole 24.02.0 this morning. All the nerd icon become tofu.

Here is the screenshot of the situation: https://sm.ms/image/yNxb94JcBEQfVk5

I am also encountering this after upgrading to 6.0.1 with Arch. For now, I changed the fixed width font in system settings to a nerd-font patched FiraCode, and that seems to work fine. I suspect that luisbocanegra found the cause, and it appears to be intended behavior.

Can we perhaps get a new setting to control this behavior, or choose a default fallback font? I'd prefer to not have to use patched fonts to get the nerd font symbols if there's a way to make that work without breaking the use case described in QTBUG-110502.

(In reply to wgalen from comment #4)
> I am also encountering this after upgrading to 6.0.1 with Arch. For now, I
> changed the fixed width font in system settings to a nerd-font patched
> FiraCode, and that seems to work fine. I suspect that luisbocanegra found
> the cause, and it appears to be intended behavior.
> 
> Can we perhaps get a new setting to control this behavior, or choose a
> default fallback font? I'd prefer to not have to use patched fonts to get
> the nerd font symbols if there's a way to make that work without breaking
> the use case described in QTBUG-110502.

Indeed, if I install `ttf-hack-nerd` and then set the "Fixed width" font in System Settings to "Hack Nerd Font 10pt" (the default is "Hack 10pt"), then Konsole shows the nerd font IF you DON'T set any specific font in the profile (it will take the default). The same holds for Kate: DON'T set any font, and it will take the default. As soon as you set a font, either you make sure you select a Nerd font, or it won't work (you experience this bug).

(In reply to wgalen from comment #4)
> I am also encountering this after upgrading to 6.0.1 with Arch. For now, I
> changed the fixed width font in system settings to a nerd-font patched
> FiraCode, and that seems to work fine. I suspect that luisbocanegra found
> the cause, and it appears to be intended behavior.
> 
> Can we perhaps get a new setting to control this behavior, or choose a
> default fallback font? I'd prefer to not have to use patched fonts to get
> the nerd font symbols if there's a way to make that work without breaking
> the use case described in QTBUG-110502.

I agree, especially because the nerds font project only covers some of them.

I like Red Hat Mono for example, and with Plasma 5 I could use that and have KDE apps fallback on the symbols-only package to render missing glyphs without doing any font patching.

The change introduced to fix QTBUG-110502 has been reverted: https://codereview.qt-project.org/c/qt/qtbase/+/548651

If that change is actually responsible for this bug, then this should be fixed in the next minor Qt release (I think).

*** Bug 485149 has been marked as a duplicate of this bug. ***

Adding myself to the list of people seeing this bug. Thanks to all for reporting and following up, seems like it may already be taken care of....

(In reply to pallaswept from comment #9)
> seems like it may already be taken care of....

Afraid not. I just looked into this and I got the update to qt 6.7 a few days ago, and I still have this bug.

*** Bug 481683 has been marked as a duplicate of this bug. ***

Created attachment 168549 [details]
screenshot-1

I thought I'd provide some additional info since I noticed some things lately.

First of all, I can't seem to be able to reproduce this in Konsole, or at least it's not as bad as it used to be right after updating to Plasma 6.

Now I'm using Konsole 24.02.1, KDE frameworks 6.0.0 and QT 6.7.0, and I can select Red Hat Mono as my fixed-width font, and Konsole will render my prompt penguin, home and green check icons just fine (although there is some weirdness still, refer to screenshot-1)

Now, "second of all":

some problems are clearly still visible throughout the whole Plasma UI when it comes to rendering emojis when the variable-width font selected does not contain those glyphs. So again it looks like some existing fallback mechanism has been removed since Plasma 6.

It's simple to reproduce, just choose a font that doesn't come with the "penguin" emoji, e.g. Inter Display, and you will see that it won't render in the toast notification that appears when you copy it from the Emoji Selector. A look at KCharSelect will confirm that this font doesn't have a glyph for the unicode. Refer to screenshot-2

Created attachment 168550 [details]
screenshot-2

And lastly, going back to monospaced fonts, no fallback is happening in the terminal panel of Dolphin.

I don't know if it's a hidden Konsole instance, or a different app/module, but for sure it behaves differently. A glyph that is resolved just fine via fallback in Konsole remains instead unrendered in Dolpin's Terminal panel. Refer to screenshot-3.

All this being considered, I think that this bug should not be filed against Konsole, but against a different, wider-scope project.

I dunno if this logic resides in Frameworks, if someone knowledgeable enough reads this, please set the correct value.

Thanks!

Created attachment 168551 [details]
screenshot-3

(In reply to Andrea Ippolito from comment #14)
> Now, "second of all":
> 
> some problems are clearly still visible throughout the whole Plasma UI when
> it comes to rendering emojis when the variable-width font selected does not
> contain those glyphs. So again it looks like some existing fallback
> mechanism has been removed since Plasma 6.
> 
> It's simple to reproduce, just choose a font that doesn't come with the
> "penguin" emoji, e.g. Inter Display, and you will see that it won't render
> in the toast notification that appears when you copy it from the Emoji
> Selector. A look at KCharSelect will confirm that this font doesn't have a
> glyph for the unicode. Refer to screenshot-2

The same is clearly visible when receiving a KDE Connect + Whatsapp notification for a message containing some fancy emoji.

The plasma notification will say something like "Dude wrote: <gibberish glyph>" instead of showing the actual emoji.

The Emoji Selector copy to clipboard feature is however a much easier way to reproduce.

Created attachment 168984 [details]
Penguin works for me

(In reply to Andrea Ippolito from comment #13)
> First of all, I can't seem to be able to reproduce this in Konsole

interesting, what you've described is basically the opposite of OP and I. We have failure in konsole (and all apps embedding it, such as dolphin) and not elsewhere... You have it elsewhere but not konsole.... So yours probably should be filed as a separate bug, and maybe refer to this one as being possibly related to it. Perhaps a bug title which encompasses the breadth of this issue might get seen to while this one seems to have fallen though the cracks. This issue title makes the bug seem as though it's limited to one app and one font, and it's not.

I agree with your general idea, there seems to be something broken, deeper than konsole. I've been seeing various reports of failing font fallback all over KDE, ever since plasma 6 dropped - always with "this worked in KDE 5". People always seem to just install a patched font and forget about it, so I guess that helps explain why this isn't getting the attention it otherwise might deserve.

(In reply to pallaswept from comment #19)
> Created attachment 168984 [details]
> Penguin works for me

What is your main font for the UI?

I was using Inter Display (og version, unpatched)

> It's simple to reproduce, just choose a font that doesn't come with the "penguin" emoji

Qt still has no real support for emojis, see here: https://wiki.archlinux.org/title/Fonts#Emoji_and_symbols

(In reply to Andrea Ippolito from comment #14)
> Now, "second of all":
> 
> some problems are clearly still visible throughout the whole Plasma UI when
> it comes to rendering emojis when the variable-width font selected does not
> contain those glyphs. So again it looks like some existing fallback
> mechanism has been removed since Plasma 6.
> 
> It's simple to reproduce, just choose a font that doesn't come with the
> "penguin" emoji, e.g. Inter Display, and you will see that it won't render
> in the toast notification that appears when you copy it from the Emoji
> Selector. A look at KCharSelect will confirm that this font doesn't have a
> glyph for the unicode. Refer to screenshot-2

Please disregard this message.
This turned out to be an issue caused by one of the fonts I had installed at user level, full story here:

https://forums.opensuse.org/t/missing-glyphs-problem-with-font-fallback/174633

So it has nothing to do with KDE

(In reply to Andrea Ippolito from comment #16)
> And lastly, going back to monospaced fonts, no fallback is happening in the
> terminal panel of Dolphin.
> 
> I don't know if it's a hidden Konsole instance, or a different app/module,
> but for sure it behaves differently. A glyph that is resolved just fine via
> fallback in Konsole remains instead unrendered in Dolpin's Terminal panel.
> Refer to screenshot-3.
> 
> All this being considered, I think that this bug should not be filed against
> Konsole, but against a different, wider-scope project.
> 
> I dunno if this logic resides in Frameworks, if someone knowledgeable enough
> reads this, please set the correct value.
> 
> Thanks!

Please disregard this message.
This turned out to be an issue caused by one of the fonts I had installed at user level, full story here:

https://forums.opensuse.org/t/missing-glyphs-problem-with-font-fallback/174633

So it has nothing to do with KDE

*** Bug 486553 has been marked as a duplicate of this bug. ***

*** Bug 483021 has been marked as a duplicate of this bug. ***

Hi, since the bug is apparently fixed in upstream, it should also be fixed in the coming KDE 6.1 release, right?

Qt is not a part of KDE release so not right

(In reply to regunakyle from comment #27)
> Hi, since the bug is apparently fixed in upstream (...)

Can you please share the link to the upstream fix?

(In reply to postix from comment #29)
> (In reply to regunakyle from comment #27)
> > Hi, since the bug is apparently fixed in upstream (...)
> 
> Can you please share the link to the upstream fix?

Here is the link: https://codereview.qt-project.org/c/qt/qtbase/+/548651

If someone could figure out which exact versions of Qt it landed in, that would be amazing. I don't know how to get that information myself.

(In reply to Nate Graham from comment #31)
> If someone could figure out which exact versions of Qt it landed in, that
> would be amazing. I don't know how to get that information myself.

I'm looking at the source for 6.7, and the above change is not in it. So, I guess it'll be in the next version.
Thanks for looking at this for us Nate!

(In reply to Nate Graham from comment #31)
> If someone could figure out which exact versions of Qt it landed in, that
> would be amazing. I don't know how to get that information myself.

The problem was introduced in commit fc33fea999365c36ed446eee0db0d59d94be306b, and is present in:
6.6.0 ~ 6.6.3; 6.7.0 ~ 6.7.1
And the commit that revert it is 4913511d3bf8ec7838f80fbfe92c0fe900b2f003, which at the moment is only present in dev branch.

P.S. you can quickly check this by `git branch --all --contains=fc33fea999365c36ed446eee0db0d59d94be306b`

Nate, it's in 6.7.1 (not in 6.7.0!) and it's easy to get that by copying the commit hash from gerrit and opening it on github (https://github.com/qt/qtbase/commit/<HASH>). It shows the branches and tags the commit is on but only tags (starting with v) are really relevant.