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

Previous Next

Full log

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

From: Mike FABIAN <mfabian <at> redhat.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: rpluim <at> gmail.com, 39799 <at> debbugs.gnu.org
Subject: Re: bug#39799: 28.0.50; Most emoji sequences don’t render correctly
Date: Sat, 29 Feb 2020 11:45:10 +0100

Eli Zaretskii <eliz <at> gnu.org> さんはかきました:

>> From: Mike FABIAN <mfabian <at> redhat.com>
>> Cc: Robert Pluim <rpluim <at> gmail.com>,  39799 <at> debbugs.gnu.org
>> Date: Sat, 29 Feb 2020 08:50:40 +0100
>> 
>> >> 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.
>> 
>> http://unicode.org/reports/tr51/#Presentation_Style
>> 
>> doesn’t seem to say that the fonts should have the variations.
>
> Please elaborate: which part thereof says that, and what are the
> implications regarding the fonts?

I think it is a bit vague. It does not say that this should be handled
by the fonts having glyphs for both styles, it does not seems to say
that it should be handled by switching fonts according to the variation
either. Currently no font which implements both the text and the emoji
representation seems to exist. So currently one can only make it work by
switching fonts depending on whether one wants to show text or emoji
representation. Pango does it that way.

I don’t know whether this is supposed to be the “right” way to it.

> The rendering of Emoji sequences is handled in Emacs via the font
> backend: Emacs submits the sequence to the backend, and the backend
> returns one or more glyphs that should be used to display the
> sequence.  Emacs only submits a sequence of characters to the backend
> if the sequence matches one of the composition rules in
> composition-function-table.  And the possible match for such
> composition rules is limited to character sequences that have the same
> 'face' text property, which in particular means the same font.  In the
> case of variation selectors as part of the characters to be composed,
> Emacs additionally tests that the face's font has a glyph for the
> specified variation selector.

So this would work if a font had both black and white glyphs and colored
glyphs and used the variation selectors to select the desired glyph.

Maybe there should be a font like this, but currently no such font seems
to exist. 

> If you are saying some of the above contradicts Unicode, please point
> out which part(s) and why.

I don’t think it contradicts Unicode. At least I am not sure, I think
the specification is not clear how this should be done.

But even if it doesn’t contradict Unicode, it means that it won't work
well with currently available fonts.

-- 
Mike FABIAN <mfabian <at> redhat.com>
睡眠不足はいい仕事の敵だ。

Previous Next

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