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

[Eli Zaretskii]

> 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?

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.

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

Thanks.