[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#39799: 28.0.50; Most emoji sequences don’t render correctly
From: |
Robert Pluim |
Subject: |
bug#39799: 28.0.50; Most emoji sequences don’t render correctly |
Date: |
Fri, 28 Feb 2020 16:57:12 +0100 |
>>>>> 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
- bug#39799: 28.0.50; Most emoji sequences don’t render correctly, (continued)
- bug#39799: 28.0.50; Most emoji sequences don’t render correctly, Eli Zaretskii, 2020/02/28
- bug#39799: 28.0.50; Most emoji sequences don’t render correctly, Mike FABIAN, 2020/02/28
- bug#39799: 28.0.50; Most emoji sequences don’t render correctly, Eli Zaretskii, 2020/02/28
- bug#39799: 28.0.50; Most emoji sequences don’t render correctly, Robert Pluim, 2020/02/28
- bug#39799: 28.0.50; Most emoji sequences don’t render correctly, Eli Zaretskii, 2020/02/28
- bug#39799: 28.0.50; Most emoji sequences don’t render correctly, Mike FABIAN, 2020/02/28
- bug#39799: 28.0.50; Most emoji sequences don’t render correctly,
Robert Pluim <=
- bug#39799: 28.0.50; Most emoji sequences don’t render correctly, Robert Pluim, 2020/02/28
- bug#39799: 28.0.50; Most emoji sequences don’t render correctly, Mike FABIAN, 2020/02/28
- bug#39799: 28.0.50; Most emoji sequences don’t render correctly, Eli Zaretskii, 2020/02/28
- bug#39799: 28.0.50; Most emoji sequences don’t render correctly, Robert Pluim, 2020/02/28
- bug#39799: 28.0.50; Most emoji sequences don’t render correctly, Eli Zaretskii, 2020/02/28
- bug#39799: 28.0.50; Most emoji sequences don’t render correctly, Robert Pluim, 2020/02/28
- bug#39799: 28.0.50; Most emoji sequences don’t render correctly, Mike FABIAN, 2020/02/28
- bug#39799: 28.0.50; Most emoji sequences don’t render correctly, Mike FABIAN, 2020/02/28
- bug#39799: 28.0.50; Most emoji sequences don’t render correctly, Robert Pluim, 2020/02/28
- bug#39799: 28.0.50; Most emoji sequences don’t render correctly, Mike FABIAN, 2020/02/28