bug#39799: 28.0.50; Most emoji sequences don’t render correctly

[Mike FABIAN]

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

>> From: Mike FABIAN <mfabian@redhat.com>
>> Cc: Robert Pluim <rpluim@gmail.com>,  39799@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@redhat.com>
睡眠不足はいい仕事の敵だ。