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

Previous Next

Package: emacs;

Reported by: Mike FABIAN <mfabian <at> redhat.com>

Date: Wed, 26 Feb 2020 14:30:03 UTC

Severity: normal

Found in version 28.0.50

Fixed in version 28.1

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

Full log


Message #149 received at 39799 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Robert Pluim <rpluim <at> gmail.com>
Cc: 39799 <at> debbugs.gnu.org, mfabian <at> redhat.com
Subject: Re: bug#39799: 28.0.50; Most emoji sequences don’t render correctly
Date: Sat, 29 Feb 2020 00:07:05 +0200
> From: Robert Pluim <rpluim <at> gmail.com>
> Cc: mfabian <at> redhat.com,  39799 <at> debbugs.gnu.org
> Date: Fri, 28 Feb 2020 22:47:36 +0100
> 
> -fn "Noto Color Emoji" doesnʼt change the default font for me for some
>  reason, but if I change the font after startup then those sequences
>  display correctly.
> 
>   (char-table-range composition-function-table #xFE0F)
> => ([".." 1 compose-gstring-for-variation-glyph])

OK, so this feature already works for suitable fonts.

> and #xFE0F is always composable according to composite.c, so I donʼt
> understand why composing only works with Noto Color Emoji. Or does the
> font need specific support for it?

Yes, the font needs to have glyph variations, see
font-variation-glyphs and its underlying font-backend method
get_variation_glyphs.




This bug report was last modified 3 years and 256 days ago.

Previous Next


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