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 #137 received at 39799 <at> debbugs.gnu.org (full text, mbox):

From: Robert Pluim <rpluim <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
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: Fri, 28 Feb 2020 22:47:36 +0100
>>>>> On Fri, 28 Feb 2020 23:02:12 +0200, Eli Zaretskii <eliz <at> gnu.org> said:

    >> Date: Fri, 28 Feb 2020 22:25:44 +0200
    >> From: Eli Zaretskii <eliz <at> gnu.org>
    >> Cc: 39799 <at> debbugs.gnu.org
    >> 
    >> Hmm... it's possible I was confused, and the functions I mentioned are
    >> unrelated to variation selectors.  To see if that's so, try to
    >> configure composition-function-table to display such sequences as
    >> composed characters, and see what happens when you use a proper font
    >> (e.g., the one with which Gedit displays the variations).

    Eli> Looking into this some more reveals that we already have
    Eli> composition-function-table set up for variation selectors, see the end
    Eli> of lisp/language/japanese.el.  Not sure why it's in japanese.el, but
    Eli> the code doesn't seem to be specific to Japanese characters, unless
    Eli> I'm missing something.  So some debugging is required to understand
    Eli> why we don't display sequences with variation selectors as intended.
    Eli> Maybe DejaVu Sans doesn't support that?  What if you try

    Eli>   emacs -Q -fn Noto Color Emoji"

    Eli> does Emacs built with HarfBuzz then display the variation sequences as
    Eli> expected?

-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])

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?

Robert




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

Previous Next


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