bug#39799: 28.0.50; Most emoji sequences don’t render correctly

[Robert Pluim]

>>>>> On Fri, 28 Feb 2020 16:32:39 +0100, Mike FABIAN <mfabian@redhat.com> said:

    Mike> Eli Zaretskii <eliz@gnu.org> さんはかきました:
    >>> From: Robert Pluim <rpluim@gmail.com>
    >>> Cc: Glenn Morris <rgm@gnu.org>,  mfabian@redhat.com,  
39799@debbugs.gnu.org
    >>> Date: Fri, 28 Feb 2020 15:14:01 +0100
    >>> 
    >>> >> It DTRT for me under Cairo if I change my fontset settings to use
    >>> >> 'Noto Color Emoji' instead of Symbola for:
    >>> 
    Eli> Is that a free font (it's from Google, AFAIK, so it might not be)?  If
    Eli> it is free, we could modify fontset.el to use this font if available.
    Eli> (Or maybe there are better free Emoji fonts out there?)
    >>> 
    >>> Its license is Apache 2.0. It seems fairly popular. I have no opinion
    >>> either way.
    >> 
    >> What about the fact that we still support XFT?

    Mike> Is it possible to set up the fontsets by default in a way that colour
    Mike> emoji fonts like "Noto Color Emoji" can be used by default in a cairo
    Mike> build but avoided by default in an XFT build?

Iʼm not sure. I donʼt think we have a (featurep 'xft) or similar, and
parsing system-configuration-features is just icky.

Itʼs possible that adding Noto Color Emoji to a fontset will just
result in it being ignored in an XFT build. Itʼs not something Iʼve
tested.

    Mike> Yes, so if you change the fontset to use a colour emoji font for a
    Mike> certain range of characters (which should be emoji), these emoji will
    Mike> display in colour in a cairo build.

    Mike> I am not sure what happens in an XFT build, if possible such 
unsupported
    Mike> fonts should be ignored in an XFT build.

Colour fonts are ignored in an XFT build, period. Fonts that are
colour fonts but donʼt get classified as such by fontconfig (such as
"Noto Color Emoji") get added to face-ignored-fonts as and when we
discover them.

Robert