This is a problem with your fontconfig, which is shipped by the distro. In the emoji picker, we have a hack to force the emojis to display properly even if your fontconfig is messed up, but we can't do that for all apps. :) The reason why it works in Firefox is because they have a similar hack since they also don't want to have to deal with broken fontconfigs. However the ideal solution is for distros to stop shipping broken fontconfig files. So go complain to your distro about it! :)

(In reply to Nate Graham from comment #1)
> This is a problem with your fontconfig, which is shipped by the distro. In
> the emoji picker, we have a hack to force the emojis to display properly
> even if your fontconfig is messed up, but we can't do that for all apps. :)
> The reason why it works in Firefox is because they have a similar hack since
> they also don't want to have to deal with broken fontconfigs. However the
> ideal solution is for distros to stop shipping broken fontconfig files. So
> go complain to your distro about it! :)

The fontconfig is in order (it points to the correct spot, where the requisite font files are.) Again, this is the only emoji that doesn't work. Every other one I can think to try works fine.

Oh, just that one Emoji? That's odd.

(In reply to Nate Graham from comment #3)
> Oh, just that one Emoji? That's odd.

Yep, just the one. I thought it was just the new Unicode 13 ones too, but the rest of them work fine. It's not an issue with color emoji either, or ones that are actually multiple characters combined, and I can't think of anything else that makes this one odd, so I really don't know what it is.

Qt probably is based on an older Unicode version than Plasma's Emoji selector.

(In reply to Christoph Feck from comment #5)
> Qt probably is based on an older Unicode version than Plasma's Emoji
> selector.

Nope, all other emoji added in the same version of Unicode work fine, so I know it's up to date.

I've written and deleted several long comments now because I keep discovering new facets of this problem. Suffice it to say:

1. I see this issue on an updated Arch Linux system.

2. One variant of the trans flag emoji works, and one doesn't. If I copy the trans flag emoji used on this page from my browser, I get the codepoints 1F3F3 FE0F 200D 26A7 FE0F. This does not work in QT / KDE applications. However, if you can manage to find a 1F3F3 200D 26A7 somewhere[1], it will work. Another example: the fully-qualified rainbow flag 🏳️‍🌈 doesn't work, the unqualified rainbow flag 🏳‍🌈 does. (It's possible the KDE bug server or my browser may have changed the representation of these characters, breaking the example.)

3. The difference between broken and working emoji is that the broken emoji all contain an *emoji presentation selector* [2] in the *middle* of a emoji character (usually right before a 200D zero width join).

4. This seems likely to be a bug with the QT text rendering engine.[3] It's not really surprising that not many people have noticed it. A search says that there are only around 250 qualified / unqualified pairs in Unicode 13.1, and nearly all of these are things like the reminder ribbon 🎗 which will display just fine because the presentation selector comes at the end of the character *AND* because most fonts don't have a "text" representation of this emoji - so it falls back to the emoji font correctly. It's made doubly complicated by the fact that if you happen to copy an unqualified emoji it will (probably) work just fine. A rare exception: "smiling face" ☺️ doesn't work for me in KDE apps. That's because ignoring the trailing presentation selector results in my base font rendering the text version of the glyph. (If you have a default font set that is explicitly designed to fall back to your emoji font, it's likely that it will not have many of these characters and so you'll see even *fewer* issues.)

5. This is closely related to another bug I discovered: QT applications will display a broken emoji if it contains a character used in your base font. For example, "man kneeling" 🧎‍♂️ displays as 🧎+ ♂ in KWrite because my selected font (Source Code Pro) contains the ♂ symbol. This might be the result of an incorrect fontconfig, but I don't believe that's likely for the reasons given in 6. If anyone can help me further drill down on the cause (even if that means filing another bug) I'd be appreciative.

6. With my current configuration, I see no issue in Firefox, gedit, or pango-view (a simple application that tests pango/cairo directly). For example, `pango-view -t "🏳️‍⚧️"` displays the transgender flag emoji in a window as expected. This further solidifies my view that the QT rendering engine has one or more bugs. I'm not fully certain whether the problem I describe in 5 is the same issue as what's reported here or not.


Let me know if there's anything I can do to help get this fixed.


[1] https://www.unicode.org/Public/emoji/14.0/emoji-test.txt

[2] https://unicode.org/reports/tr51/#def_emoji_presentation_selector

[3] I noticed that there's special handling for a ZWJ coming after a glyph handled by a fallback font, but no such handling for an emoji presentation selector. Could that be the source of the problem? https://codereview.qt-project.org/gitweb?p=qt/qtbase.git;a=blob;f=src/gui/text/qfontengine.cpp#l1844

Great investigation, Adam. I think you're right that these are Qt issues. Can you please file a bug report upstream for the Qt people at bugreports.qt.io that summarizes your findings? Bonus points for including those examples too. Once you've filed the bug report, can you add it to the URL field of this one? Thanks!

I've filed a bug with QT that covers the issues described in points 2-4 and linked it here. I ended up filing a separate report for the issue I described in point 5, as it has a rather different cause than the others: https://bugreports.qt.io/browse/QTBUG-97400

I'm reopening this in the hope of further discussion.

I filed the upstream bugs over a year ago now:
 * https://bugreports.qt.io/browse/QTBUG-97401
 * https://bugreports.qt.io/browse/QTBUG-97400

I think they were extremely clear about what the problem was on a technical level, and if I'm not wrong, they're probably not that hard to fix in QT. Unfortunately, neither bug has received a single comment from a QT developer or even marked confirmed. Because the reported issue also affects QT 6, I can only assume this problem is not going away for us in the near future.

I think we have to have some sort of plan here. KDE is a desktop environment! Having broken emojis should be considered unacceptable. My understanding is that we patch QT on many of the platforms QT ships on. (My operating system, Arch Linux, packages QT with patches by KDE.) Is this something we can fix on our end and move on? Are there other possible workarounds?

To quickly summarize the issues for anyone new to this bug report,
 * QT ignores the emoji presentation selector (QTBUG-85744) and in fact emoji representation breaks if an emoji contains a presentation selector in the middle of the emoji (QTBUG-97401). Presentation selectors are used in the normal (or "fully qualified") form of many emojis.
 * When an emoji combines two other code points with a zero-width join (like "man kneeling" = "person kneeling" + "male sign"), the resulting emoji will not be displayed correctly if one of those two symbols exists in the user's primary font. (QTBUG-97400)

I have a more detailed discussion in the thread above.

We cannot patch our Qt to fix this because nobody has written such a patch. If they did, they would submit it to Qt, and once it was merged there, we would backport it to out Qt 5 patch collection.

See https://community.kde.org/Get_Involved/Issue_Reporting#Understand_what_the_resolution_statuses_mean

Update: after four years, there's finally some movement on this. Qt now depends on the emoji-segmenter [1] library, and patches for Qt6 to use this library to layout text using correct segmentation have now been merged to their dev branch. I believe this may land in Qt 6.9 and fix the two issues I discovered along with several others. I'll update this issue as soon as I'm able to test the changes.

See https://bugreports.qt.io/browse/QTBUG-111801 for more. 

[1] https://github.com/google/emoji-segmenter