GNU bug report logs - #39799
28.0.50; Most emoji sequences don’t render correctly

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Mike FABIAN <mfabian <at> redhat.com>
Cc: rpluim <at> gmail.com, 39799 <at> debbugs.gnu.org
Subject: bug#39799: 28.0.50; Most emoji sequences don’t render correctly
Date: Fri, 28 Feb 2020 22:21:36 +0200

> From: Mike FABIAN <mfabian <at> redhat.com>
> Cc: Eli Zaretskii <eliz <at> gnu.org>,  39799 <at> debbugs.gnu.org
> Date: Fri, 28 Feb 2020 18:30:12 +0100
> 
> U+24C2 is an Emoji which has both a text and an emoji presentation.

I don't think I understand how this fact is relevant to which font
Emacs selects for a character.  Can you elaborate on the relation?

> If I test in gedit, U+24C2 on  its  own is displayed in black and white
> (happens to use "MS Gothic" font on my system).
> U+24C2 U+FE0E is displayed in black and white in gedit as well.
> U+24C2 U+FE0F is displayed in colour in gedit  using the "Noto Color
> Emoji" font.
> 
> These selectors don’t work in Emacs for me. U+24C2, U+24C2 U+FE0E, and
> U+24C2 U+FE0F *all* display in black and white for me in Emacs.
> 
> The selectors are displayed as a narrow box.

Emacs doesn't yet support display of sequences with variation
selectors, although at least some part of the infrastructure is
already there, see ftfont_variation_glyphs and similar functions in
other HarfBuzz-based font backends.

> The presence of such selectors in a currently visible buffer make my
> Emacs extremely slow and unresponsive, I can hardly finish typing this
> e-mail.

Does it help to set inhibit-compacting-font-caches non-nil?

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.