[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: |
Mike FABIAN |
Subject: |
bug#39799: 28.0.50; Most emoji sequences don’t render correctly |
Date: |
Sat, 29 Feb 2020 17:59:25 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) |
Eli Zaretskii <eliz@gnu.org> さんはかきました:
>> > And the resulting display is what you expect? If not, then I think
>> > you need to find a font which supports Emoji presentation of
>> > characters such as Ⓜ, and make Emacs use it for those sequences.
>>
>> Yes, in the case of Ⓜ️ U+24C2 U+FE0F the result in Emacs is perfect
>> when using “Noto Color Emoji” or “Joypixels”. It is displayed in colour
>> and behaves as a single character in the buffer, the variation selector
>> is not displayed as a box. This is perfect.
>>
>> But when using Symbola for the same sequence one sees U+FE0F as an ugly
>> box.
>
> So we should augment our default fontsets to use Emoji-capable fonts
> in preference to those, like Symbola, which aren't. And perhaps for
> Emoji we should make the exception in the rule that we prefer the
> default face's font, so that users will not need to tweak
> use-default-font-for-symbols to have Emoji display with those capable
> fonts. Patches to these effects are welcome.
>
>> But what about # U+0023 NUMBER SIGN ?
>>
>> This does have an emoji representation.
>
> The question is how important is to be able to display that character
> as an Emoji, in the context of the jobs that Emacs is mainly used
> for. Maybe not too much.
I agree, not very important at all. I am surprised why this exists at
all as an emoji.
>> How could this ever work in Emacs? If you have to decide for a single
>> font to render U+0023 in Emacs, you would need to set a “capable” emoji
>> font for an ASCII character like #. One probably does not want to do
>> that.
>
> If fonts like DejaVu Sans Mono and others, routinely used for
> displaying fixed-pitch text (such as program source code) acquire the
> capabilities of displaying Emoji, that is exactly what should be done.
> As long as the current tendency of using Emoji everywhere continues, I
> see no reason not to expect those fonts to be enhanced to support
> Emoji.
Yes, maybe that could be a long term solution.
--
Mike FABIAN <mfabian@redhat.com>
睡眠不足はいい仕事の敵だ。
- 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, 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, Mike FABIAN, 2020/02/29
- bug#39799: 28.0.50; Most emoji sequences don’t render correctly, Eli Zaretskii, 2020/02/29
- bug#39799: 28.0.50; Most emoji sequences don’t render correctly, Mike FABIAN, 2020/02/29
- bug#39799: 28.0.50; Most emoji sequences don’t render correctly, Eli Zaretskii, 2020/02/29
- bug#39799: 28.0.50; Most emoji sequences don’t render correctly,
Mike FABIAN <=
- 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, Eli Zaretskii, 2020/02/28
- bug#39799: 28.0.50; Most emoji sequences don’t render correctly, Mike FABIAN, 2020/02/29
- bug#39799: 28.0.50; Most emoji sequences don’t render correctly, Eli Zaretskii, 2020/02/29
- bug#39799: 28.0.50; Most emoji sequences don’t render correctly, Mike FABIAN, 2020/02/29
- bug#39799: 28.0.50; Most emoji sequences don’t render correctly, Eli Zaretskii, 2020/02/29