Unicode 15

Unicode 15

[समीर सिंह Sameer Singh]

[-- Attachment #1: Type: text/plain, Size: 227 bytes --]

Unicode 15 has just been released, and I was wondering whether this time I
could work on updating Emacs to support it and if there are some special
instructions/guidelines that I should keep in mind while updating it?

Thanks.

[-- Attachment #2: Type: text/html, Size: 292 bytes --]

Re: Unicode 15

[Eli Zaretskii]

> From: समीर सिंह Sameer Singh
>  <lumarzeli30@gmail.com>
> Date: Wed, 14 Sep 2022 06:26:35 +0530
> 
> Unicode 15 has just been released, and I was wondering whether this time I could work on updating Emacs
> to support it and if there are some special instructions/guidelines that I should keep in mind while updating it?

See admin/notes/unicode.

Re: Unicode 15

[समीर सिंह Sameer Singh]

[-- Attachment #1: Type: text/plain, Size: 1064 bytes --]

The admin/notes/unicode file also asks to include the BidiCharacterTest.txt
file to the admin/unidata directory,
but unlike other files whose unicode 14 version were present, this one was
missing, so should it be place there regardless?

Also in lisp/international/characters.el file in the char-width-table soft
hyphen (00ad) is not included in the non-spacing category
even though it has the Cf text property, should I include it there, also in
the non spacing category, arabic-semicolon (061b) is included
even though it has the Po property, so should it be removed?

Thanks.



On Wed, Sep 14, 2022 at 8:09 AM Eli Zaretskii <eliz@gnu.org> wrote:

> > From: समीर सिंह Sameer Singh
> >  <lumarzeli30@gmail.com>
> > Date: Wed, 14 Sep 2022 06:26:35 +0530
> >
> > Unicode 15 has just been released, and I was wondering whether this time
> I could work on updating Emacs
> > to support it and if there are some special instructions/guidelines that
> I should keep in mind while updating it?
>
> See admin/notes/unicode.
>

[-- Attachment #2: Type: text/html, Size: 1533 bytes --]

Re: Unicode 15

[Eli Zaretskii]

> From: समीर सिंह Sameer Singh <lumarzeli30@gmail.com>
> Date: Wed, 14 Sep 2022 17:54:21 +0530
> Cc: emacs-devel@gnu.org
> 
> The admin/notes/unicode file also asks to include the BidiCharacterTest.txt file to the admin/unidata
> directory,
> but unlike other files whose unicode 14 version were present, this one was missing, so should it be place
> there regardless?

It is not missing, it is in test/manual/ directory.  See this part of
admin/notes/unicode:

  The file BidiCharacterTest.txt should be copied to the test suite, and
  if its format has changed, the file biditest.el there should be
  modified to follow suit.  If there's trailing whitespace in
  BidiCharacterTest.txt, it should be removed before committing the new
  version.

> Also in lisp/international/characters.el file in the char-width-table soft hyphen (00ad) is not included in the
> non-spacing category
> even though it has the Cf text property, should I include it there

No, because Emacs doesn't (yet) handle this character as Unicode mandates.

> also in the non spacing category,
> arabic-semicolon (061b) is included
> even though it has the Po property, so should it be removed?

Probably, yes.

Re: Unicode 15

[समीर सिंह Sameer Singh]

[-- Attachment #1: Type: text/plain, Size: 1739 bytes --]

admin/notes/unicode says that the zero-width characters are not taken from
EastAsianWidth.txt and also
there are some zero width characters defined in that which are not present
in the char-width-table in
lisp/international/characters.el, so should I include them there or is
there some other location from where
I have to verify the zero width characters?

Thanks.

On Wed, Sep 14, 2022 at 6:22 PM Eli Zaretskii <eliz@gnu.org> wrote:

> > From: समीर सिंह Sameer Singh <lumarzeli30@gmail.com>
> > Date: Wed, 14 Sep 2022 17:54:21 +0530
> > Cc: emacs-devel@gnu.org
> >
> > The admin/notes/unicode file also asks to include the
> BidiCharacterTest.txt file to the admin/unidata
> > directory,
> > but unlike other files whose unicode 14 version were present, this one
> was missing, so should it be place
> > there regardless?
>
> It is not missing, it is in test/manual/ directory.  See this part of
> admin/notes/unicode:
>
>   The file BidiCharacterTest.txt should be copied to the test suite, and
>   if its format has changed, the file biditest.el there should be
>   modified to follow suit.  If there's trailing whitespace in
>   BidiCharacterTest.txt, it should be removed before committing the new
>   version.
>
> > Also in lisp/international/characters.el file in the char-width-table
> soft hyphen (00ad) is not included in the
> > non-spacing category
> > even though it has the Cf text property, should I include it there
>
> No, because Emacs doesn't (yet) handle this character as Unicode mandates.
>
> > also in the non spacing category,
> > arabic-semicolon (061b) is included
> > even though it has the Po property, so should it be removed?
>
> Probably, yes.
>

[-- Attachment #2: Type: text/html, Size: 2300 bytes --]

Re: Unicode 15

[Eli Zaretskii]

> From: समीर सिंह Sameer Singh <lumarzeli30@gmail.com>
> Date: Wed, 14 Sep 2022 21:56:03 +0530
> Cc: emacs-devel@gnu.org
> 
> admin/notes/unicode says that the zero-width characters are not taken from EastAsianWidth.txt and also
> there are some zero width characters defined in that which are not present in the char-width-table in
> lisp/international/characters.el, so should I include them there or is there some other location from where
> I have to verify the zero width characters?

Emacs doesn't really display zero-width characters as having zero
width, certainly not on TTY frames, where char-width-table is most
important.  So I don't think we should change this, not in general.
But if there are specific characters where we really display them as
nothing, we could discuss that case by case.

Re: Unicode 15

[समीर सिंह Sameer Singh]

[-- Attachment #1: Type: text/plain, Size: 1032 bytes --]

Thanks! I should not change it then and instead verify the double width
characters

On Wed, Sep 14, 2022 at 10:12 PM Eli Zaretskii <eliz@gnu.org> wrote:

> > From: समीर सिंह Sameer Singh <lumarzeli30@gmail.com>
> > Date: Wed, 14 Sep 2022 21:56:03 +0530
> > Cc: emacs-devel@gnu.org
> >
> > admin/notes/unicode says that the zero-width characters are not taken
> from EastAsianWidth.txt and also
> > there are some zero width characters defined in that which are not
> present in the char-width-table in
> > lisp/international/characters.el, so should I include them there or is
> there some other location from where
> > I have to verify the zero width characters?
>
> Emacs doesn't really display zero-width characters as having zero
> width, certainly not on TTY frames, where char-width-table is most
> important.  So I don't think we should change this, not in general.
> But if there are specific characters where we really display them as
> nothing, we could discuss that case by case.
>

[-- Attachment #2: Type: text/html, Size: 1476 bytes --]

Re: Unicode 15

[Eli Zaretskii]

> From: समीर सिंह Sameer Singh <lumarzeli30@gmail.com>
> Date: Wed, 14 Sep 2022 22:15:32 +0530
> Cc: emacs-devel@gnu.org
> 
> Thanks! I should not change it then and instead verify the double width characters

Yes.  Especially any changes and additions in that area.

Re: Unicode 15

[समीर सिंह Sameer Singh]

[-- Attachment #1: Type: text/plain, Size: 996 bytes --]

The lisp/international/ucs-normalize-tests.el is failing and the file says
to adjust
ucs-normalize-tests--failing-lines-part1 and
ucs-normalize-tests--failing-lines-part2,
but what do the numbers mean there?

Also, the latest noto emoji[1] is in a new format named COLRv1 which I
guess is not yet supported by
emacs therefore all of the emojis are appearing as blank, so we should
support that in the future.
in the meantime do you know of any other font which supports the newest
emojis so that emoji support could be
tested?

Thanks.

[1] https://fonts.google.com/noto/specimen/Noto+Color+Emoji

On Wed, Sep 14, 2022 at 10:24 PM Eli Zaretskii <eliz@gnu.org> wrote:

> > From: समीर सिंह Sameer Singh <lumarzeli30@gmail.com>
> > Date: Wed, 14 Sep 2022 22:15:32 +0530
> > Cc: emacs-devel@gnu.org
> >
> > Thanks! I should not change it then and instead verify the double width
> characters
>
> Yes.  Especially any changes and additions in that area.
>

[-- Attachment #2: Type: text/html, Size: 1599 bytes --]

Re: Unicode 15

[Eli Zaretskii]

> From: समीर सिंह Sameer Singh <lumarzeli30@gmail.com>
> Date: Thu, 15 Sep 2022 06:56:48 +0530
> Cc: emacs-devel@gnu.org
> 
> The lisp/international/ucs-normalize-tests.el is failing and the file says to adjust
> ucs-normalize-tests--failing-lines-part1 and ucs-normalize-tests--failing-lines-part2,
> but what do the numbers mean there?

See the code: those are failing line numbers and character numbers.

When the test fails, you have a procedure to update those so it
passes:

  ;; If there are lines marked as failing (see
  ;; `ucs-normalize-tests--failing-lines-part1' and
  ;; `ucs-normalize-tests--failing-lines-part2'), they may need to be
  ;; adjusted when NormalizationTest.txt is updated.  Run the function
  ;; `ucs-normalize-check-failing-lines' to see what changes are needed.

Note the last sentence.  admin/notes/unicode mentions that comment
where it describes how to run this test.

> Also, the latest noto emoji[1] is in a new format named COLRv1 which I guess is not yet supported by
> emacs therefore all of the emojis are appearing as blank, so we should support that in the future.
> in the meantime do you know of any other font which supports the newest emojis so that emoji support could
> be
> tested?

I don't know of any other fonts, sorry.

As for COLRv1, I think it's HarfBuzz and/or Cairo that need to support
that, no?  But I'm just guessing here.  One thing to try is to run
hb-view and see what it produces for these sequences.

Re: Unicode 15

[समीर सिंह Sameer Singh]

[-- Attachment #1: Type: text/plain, Size: 2969 bytes --]

>
> See the code: those are failing line numbers and character numbers.
>
> When the test fails, you have a procedure to update those so it
> passes:
>
>   ;; If there are lines marked as failing (see
>   ;; `ucs-normalize-tests--failing-lines-part1' and
>   ;; `ucs-normalize-tests--failing-lines-part2'), they may need to be
>   ;; adjusted when NormalizationTest.txt is updated.  Run the function
>   ;; `ucs-normalize-check-failing-lines' to see what changes are needed.
>
> Note the last sentence.  admin/notes/unicode mentions that comment
> where it describes how to run this test.


Thanks, the tests are passing now.

>
>  As for COLRv1, I think it's HarfBuzz and/or Cairo that need to support
> that, no?  But I'm just guessing here.  One thing to try is to run
> hb-view and see what it produces for these sequences.
>

I tried with the latest harfbuzz master and the hb-view is producing a
blank file,
also this is what harfbuzz says about it COLRv1 support [1]:

> HarfBuzz implementation will follow later. No major client relies on
> HarfBuzz for color fonts currently, but we certainly want to implement
> later as there are clients who like to remove FreeType dependency
> completely.
>

[1] https://github.com/googlefonts/colr-gradients-spec#harfbuzz

On Thu, Sep 15, 2022 at 11:26 AM Eli Zaretskii <eliz@gnu.org> wrote:

> > From: समीर सिंह Sameer Singh <lumarzeli30@gmail.com>
> > Date: Thu, 15 Sep 2022 06:56:48 +0530
> > Cc: emacs-devel@gnu.org
> >
> > The lisp/international/ucs-normalize-tests.el is failing and the file
> says to adjust
> > ucs-normalize-tests--failing-lines-part1 and
> ucs-normalize-tests--failing-lines-part2,
> > but what do the numbers mean there?
>
> See the code: those are failing line numbers and character numbers.
>
> When the test fails, you have a procedure to update those so it
> passes:
>
>   ;; If there are lines marked as failing (see
>   ;; `ucs-normalize-tests--failing-lines-part1' and
>   ;; `ucs-normalize-tests--failing-lines-part2'), they may need to be
>   ;; adjusted when NormalizationTest.txt is updated.  Run the function
>   ;; `ucs-normalize-check-failing-lines' to see what changes are needed.
>
> Note the last sentence.  admin/notes/unicode mentions that comment
> where it describes how to run this test.
>
> > Also, the latest noto emoji[1] is in a new format named COLRv1 which I
> guess is not yet supported by
> > emacs therefore all of the emojis are appearing as blank, so we should
> support that in the future.
> > in the meantime do you know of any other font which supports the newest
> emojis so that emoji support could
> > be
> > tested?
>
> I don't know of any other fonts, sorry.
>
> As for COLRv1, I think it's HarfBuzz and/or Cairo that need to support
> that, no?  But I'm just guessing here.  One thing to try is to run
> hb-view and see what it produces for these sequences.
>

[-- Attachment #2: Type: text/html, Size: 4104 bytes --]

Re: Unicode 15

[Robert Pluim]

>>>>> On Thu, 15 Sep 2022 17:30:22 +0530, समीर सिंह Sameer Singh <lumarzeli30@gmail.com> said:


    समीर> I tried with the latest harfbuzz master and the hb-view is producing a
    समीर> blank file,
    समीर> also this is what harfbuzz says about it COLRv1 support [1]:

So when not using COLRv1 fonts, do the emoji sequences in
emoji-zwj-sequences.txt and emoji-sequences.txt all look correct? (Iʼm
assuming Unicode 15 has added sequences, and consequently updated
those files)

Robert
-- 

Re: Unicode 15

[समीर सिंह Sameer Singh]

[-- Attachment #1: Type: text/plain, Size: 1054 bytes --]

>
> So when not using COLRv1 fonts, do the emoji sequences in
> emoji-zwj-sequences.txt and emoji-sequences.txt all look correct? (Iʼm
> assuming Unicode 15 has added sequences, and consequently updated
> those files)
>

Yes, when using a non COLRv1 font such as Twemoji 14, the emojis in those
files appear correctly, obviously except
the unicode 15 ones which do not render correctly.

On Thu, Sep 15, 2022 at 6:07 PM Robert Pluim <rpluim@gmail.com> wrote:

> >>>>> On Thu, 15 Sep 2022 17:30:22 +0530, समीर सिंह Sameer Singh <
> lumarzeli30@gmail.com> said:
>
>
>     समीर> I tried with the latest harfbuzz master and the hb-view is
> producing a
>     समीर> blank file,
>     समीर> also this is what harfbuzz says about it COLRv1 support [1]:
>
> So when not using COLRv1 fonts, do the emoji sequences in
> emoji-zwj-sequences.txt and emoji-sequences.txt all look correct? (Iʼm
> assuming Unicode 15 has added sequences, and consequently updated
> those files)
>
> Robert
> --
>

[-- Attachment #2: Type: text/html, Size: 1635 bytes --]

Re: Unicode 15

[Robert Pluim]

>>>>> On Thu, 15 Sep 2022 18:43:25 +0530, समीर सिंह Sameer Singh <lumarzeli30@gmail.com> said:

    >> 
    >> So when not using COLRv1 fonts, do the emoji sequences in
    >> emoji-zwj-sequences.txt and emoji-sequences.txt all look correct? (Iʼm
    >> assuming Unicode 15 has added sequences, and consequently updated
    >> those files)
    >> 

    समीर> Yes, when using a non COLRv1 font such as Twemoji 14, the emojis in those
    समीर> files appear correctly, obviously except
    समीर> the unicode 15 ones which do not render correctly.

If thatʼs only because of missing glyphs in the font then thatʼs expected.

Robert
-- 

Re: Unicode 15

[समीर सिंह Sameer Singh]

[-- Attachment #1: Type: text/plain, Size: 984 bytes --]

I think I have completed almost everything to update to unicode 15, but the
problem is
insert-char (C-x 8 RET) is not listing these new characters, why is that?

Thanks.

On Thu, Sep 15, 2022 at 7:00 PM Robert Pluim <rpluim@gmail.com> wrote:

> >>>>> On Thu, 15 Sep 2022 18:43:25 +0530, समीर सिंह Sameer Singh <
> lumarzeli30@gmail.com> said:
>
>     >>
>     >> So when not using COLRv1 fonts, do the emoji sequences in
>     >> emoji-zwj-sequences.txt and emoji-sequences.txt all look correct?
> (Iʼm
>     >> assuming Unicode 15 has added sequences, and consequently updated
>     >> those files)
>     >>
>
>     समीर> Yes, when using a non COLRv1 font such as Twemoji 14, the emojis
> in those
>     समीर> files appear correctly, obviously except
>     समीर> the unicode 15 ones which do not render correctly.
>
> If thatʼs only because of missing glyphs in the font then thatʼs expected.
>
> Robert
> --
>

[-- Attachment #2: Type: text/html, Size: 1472 bytes --]

Re: Unicode 15

[Eli Zaretskii]

> From: समीर सिंह Sameer Singh <lumarzeli30@gmail.com>
> Date: Thu, 15 Sep 2022 22:35:39 +0530
> Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
> 
> I think I have completed almost everything to update to unicode 15, but the problem is
> insert-char (C-x 8 RET) is not listing these new characters, why is that?

You mean, you've updated UnicodeData.txt and other Unicode files,
you've run "make" to rebuild Emacs, and Emacs doesn't know about new
characters added by Unicode 15.0, even though UnicodeData.txt in
admin/unidata/ has them?

Re: Unicode 15

[समीर सिंह Sameer Singh]

[-- Attachment #1: Type: text/plain, Size: 845 bytes --]

No :/ is this related to mule-cmds.el? Because I did not update it, because
I could not understand it
for example why are some ranges commented out and some are missing.

On Thu, Sep 15, 2022 at 10:41 PM Eli Zaretskii <eliz@gnu.org> wrote:

> > From: समीर सिंह Sameer Singh <lumarzeli30@gmail.com>
> > Date: Thu, 15 Sep 2022 22:35:39 +0530
> > Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
> >
> > I think I have completed almost everything to update to unicode 15, but
> the problem is
> > insert-char (C-x 8 RET) is not listing these new characters, why is that?
>
> You mean, you've updated UnicodeData.txt and other Unicode files,
> you've run "make" to rebuild Emacs, and Emacs doesn't know about new
> characters added by Unicode 15.0, even though UnicodeData.txt in
> admin/unidata/ has them?
>

[-- Attachment #2: Type: text/html, Size: 1372 bytes --]

Re: Unicode 15

[Eli Zaretskii]

> From: समीर सिंह Sameer Singh <lumarzeli30@gmail.com>
> Date: Thu, 15 Sep 2022 23:03:16 +0530
> Cc: rpluim@gmail.com, emacs-devel@gnu.org
> 
> No :/ is this related to mule-cmds.el? Because I did not update it, because I could not understand it
> for example why are some ranges commented out and some are missing.

mule-cmds.el needs to be updated only if ranges of codepoints marked
as "unused" have changed, so some of their codepoints are now used for
characters.  The commented-out ranges are those whose names either
don't exist (because they are unused) or are meaningless, like those
in the various ideographic blocks.

Suppose you tell what exactly did you do with "C-x 8 RET" that didn't
work?

Re: Unicode 15

[समीर सिंह Sameer Singh]

[-- Attachment #1: Type: text/plain, Size: 1233 bytes --]

>
> Suppose you tell what exactly did you do with "C-x 8 RET" that didn't
> work?


After typing "C-x 8 RET" I type the names of the newly added characters
such as "kawi",
"nag mundari" etc in the prompt and then try to TAB autocomplete it but
they do not appear,
also when describe-char-ing these characters
their unicode name also does not show up in Character code properties

On Thu, Sep 15, 2022 at 11:57 PM Eli Zaretskii <eliz@gnu.org> wrote:

> > From: समीर सिंह Sameer Singh <lumarzeli30@gmail.com>
> > Date: Thu, 15 Sep 2022 23:03:16 +0530
> > Cc: rpluim@gmail.com, emacs-devel@gnu.org
> >
> > No :/ is this related to mule-cmds.el? Because I did not update it,
> because I could not understand it
> > for example why are some ranges commented out and some are missing.
>
> mule-cmds.el needs to be updated only if ranges of codepoints marked
> as "unused" have changed, so some of their codepoints are now used for
> characters.  The commented-out ranges are those whose names either
> don't exist (because they are unused) or are meaningless, like those
> in the various ideographic blocks.
>
> Suppose you tell what exactly did you do with "C-x 8 RET" that didn't
> work?
>

[-- Attachment #2: Type: text/html, Size: 1976 bytes --]

Re: Unicode 15

[Eli Zaretskii]

> From: समीर सिंह Sameer Singh <lumarzeli30@gmail.com>
> Date: Fri, 16 Sep 2022 00:03:33 +0530
> Cc: rpluim@gmail.com, emacs-devel@gnu.org
> 
>  Suppose you tell what exactly did you do with "C-x 8 RET" that didn't
>  work?
> 
> After typing "C-x 8 RET" I type the names of the newly added characters such as "kawi",
> "nag mundari" etc in the prompt and then try to TAB autocomplete it but they do not appear,
> also when describe-char-ing these characters
> their unicode name also does not show up in Character code properties 

And this is after rebuilding Emacs following all the changes in the
admin/unidata/ files?

Do the new characters appear in admin/unidata/unidata.txt?  That file
was supposed to be re-generated from new UnicodeData.txt.

Re: Unicode 15

[समीर सिंह Sameer Singh]

[-- Attachment #1: Type: text/plain, Size: 1125 bytes --]

Well I just made a fresh new emacs directory copied the unicode 15 files
there and compiled it,
and insert-char is now working as intended there! Maybe I did something
wrong in the old one or it was something else.

Thanks

On Fri, Sep 16, 2022 at 12:35 AM Eli Zaretskii <eliz@gnu.org> wrote:

> > From: समीर सिंह Sameer Singh <lumarzeli30@gmail.com>
> > Date: Fri, 16 Sep 2022 00:03:33 +0530
> > Cc: rpluim@gmail.com, emacs-devel@gnu.org
> >
> >  Suppose you tell what exactly did you do with "C-x 8 RET" that didn't
> >  work?
> >
> > After typing "C-x 8 RET" I type the names of the newly added characters
> such as "kawi",
> > "nag mundari" etc in the prompt and then try to TAB autocomplete it but
> they do not appear,
> > also when describe-char-ing these characters
> > their unicode name also does not show up in Character code properties
>
> And this is after rebuilding Emacs following all the changes in the
> admin/unidata/ files?
>
> Do the new characters appear in admin/unidata/unidata.txt?  That file
> was supposed to be re-generated from new UnicodeData.txt.
>

[-- Attachment #2: Type: text/html, Size: 1723 bytes --]

Re: Unicode 15

[समीर सिंह Sameer Singh]

[-- Attachment #1.1: Type: text/plain, Size: 1383 bytes --]

After using the monochrome Noto Emoji font, I can verify that the newly
added emojis are rendered correctly.

On Fri, Sep 16, 2022 at 5:31 AM समीर सिंह Sameer Singh <
lumarzeli30@gmail.com> wrote:

> Well I just made a fresh new emacs directory copied the unicode 15 files
> there and compiled it,
> and insert-char is now working as intended there! Maybe I did something
> wrong in the old one or it was something else.
>
> Thanks
>
> On Fri, Sep 16, 2022 at 12:35 AM Eli Zaretskii <eliz@gnu.org> wrote:
>
>> > From: समीर सिंह Sameer Singh <lumarzeli30@gmail.com>
>> > Date: Fri, 16 Sep 2022 00:03:33 +0530
>> > Cc: rpluim@gmail.com, emacs-devel@gnu.org
>> >
>> >  Suppose you tell what exactly did you do with "C-x 8 RET" that didn't
>> >  work?
>> >
>> > After typing "C-x 8 RET" I type the names of the newly added characters
>> such as "kawi",
>> > "nag mundari" etc in the prompt and then try to TAB autocomplete it but
>> they do not appear,
>> > also when describe-char-ing these characters
>> > their unicode name also does not show up in Character code properties
>>
>> And this is after rebuilding Emacs following all the changes in the
>> admin/unidata/ files?
>>
>> Do the new characters appear in admin/unidata/unidata.txt?  That file
>> was supposed to be re-generated from new UnicodeData.txt.
>>
>

[-- Attachment #1.2: Type: text/html, Size: 2244 bytes --]

[-- Attachment #2: emacs-unicode15-emojis.png --]
[-- Type: image/png, Size: 118689 bytes --]

Re: Unicode 15

[Robert Pluim]

>>>>> On Fri, 16 Sep 2022 10:04:02 +0530, समीर सिंह Sameer Singh <lumarzeli30@gmail.com> said:

    समीर> After using the monochrome Noto Emoji font, I can verify that the newly
    समीर> added emojis are rendered correctly.

Monochrome? I didnʼt know there was a monochrome Noto Emoji font 😀

I assume Noto Color Emoji works as well?

Anyway, if you think itʼs ready, post a patch (if itʼs not too large)
or stick it on a scratch branch somewhere.

Robert
-- 

Re: Unicode 15

[Peter Oliver]

[-- Attachment #1: Type: text/plain, Size: 870 bytes --]

On Thu, 15 Sep 2022, Eli Zaretskii wrote:

>> From: समीर सिंह Sameer Singh <lumarzeli30@gmail.com>
>>
>> Also, the latest noto emoji[1] is in a new format named COLRv1 which I guess is not yet supported by
>> emacs therefore all of the emojis are appearing as blank, so we should support that in the future.
>> in the meantime do you know of any other font which supports the newest emojis so that emoji support could
>> be
>> tested?

A CBDT version of Noto Color Emoji version 2.038 has now been pushed to https://github.com/googlefonts/noto-emoji/tree/main/fonts/.

> As for COLRv1, I think it's HarfBuzz and/or Cairo that need to support
> that, no?

I think there’s more to it than that, since COLR v0 fonts don’t work for me in Emacs either (https://debbugs.gnu.org/cgi/bugreport.cgi?bug=43058), but do work in other programs.

-- 
Peter Oliver