Created attachment 110922 [details] No font at all in KeePass (Mono/GTK2 app) I run an up-to-date KDE neon user edition. After updating Neon a few of days ago, I noticed a couple of regressions: * Firefox menus and tab titles switched to some kind of very basic serif font * KeePass stopped displaying any text in its GUI (see attached screenshot), which prompted me to urgently investigate! After investigating, I came to find an incompatibility between a file very recently added to Neon (56-neon-noto.conf) and a file added by a PPA which provides color emoji support in Linux (56-twemoji-color.conf). A workaround is simple to remove the /etc/fonts/conf.d/56-neon-noto.conf symlink. I understand Neon cannot support and be compatible with every PPA out there, but I found that package is the top recommendation for adding proper color emojis to a Linux desktop, which are otherwise sorely missing. Affected packages and versions: * neon-settings 0.0+p16.04+git20180220.1452 * fonts-twemoji-svginot 1.3-1 from ppa:eosrei/fonts (Xenial packages of course)
Well, if jriddell took the time to package Noto Emoji, you wouldn't need subpar third party packages at all... If I were you'd I'd just drop https://github.com/googlei18n/noto-emoji/tree/master/fonts into your ~/.fonts and delete the twemoji PPA package. That PPA config is fairly daftly written and I would not recommend using it. The reason it breaks your keepass is that it prepends its emoji font to everything containing the noto emoji font (which is just about everything as we've set up complete noto coverage in the 56-neon rule which is lexographically run before the twemoji config), so basically keepass will try to render every single character as an emoji, then as bitstream vera and then as noto (as per our rules). Mind you, it's funny how the emoji config picks such a high order value. If you were to configure user side fonts that'd happen in 50-* IIRC, so if the user configures a font rule that includes any of the popular color emoji fonts that'd also break font rendering because of how the emoji rule is written. So, really, the 56-twemoji-color.conf should be 49-x-twemoji-color.conf so it loads before any user customization. Or Maybe, and this is a big maybe, 50-c-twemoji-color.conf so it customizes on top of any user customization (which would still leave the problem of it basically breaking any font list including the mainstream color emoji fonts). All that said. What happens if you rename /etc/fonts/conf.d/56-neon-noto.conf to 56-x-neon-noto.conf? The way I see it if the noto config loads after the tw config all should be good.
Thanks for your detailed answer. I did not know about Noto Emoji, it is interesting to know there is some choice in this area. However, looking at https://github.com/googlei18n/noto-emoji/issues/36 it appears you need very recent fontconfig and/or cairo to have it working out of the box. Indeed, I removed Twitter Color Emoji, restored the Neon fontconfig files, and put NotoColorEmoji.ttf in ~/.local/share/fonts as you suggested, and it was totally ignored by fontconfig. I also put NotoEmoji-Regular.ttf there, it was not ignored, but it only contains outdated black-and-white glyphs according to the noto-emoji README. The prepend hack may be ugly, but it also appears to be widely done by users in https://github.com/googlei18n/noto-emoji/issues/36 (at least until the very recent fontconfig version gets distributed more widely). Without it, I get glyphs from /usr/share/fonts/truetype/dejavu/DejaVuSans.ttf and they suffer from a huge style clash: some of the most basic emojis are ugly black-and-white glyphs, while the rest has nice coloring. The emoji coverage is also very poor. Currently, it appears TwitterColorEmoji-SVGinOT.ttf is the one providing a font with full support and consistent style that just works under the Xenial software stack. The prepend hack, while unsavory, seems necessary to make it work in all cases. (Or maybe getting rid of DevaVuSans is a solution...) I also tried renaming 56-neon-noto.conf to 56-x-neon-noto.conf and it solves my issue as you expected. Thanks! Should I close this issue, or would you prefer to keep it open to include a workaround in your package?
Coming back to this bug report two years later, I can confirm this has been fixed in KDE neon 18.04.