SUMMARY In Fedora 32, the Plasma Emoji Picker was showing lots of rectangles instead of emojis, then when I installed google-noto-emoji-color-fonts it showed an odd mix of black & white and color emojis. This is not ibus-ui-emojier-plasma's fault, however it could provide the Unicode code point of a glyph and the font from which the glyph comes to help the user figure out what's going on. STEPS TO REPRODUCE 1. Run ibus-ui-emojier-plasma in Fedora (see Redhat bugs 1820952 and 1855926 if it isn't working). 2. Note there are still black rectangles, and a mix of color and black & white glyphs. 3. Try to figure out what Unicode code point is missing for e.g. "smiling face with tear" 4. Try to figure out why some glyphs are color and some are black & white. OBSERVED RESULT Emoji Picker provides a tooltip that has the name of the character code, e.g. "smiling face with tear". But it doesn't reveal the code point (U+1F972 for "smiling face with tear") and it doesn't identify the font providing the glyph. EXPECTED RESULT Emoji Picker could display both pieces of information in a right-click context panel. For what it's worth, the Gnome Character Map "Gucharmap will display the origin font when you right-click on a glyph." Emoji Picker could also display the hex code in the missing glyph rectangle (I think this is called the "font fallback box glyph” or "tofu"), but that's hard to read and doesn't help for existing characters. SOFTWARE/OS VERSIONS Linux/KDE Plasma: KDE Plasma Version: 5.18.5 KDE Frameworks Version: 5.70.0 Qt Version: 5.14.2 using xcb ADDITIONAL INFORMATION The Font Viewer program kfontview has a useful popup when you choose a Unicode Block and then hover over a character: a bigger rendering of the glyph, its category, and its character number in various Unicode encodings. It's missing the Unicode character name and the font used . I would like these two utilities to have similar property pop-ups.
Feels like the real fix is in the Fedora packaging. I'm not sure how your proposal would help a person fix it, or indicate what the problem is. Can you clarify?
(In reply to Nate Graham from comment #1) > Feels like the real fix is in the Fedora packaging. Yes, I filed a bug in Redhat bugzilla for that, sorry for any confusion. Here I'm motivating my request for the Emoji Picker to display more info. This bug's priority should probably be enhancement or wishlist. > I'm not sure how your > proposal would help a person fix it, or indicate what the problem is. Can > you clarify? Demonstrably, the Emoji Picker can show missing glyphs and a mix of emoji styles; others have reported these problems (again yes, they are usually distro issues). If the Emoji Picker displayed the code point of missing glyphs then I would be able to check if the Unicode coverage of alternative emoji fonts includes the empty code points; if the Emoji Picker showed the font from which each rendered glyph came, I would understand why emoji styles don't match and have a guide as to how to adjust font config priorities to favor the emoji font I prefer. Generally, more info is A Good Thing, as kfontview and GuCharMap show.
Could we detect if there are missing symbols and show an inline message a la "Your font config is borked"?
>Could we detect if there are missing symbols and show an inline message a la "Your font config is borked"? Using our normal set of high level Qt API, no.
We have fixed the toufu/B&W emoji rendering issue https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/158 Please try Plasma 5.20 when it arrived in Fedora. You can run 'fc-match emoji' and the result should be: NotoColorEmoji.ttf: "Noto Color Emoji" "Regular" If not, you might installed some B/W emoji fonts, like "Noto Emoji" (it has been deprecated and should be removed from distros).
Yeah, this is a workaround for a bug. We should just fix the bug. :)