Comment # 19 on bug 1110412 from Gerry Makaro

(In reply to Petr Gajdos from comment #16)
> (In reply to Yunhe Guo from comment #10)
> > https://gitlab.freedesktop.org/fontconfig/fontconfig/blob/master/conf.d/60-
> > latin.conf#L26
> > 
> > I deleted this line manually and everything works well. It seems fontconfig
> > will first look at latin fonts, and then look for emoji if nothing provide
> > the font. But if some latin fonts have provided it, then it use the latin
> > font to render the emoji.
> 
> We do not ship this, we ship ours:
> /etc/fonts/conf.d/60-family-prefer.conf ->
> /usr/share/fonts-config/conf.avail/60-family-prefer.conf
> 
> It contains some state preference list, yes, because we need to ship one. It
> boiled down along many years, but it is of course subject of change. Each
> such change needs to be very carefully thought trough, though. But actually
> I started to write yast-fonts to stop these discussions [By the way: we
> could consider add 'smiley' section along sans/serif/sans-serif, Gerry, what
> do you think?].
> 
> Unfortunately we cannot add emoji fonts too high here. If they would not
> contain another symbols than emoji, it would be a logical solution. But that
> is unfortunately not true, these fonts overlap code points from 'regular'
> fonts. For showy example look here:
> https://fontinfo.opensuse.org/fonts/EmojiOneColorRegular.html
> and imagine a text that would not contain any smiley but would contain
> U+2049 in it.
> 
> I think applications has to support emoji that way that they ask for it (by
> library call equivalent to fc-match emoji) where they want to really render
> a smiley. Perhaps there is another solution I do not see, but anyway:
> 
> (In reply to Yunhe Guo from comment #14)
> > So I will report this bug to Qt and KDE. Let's see if they have some good
> > solutions.
> 
> that is only solution I can imagine for now (but as I already said, my font
> knowledge is gets dusty). Thanks for the analysis!

I concur with Marketa's evaluation of this, as well as what you have to say,
Petr.  This should be fixed upstream @ KDE, IMHO.