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

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Robert Pluim <rpluim <at> gmail.com>
Cc: rgm <at> gnu.org, 39799 <at> debbugs.gnu.org, mfabian <at> redhat.com
Subject: Re: bug#39799: 28.0.50; Most emoji sequences don’t render correctly
Date: Tue, 21 Sep 2021 13:54:02 +0300

> From: Robert Pluim <rpluim <at> gmail.com>
> Cc: rgm <at> gnu.org,  39799 <at> debbugs.gnu.org,  mfabian <at> 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.

Previous Next

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