[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#39799: 28.0.50; Most emoji sequences don’t render correctly
From: |
Eli Zaretskii |
Subject: |
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@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.
- bug#39799: 28.0.50; Most emoji sequences don’t render correctly, Robert Pluim, 2021/09/20
- bug#39799: 28.0.50; Most emoji sequences don’t render correctly, Eli Zaretskii, 2021/09/21
- bug#39799: 28.0.50; Most emoji sequences don’t render correctly, Robert Pluim, 2021/09/21
- bug#39799: 28.0.50; Most emoji sequences don’t render correctly,
Eli Zaretskii <=
- bug#39799: 28.0.50; Most emoji sequences don’t render correctly, Eli Zaretskii, 2021/09/21
- bug#39799: 28.0.50; Most emoji sequences don’t render correctly, Robert Pluim, 2021/09/21
- bug#39799: 28.0.50; Most emoji sequences don’t render correctly, Eli Zaretskii, 2021/09/21
- bug#39799: 28.0.50; Most emoji sequences don’t render correctly, Robert Pluim, 2021/09/22
- bug#39799: 28.0.50; Most emoji sequences don’t render correctly, Mike FABIAN, 2021/09/24
- bug#39799: 28.0.50; Most emoji sequences don’t render correctly, Eli Zaretskii, 2021/09/25
- bug#39799: 28.0.50; Most emoji sequences don’t render correctly, Mike FABIAN, 2021/09/25
- bug#39799: 28.0.50; Most emoji sequences don’t render correctly, Eli Zaretskii, 2021/09/25
bug#39799: 28.0.50; Most emoji sequences don’t render correctly, Mike FABIAN, 2021/09/21