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

[Mike FABIAN]

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?

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

> And anyway, the name "Noto Color Emoji" seems to imply it's a font
> created to display Emoji, not symbols in general, let alone non-symbol
> blocks we currently set up to use Symbola if that is available.

Yes, if possible, "Noto Color Emoji" should be preferred for the emoji
but Symbola should be preferred for all the other symbols.

>> As Mike clarified, you need to change the fontsets in order to get
>> them to display in colour (uncomposed, of course).
>
> I don't see how that is relevant.  Fontsets are just means to cause
> Emacs use a certain font for a certain range of characters.  Fontsets
> do not affect color Emoji support.

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

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

-- 
Mike FABIAN <mfabian@redhat.com>
睡眠不足はいい仕事の敵だ。