bug#56789: 28.1.90; Emoji composition problems with Harfbuzz 5.0.1-1

bug#56789: 28.1.90; Emoji composition problems with Harfbuzz 5.0.1-1

[Simon Pugnet]

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

I have just updated the Harfbuzz package in Arch Linux to
harfbuzz-5.0.1-1 and I've noticed that some emojis are no longer
displayed properly. From an initial investigation it appears to be
only composed sequences that have problems.

Instead of seeing a correctly composed emoji sequence as before, I now
only see an empty box with a single-pixel border.

Calling describe-char on one of these boxes shows the base emojis
properly. For example: -

             position: 20 of 39 (49%), column: 19
            character: 👩 (displayed as 👩) (codepoint 128105,
            #o372151, #x1f469)
              charset: unicode (Unicode (ISO10646))
code point in charset: 0x1F469
               script: emoji
               syntax: w 	which means: word
             category: .:Base
             to input: type "C-x 8 RET 1f469" or "C-x 8 RET WOMAN"
          buffer code: #xF0 #x9F #x91 #xA9
            file code: #xF0 #x9F #x91 #xA9 (encoded by coding system
            utf-8-unix)
              display: composed to form "👩‍❤️‍👨" (see below)

Composed with the following character(s) "‍❤️‍👨" using this font:
  ftcrhb:-GOOG-Noto Color
  Emoji-normal-normal-normal-*-13-*-*-*-m-0-iso10646-1
by these glyphs:
  [0 5 128105 2178 16 0 17 13 4 [0 0 0]]
with these character(s):
  ‍ (#x200d) ZERO WIDTH JOINER
  ❤ (#x2764) HEAVY BLACK HEART
  ️ (#xfe0f) VARIATION SELECTOR-16
  ‍ (#x200d) ZERO WIDTH JOINER
  👨 (#x1f468) MAN

Each individual character image is shown properly for me, but the
composition isn't (in this case it previously showed a man and a woman
and a love heart in between them). i.e. I see something like 'display:
composed to form "[ ]" (see below)' in the output above.

I'm not sure if this is a bug in Emacs or Harfbuzz however it only
started happening after the upgrade to 5.0.1-1

Thank you for your time,

Simon



In GNU Emacs 28.1.90 (build 18, x86_64-pc-linux-gnu, GTK+ Version
3.24.34, cairo version 1.17.6)
 of 2022-07-26 built on palenque
Repository revision: 970190b84485e4511b094546395a7e710f894fae
Repository branch: emacs-28
Windowing system distributor 'The X.Org Foundation', version
11.0.12101004
System Description: Arch Linux

Configured using:
 'configure --with-native-compilation --with-json --with-modules
 --with-xinput2'

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ
JPEG
JSON LCMS2 LIBOTF LIBSYSTEMD LIBXML2 M17N_FLT MODULES NATIVE_COMP
NOTIFY
INOTIFY PDUMPER PNG RSVG SECCOMP SOUND THREADS TIFF
TOOLKIT_SCROLL_BARS
X11 XDBE XIM XPM GTK3 ZLIB

Important settings:
  value of $LC_CTYPE: en_GB.UTF-8
  value of $LANG: en_GB.UTF-8
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8-unix

Major mode: Text

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs
rfc822 mml mml-sec epa derived epg rfc6068 epg-config gnus-util rmail
rmail-loaddefs auth-source eieio eieio-core eieio-loaddefs
password-cache json map comp comp-cstr warnings rx cl-seq cl-macs
cl-extra text-property-search time-date subr-x seq byte-opt gv
bytecomp
byte-compile cconv mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums
mm-util mail-prsvr mail-utils wid-edit descr-text help-mode
cl-loaddefs
cl-lib iso-transl tooltip eldoc paren electric uniquify ediff-hook
vc-hooks lisp-float-type elisp-mode mwheel term/x-win x-win
term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode lisp-mode prog-mode
register
page tab-bar menu-bar rfn-eshadow isearch easymenu timer select
scroll-bar mouse jit-lock font-lock syntax font-core term/tty-colors
frame minibuffer cl-generic cham georgian utf-8-lang misc-lang
vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932
hebrew greek romanian slovak czech european ethiopic indian cyrillic
chinese composite emoji-zwj charscript charprop case-table epa-hook
jka-cmpr-hook help simple abbrev obarray cl-preloaded nadvice button
loaddefs faces cus-face macroexp files window text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote threads dbusbind inotify lcms2
dynamic-setting system-font-setting font-render-setting cairo
move-toolbar gtk x-toolkit x multi-tty make-network-process
native-compile emacs)

Memory information:
((conses 16 114901 17962)
 (symbols 48 21114 1)
 (strings 32 87518 2289)
 (string-bytes 1 2298262)
 (vectors 16 28938)
 (vector-slots 8 1511821 27694)
 (floats 8 34 74)
 (intervals 56 291 0)
 (buffers 992 13))

[-- Attachment #2: attachment.sig --]
[-- Type: application/pgp-signature, Size: 877 bytes --]

bug#56789: 28.1.90; Emoji composition problems with Harfbuzz 5.0.1-1

[Robert Pluim]

>>>>> On Wed, 27 Jul 2022 06:10:06 +0000, Simon Pugnet <simon@polaris64.net> said:

    Simon> I have just updated the Harfbuzz package in Arch Linux to
    Simon> harfbuzz-5.0.1-1 and I've noticed that some emojis are no longer
    Simon> displayed properly. From an initial investigation it appears to be
    Simon> only composed sequences that have problems.

    Simon> Instead of seeing a correctly composed emoji sequence as before, I now
    Simon> only see an empty box with a single-pixel border.

What does hb-view show? Something like

hb-view  --output-file=foo.svg --font-size=13 \
/usr/share/fonts/truetype/noto/NotoColorEmoji.ttf \
-u 1f469,200d,2764,fe0f,200d,1f468

and then display foo.svg

    Simon> I'm not sure if this is a bug in Emacs or Harfbuzz however it only
    Simon> started happening after the upgrade to 5.0.1-1

I donʼt think weʼve changed anything in this area recently. Certainly
not on the emacs-28 branch.

Robert
-- 

bug#56789: 28.1.90; Emoji composition problems with Harfbuzz 5.0.1-1

[Simon Pugnet]

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


"Robert Pluim" <rpluim@gmail.com> writes:

> What does hb-view show? Something like
>
> hb-view  --output-file=foo.svg --font-size=13 \
> /usr/share/fonts/truetype/noto/NotoColorEmoji.ttf \
> -u 1f469,200d,2764,fe0f,200d,1f468
>
> and then display foo.svg

That highlighted a missing shared library: -

  hb-view: error while loading shared libraries: libchafa.so.0: cannot
  open shared object file: No such file or directory

I searched through Arch's package repository and found: -

  $ pacman -Ss chafa
  community/chafa 1.12.0-1
      Image-to-text converter supporting a wide range of symbols and
      palettes, transparency, animations, etc.

I installed this and then hb-view started working. The output was as
I'd expect: a properly composed image. I restarted Emacs however the
same problem persists. Perhaps I need to rebuild Emacs so I'll try
that in a bit.

If that fixes it then it looks like the Arch harfbuzz package now
depends on chafa, however it is not listed as a dependency. That would
then be a bug with the Arch packaging I think.

Thanks for your help!

--
Simon Pugnet
https://www.polaris64.net/

[-- Attachment #2: attachment.sig --]
[-- Type: application/pgp-signature, Size: 877 bytes --]

bug#56789: 28.1.90; Emoji composition problems with Harfbuzz 5.0.1-1

[Simon Pugnet]

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


Simon Pugnet <simon@polaris64.net> writes:

> "Robert Pluim" <rpluim@gmail.com> writes:
>
>> What does hb-view show? Something like
>>
>> hb-view  --output-file=foo.svg --font-size=13 \
>> /usr/share/fonts/truetype/noto/NotoColorEmoji.ttf \
>> -u 1f469,200d,2764,fe0f,200d,1f468
>>
>> and then display foo.svg
>
> That highlighted a missing shared library: -
>
>  hb-view: error while loading shared libraries: libchafa.so.0:
>  cannot
>  open shared object file: No such file or directory
>
> I searched through Arch's package repository and found: -
>
>  $ pacman -Ss chafa
>  community/chafa 1.12.0-1
>      Image-to-text converter supporting a wide range of symbols and
>      palettes, transparency, animations, etc.
>
> I installed this and then hb-view started working. The output was as
> I'd expect: a properly composed image. I restarted Emacs however the
> same problem persists. Perhaps I need to rebuild Emacs so I'll try
> that in a bit.
>
> If that fixes it then it looks like the Arch harfbuzz package now
> depends on chafa, however it is not listed as a dependency. That
> would
> then be a bug with the Arch packaging I think.
>
> Thanks for your help!

Following up on this, rebuilding Emacs didn't help. I also used
LD_DEBUG while running Emacs and I cannot see any reference to chafa,
so perhaps that was only a dependency for hb-view and not harfbuzz
itself? I also looked through the LD_DEBUG output and I couldn't see
anything that looked like a problem (e.g. missing harfbuzz symbols).

Kind regards,

--
Simon Pugnet
https://www.polaris64.net/

[-- Attachment #2: attachment.sig --]
[-- Type: application/pgp-signature, Size: 877 bytes --]

bug#56789: 28.1.90; Emoji composition problems with Harfbuzz 5.0.1-1

[Eli Zaretskii]

> Cc: 56789@debbugs.gnu.org
> Date: Wed, 27 Jul 2022 09:01:15 +0000
> From: Simon Pugnet <simon@polaris64.net>
> 
> > I installed this and then hb-view started working. The output was as
> > I'd expect: a properly composed image. I restarted Emacs however the
> > same problem persists. Perhaps I need to rebuild Emacs so I'll try
> > that in a bit.
> >
> > If that fixes it then it looks like the Arch harfbuzz package now
> > depends on chafa, however it is not listed as a dependency. That
> > would
> > then be a bug with the Arch packaging I think.
> >
> > Thanks for your help!
> 
> Following up on this, rebuilding Emacs didn't help. I also used
> LD_DEBUG while running Emacs and I cannot see any reference to chafa,
> so perhaps that was only a dependency for hb-view and not harfbuzz
> itself? I also looked through the LD_DEBUG output and I couldn't see
> anything that looked like a problem (e.g. missing harfbuzz symbols).

In your build, Cairo is also used, so maybe this is a Cairo problem,
or something between HarfBuzz and Cairo.  Or maybe the font you are
using causes this; did you try to upgrade to the latest version of
Noto Color Emoji?

This part of the "C-u C-x ="s output:

		display: composed to form "👩‍❤️‍👨" (see below)

  Composed with the following character(s) "‍❤️‍👨" using this font:
    ftcrhb:-GOOG-Noto Color
    Emoji-normal-normal-normal-*-13-*-*-*-m-0-iso10646-1
  by these glyphs:
    [0 5 128105 2178 16 0 17 13 4 [0 0 0]]
  with these character(s):
    ‍ (#x200d) ZERO WIDTH JOINER
    ❤ (#x2764) HEAVY BLACK HEART
    ️ (#xfe0f) VARIATION SELECTOR-16
    ‍ (#x200d) ZERO WIDTH JOINER
    👨 (#x1f468) MAN

means that Emacs did recognize a composable sequence, and did pass it
all to HarfBuzz for shaping.  What happens next is entirely up to
HarfBuzz, the font, and Cairo.

bug#56789: 28.1.90; Emoji composition problems with Harfbuzz 5.0.1-1

[Eli Zaretskii]

> Date: Wed, 27 Jul 2022 06:10:06 +0000
> From: Simon Pugnet <simon@polaris64.net>
> 
> Instead of seeing a correctly composed emoji sequence as before, I now
> only see an empty box with a single-pixel border.

Could you show a screenshot of that "empty box"?

Also, does this happen in "emacs -Q"?

bug#56789: 28.1.90; Emoji composition problems with Harfbuzz 5.0.1-1

[Simon Pugnet]

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

Hi Eli,

"Eli Zaretskii" <eliz@gnu.org> writes:

>> Date: Wed, 27 Jul 2022 06:10:06 +0000
>> From: Simon Pugnet <simon@polaris64.net>
>>
>> Instead of seeing a correctly composed emoji sequence as before, I
>> now
>> only see an empty box with a single-pixel border.
>
> Could you show a screenshot of that "empty box"?


> Also, does this happen in "emacs -Q"?

Yes, my screenshot and tests were done with "emacs -Q".

Kind regards,

--
Simon Pugnet
https://www.polaris64.net/

[-- Attachment #2: Emacs-emoji.png --]
[-- Type: image/png, Size: 108894 bytes --]

[-- Attachment #3: attachment.sig --]
[-- Type: application/pgp-signature, Size: 877 bytes --]

bug#56789: 28.1.90; Emoji composition problems with Harfbuzz 5.0.1-1

[Simon Pugnet]

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

Hi Eli,

"Eli Zaretskii" <eliz@gnu.org> writes:

>> Cc: 56789@debbugs.gnu.org
>> Date: Wed, 27 Jul 2022 09:01:15 +0000
>> From: Simon Pugnet <simon@polaris64.net>
>>
>> Following up on this, rebuilding Emacs didn't help. I also used
>> LD_DEBUG while running Emacs and I cannot see any reference to
>> chafa,
>> so perhaps that was only a dependency for hb-view and not harfbuzz
>> itself? I also looked through the LD_DEBUG output and I couldn't
>> see
>> anything that looked like a problem (e.g. missing harfbuzz
>> symbols).
>
> In your build, Cairo is also used, so maybe this is a Cairo problem,
> or something between HarfBuzz and Cairo.  Or maybe the font you are
> using causes this; did you try to upgrade to the latest version of
> Noto Color Emoji?

I'm currently using the latest version of the font that is available
from the Arch Linux repositories. The last time this font was updated
on my system was 2022-06-22.

This issue was not present this morning with the same build of Emacs,
it only started after performing a system update which included this
new version of HarfBuzz.

Here's the pacman.log for this particular set of updates: -

 [2022-07-27T06:43:50+0100] [PACMAN] Running 'pacman --sync -y -u --'
 [2022-07-27T06:43:50+0100] [PACMAN] synchronizing package lists
 [2022-07-27T06:43:52+0100] [PACMAN] starting full system upgrade
 [2022-07-27T06:45:06+0100] [ALPM] running 'ghc-unregister.hook'...
 [2022-07-27T06:45:07+0100] [ALPM] transaction started
 [2022-07-27T06:45:07+0100] [ALPM] upgraded libcap (2.64-1 -> 2.65-1)
 [2022-07-27T06:45:07+0100] [ALPM] upgraded iso-codes (4.10.0-1 ->
 4.11.0-1)
 [2022-07-27T06:45:07+0100] [ALPM] upgraded harfbuzz (4.4.1-1 ->
 5.0.1-1)
 [2022-07-27T06:45:07+0100] [ALPM] upgraded appstream-glib (0.7.18-2
 -> 0.8.0-1)
 [2022-07-27T06:45:07+0100] [ALPM] upgraded firefox (102.0.1-1 ->
 103.0-1)
 [2022-07-27T06:45:07+0100] [ALPM] upgraded harfbuzz-icu (4.4.1-1 ->
 5.0.1-1)
 [2022-07-27T06:45:07+0100] [ALPM] upgraded haskell-githash
 (0.1.6.2-120 -> 0.1.6.2-121)
 [2022-07-27T06:45:07+0100] [ALPM] upgraded haskell-hpack (0.34.7-4 ->
 0.34.7-5)
 [2022-07-27T06:45:07+0100] [ALPM] upgraded haskell-optparse-simple
 (0.1.1.4-152 -> 0.1.1.4-153)
 [2022-07-27T06:45:07+0100] [ALPM] upgraded haskell-pantry (0.5.6-2 ->
 0.5.6-3)
 [2022-07-27T06:45:07+0100] [ALPM] upgraded haskell-th-expand-syns
 (0.4.9.0-37 -> 0.4.10.0-1)
 [2022-07-27T06:45:07+0100] [ALPM] upgraded haskell-th-reify-many
 (0.1.10-53 -> 0.1.10-54)
 [2022-07-27T06:45:07+0100] [ALPM] upgraded hwloc (2.7.1-1 -> 2.8.0-1)
 [2022-07-27T06:45:07+0100] [ALPM] upgraded lib32-harfbuzz (4.4.1-1 ->
 5.0.1-1)
 [2022-07-27T06:45:07+0100] [ALPM] upgraded lib32-libcap (2.64-1 ->
 2.65-1)
 [2022-07-27T06:45:07+0100] [ALPM] upgraded libplacebo (4.192.1-3 ->
 4.208.0-1)
 [2022-07-27T06:45:07+0100] [ALPM] upgraded libspiro (1:20200505-2 ->
 1:20220722-1)
 [2022-07-27T06:45:07+0100] [ALPM] upgraded lv2 (1.18.4-2 -> 1.18.6-1)
 [2022-07-27T06:45:07+0100] [ALPM] upgraded
 mobile-broadband-provider-info (20220511-1 -> 20220725-1)
 [2022-07-27T06:45:07+0100] [ALPM] upgraded protobuf (21.3-2 ->
 21.4-1)
 [2022-07-27T06:45:08+0100] [ALPM] upgraded pyright (1.1.263-1 ->
 1.1.264-1)
 [2022-07-27T06:45:08+0100] [ALPM] upgraded python-executing (0.9.0-1
 -> 0.9.1-1)
 [2022-07-27T06:45:08+0100] [ALPM] upgraded python-pip (22.1.2-1 ->
 22.2-1)
 [2022-07-27T06:45:08+0100] [ALPM] upgraded python-protobuf (21.3-2 ->
 21.4-1)
 [2022-07-27T06:45:08+0100] [ALPM] upgraded serd (0.30.12-2 ->
 0.30.14-1)
 [2022-07-27T06:45:08+0100] [ALPM] upgraded sord (0.16.10-2 ->
 0.16.12-3)
 [2022-07-27T06:45:08+0100] [ALPM] upgraded sratom (0.6.10-3 ->
 0.6.12-1)
 [2022-07-27T06:45:08+0100] [ALPM] upgraded stack (2.7.5-105 ->
 2.7.5-106)
 [2022-07-27T06:45:08+0100] [ALPM] upgraded vlc (3.0.17.4-6 ->
 3.0.17.4-7)
 [2022-07-27T06:45:08+0100] [ALPM] transaction completed
 [2022-07-27T06:45:08+0100] [ALPM] running '30-systemd-update.hook'...
 [2022-07-27T06:45:08+0100] [ALPM] running 'ghc-register.hook'...
 [2022-07-27T06:45:08+0100] [ALPM] running
 'gtk-update-icon-cache.hook'...
 [2022-07-27T06:45:08+0100] [ALPM] running
 'update-desktop-database.hook'...
 [2022-07-27T06:45:08+0100] [ALPM] running
 'update-vlc-plugin-cache.hook'...


> This part of the "C-u C-x ="s output:
>
> 		display: composed to form "👩‍❤️‍👨" (see below)
>
>   Composed with the following character(s) "‍❤️‍👨" using this font:
>     ftcrhb:-GOOG-Noto Color
>     Emoji-normal-normal-normal-*-13-*-*-*-m-0-iso10646-1
>   by these glyphs:
>     [0 5 128105 2178 16 0 17 13 4 [0 0 0]]
>   with these character(s):
>     ‍ (#x200d) ZERO WIDTH JOINER
>     ❤ (#x2764) HEAVY BLACK HEART
>     ️ (#xfe0f) VARIATION SELECTOR-16
>     ‍ (#x200d) ZERO WIDTH JOINER
>     👨 (#x1f468) MAN
>
> means that Emacs did recognize a composable sequence, and did pass
> it
> all to HarfBuzz for shaping.  What happens next is entirely up to
> HarfBuzz, the font, and Cairo.

After installation of libchafa it looks like HarfBuzz is correctly
composing the sequence as evidenced by the output of the hb-view
command that Robert asked me to run earlier. So perhaps it is an issue
with Cairo. However I haven't updated this since 2022-04-06; it's
currently at version 1.17.6-2.

I will try recompiling Emacs without Cairo and I'll let you know what
happens.

Thanks for your help,

--
Simon Pugnet
https://www.polaris64.net/

[-- Attachment #2: attachment.sig --]
[-- Type: application/pgp-signature, Size: 877 bytes --]

bug#56789: 28.1.90; Emoji composition problems with Harfbuzz 5.0.1-1

[Robert Pluim]

>>>>> On Wed, 27 Jul 2022 12:06:43 +0000, Simon Pugnet <simon@polaris64.net> said:

    Simon> Hi Eli,
    Simon> "Eli Zaretskii" <eliz@gnu.org> writes:

    >>> Date: Wed, 27 Jul 2022 06:10:06 +0000
    >>> From: Simon Pugnet <simon@polaris64.net>
    >>> 
    >>> Instead of seeing a correctly composed emoji sequence as before, I
    >>> now
    >>> only see an empty box with a single-pixel border.
    >> 
    >> Could you show a screenshot of that "empty box"?


    >> Also, does this happen in "emacs -Q"?

    Simon> Yes, my screenshot and tests were done with "emacs -Q".

I can reproduce this on archlinux. If I downgrade to harfbuzz 4.4.1-1
the composed sequence displays properly , so it seems like a harfbuzz issue
(or the way weʼre supposed to use the API has changed). In any case I
think this needs to be taken up with the harfbuzz developers.

Robert
-- 

bug#56789: 28.1.90; Emoji composition problems with Harfbuzz 5.0.1-1

[Robert Pluim]

>>>>> On Wed, 27 Jul 2022 14:52:45 +0200, Robert Pluim <rpluim@gmail.com> said:

>>>>> On Wed, 27 Jul 2022 12:06:43 +0000, Simon Pugnet <simon@polaris64.net> said:
    Simon> Hi Eli,
    Simon> "Eli Zaretskii" <eliz@gnu.org> writes:

    >>>> Date: Wed, 27 Jul 2022 06:10:06 +0000
    >>>> From: Simon Pugnet <simon@polaris64.net>
    >>>> 
    >>>> Instead of seeing a correctly composed emoji sequence as before, I
    >>>> now
    >>>> only see an empty box with a single-pixel border.
    >>> 
    >>> Could you show a screenshot of that "empty box"?


    >>> Also, does this happen in "emacs -Q"?

    Simon> Yes, my screenshot and tests were done with "emacs -Q".

    Robert> I can reproduce this on archlinux. If I downgrade to harfbuzz 4.4.1-1
    Robert> the composed sequence displays properly , so it seems like a harfbuzz issue
    Robert> (or the way weʼre supposed to use the API has changed). In any case I
    Robert> think this needs to be taken up with the harfbuzz developers.

OK, known issue in harfbuzz, will be fixed in their next release:

<https://github.com/harfbuzz/harfbuzz/issues/3754>
<https://github.com/harfbuzz/harfbuzz/issues/3755>

Robert
-- 

bug#56789: 28.1.90; Emoji composition problems with Harfbuzz 5.0.1-1

[Simon Pugnet]

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

"Robert Pluim" <rpluim@gmail.com> writes:

>     Robert> I can reproduce this on archlinux. If I downgrade to
>     harfbuzz 4.4.1-1
>     Robert> the composed sequence displays properly , so it seems
>     like a harfbuzz issue
>     Robert> (or the way weʼre supposed to use the API has changed).
>     In any case I
>     Robert> think this needs to be taken up with the harfbuzz
>     developers.
>
> OK, known issue in harfbuzz, will be fixed in their next release:
>
> <https://github.com/harfbuzz/harfbuzz/issues/3754>
> <https://github.com/harfbuzz/harfbuzz/issues/3755>
>
> Robert

Thank you for looking into that for me, I also just saw these two
issues and was about to let you know!

I'll leave things as-is for now then and I'll let you know what
happens when the update becomes available.

Kind regards,

--
Simon Pugnet
https://www.polaris64.net/

[-- Attachment #2: attachment.sig --]
[-- Type: application/pgp-signature, Size: 877 bytes --]

bug#56789: 28.1.90; Emoji composition problems with Harfbuzz 5.0.1-1

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  56789@debbugs.gnu.org
> Date: Wed, 27 Jul 2022 16:02:32 +0200
> 
> OK, known issue in harfbuzz, will be fixed in their next release:
> 
> <https://github.com/harfbuzz/harfbuzz/issues/3754>
> <https://github.com/harfbuzz/harfbuzz/issues/3755>

Thanks.  I wonder how come hb-view does display this sequence
correctly...

So I guess we should close this?

bug#56789: 28.1.90; Emoji composition problems with Harfbuzz 5.0.1-1

[Robert Pluim]

>>>>> On Wed, 27 Jul 2022 18:56:10 +0300, Eli Zaretskii <eliz@gnu.org> said:

    >> From: Robert Pluim <rpluim@gmail.com>
    >> Cc: Eli Zaretskii <eliz@gnu.org>,  56789@debbugs.gnu.org
    >> Date: Wed, 27 Jul 2022 16:02:32 +0200
    >> 
    >> OK, known issue in harfbuzz, will be fixed in their next release:
    >> 
    >> <https://github.com/harfbuzz/harfbuzz/issues/3754>
    >> <https://github.com/harfbuzz/harfbuzz/issues/3755>

    Eli> Thanks.  I wonder how come hb-view does display this sequence
    Eli> correctly...

    Eli> So I guess we should close this?

I guess. I built emacs against the 'main' branch of harfbuzz, ran it
with an appropriate LD_LIBRARY_PATH, and it worked correctly.

Robert
-- 

bug#56789: 28.1.90; Emoji composition problems with Harfbuzz 5.0.1-1

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: simon@polaris64.net,  56789@debbugs.gnu.org
> Date: Wed, 27 Jul 2022 18:00:25 +0200
> 
> >>>>> On Wed, 27 Jul 2022 18:56:10 +0300, Eli Zaretskii <eliz@gnu.org> said:
> 
>     >> From: Robert Pluim <rpluim@gmail.com>
>     >> Cc: Eli Zaretskii <eliz@gnu.org>,  56789@debbugs.gnu.org
>     >> Date: Wed, 27 Jul 2022 16:02:32 +0200
>     >> 
>     >> OK, known issue in harfbuzz, will be fixed in their next release:
>     >> 
>     >> <https://github.com/harfbuzz/harfbuzz/issues/3754>
>     >> <https://github.com/harfbuzz/harfbuzz/issues/3755>
> 
>     Eli> Thanks.  I wonder how come hb-view does display this sequence
>     Eli> correctly...
> 
>     Eli> So I guess we should close this?
> 
> I guess. I built emacs against the 'main' branch of harfbuzz, ran it
> with an appropriate LD_LIBRARY_PATH, and it worked correctly.

Thanks, closing.