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

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: rgm@gnu.org,  39799@debbugs.gnu.org,  mfabian@redhat.com
> Date: Tue, 21 Sep 2021 12:34:45 +0200
> 
>     Eli> Btw, currently U+261D followed by VS-16 doesn't compose for me,
>     Eli> probably because compose-gstring-for-variation-glyph is hardcoded to
>     Eli> work only for Han characters, and U+261D isn't, or because that
>     Eli> function is not suited to VS-16 (it looks for glyph variations in the
>     Eli> font)?  Or am I missing something?
> 
> You mean it doesnʼt get treated as a composition, or the result looks
> bad

The former.

> Composed with the following character(s) "️" using this font:
>   ftcrhb:-GOOG-Noto Color Emoji-normal-normal-normal-*-19-*-*-*-m-0-iso10646-1
> by these glyphs:
>   [0 1 9757 69 24 0 24 18 5 nil]
> with these character(s):
>   ️ (#xfe0f) VARIATION SELECTOR-16

I guess it's the font, then.  But anyway, it's confusing to have the
composition function in japanese.el, we should move it to composite.el
instead, I think.

> I think this means you'd have to add the Variation Selectors to the
> emoji script

Yes, of course.

> Iʼm not sure that *all* the
> characters need to be supported by the font: if thereʼs a ZWJ in
> there, itʼs purely functional, so thereʼs no need for a glyph for it
> (and Iʼm hoping harfbuzz agrees)

This is already handled in font_range:

  while (pos < *limit)
    {
      c = (NILP (string)
           ? fetch_char_advance_no_check (&pos, &pos_byte)
           : fetch_string_char_advance_no_check (string, &pos, &pos_byte));
      Lisp_Object category = CHAR_TABLE_REF (Vunicode_category_table, c);
      if (FIXNUMP (category)
          && (XFIXNUM (category) == UNICODE_CATEGORY_Cf  <<<<<<<<<<<<<<<<<<<<
              || CHAR_VARIATION_SELECTOR_P (c)))
        continue;

>     Eli> Btw, if you use Firefox or Chrome, or some other application that can
>     Eli> show Emoji sequences, or maybe just use HarfBuzz's hb-view, how does
>     Eli> the display of the U+2xxx changes when they are followed by VS-16?  
> Is
>     Eli> the change prominent enough for us to try to support it?  If not,
>     Eli> perhaps the above should be left out for the moment.
> 
> At least with chromium, the glyph becomes more colourful for about a
> dozen codepoints, but not for U+261D (see attached).

So it _is_ worth supporting.  Would you please make those changes in
font_range and in blocks.awk?

> The VS-16 itself is hidden.

If the composition succeeds, it will be hidden in Emacs as well.