bug#57066: 29.0.50; Complex emoji overlaps with text

[YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>]

On Thu, 11 Aug 2022 13:07:03 +0900,
Protesilaos Stavrou wrote:
> 
> > From: Eli Zaretskii <eliz@gnu.org>
> > Date: Wed, 10 Aug 2022 15:33:20 +0300
> 
> >> > <Shrug> strange.  What is the default value?  That is
> >> >
> >> >    M-: (default-value 'buffer-file-coding-system) RET
> >> 
> >> It is nil.
> >
> > But of course.  Should be fixed now, thanks.
> 
> Thank you!  The C-u C-x = works now.
> 
> Back to my original recipe then:
> 
> - C-x 8 e s
> - Type "sun" and RET
> - C-b
> - C-u C-x =
> 
> This gives me the following Help buffer:
> 
>                  position: 152 of 153 (99%), column: 6
>                 character: ☀ (displayed as ☀) (codepoint 9728, #o23000, #x2600)
>                   charset: unicode (Unicode (ISO10646))
>     code point in charset: 0x2600
>                    script: symbol
>                    syntax: w 	which means: word
>                  category: .:Base, j:Japanese
>                  to input: type "C-x 8 RET 2600" or "C-x 8 RET BLACK SUN WITH RAYS"
>               buffer code: #xE2 #x98 #x80
>                 file code: not encodable by coding system nil
>                   display: composed to form "☀️" (see below)
> 
>     Composed with the following character(s) "️" using this font:
>       ftcrhb:-GOOG-Noto Color Emoji-regular-normal-normal-*-13-*-*-*-m-0-iso10646-1
>     by these glyphs:
>       [0 1 9728 59 16 0 17 13 4 [0 0 2]]
>     with these character(s):
>       ️ (#xfe0f) VARIATION SELECTOR-16
> 
>     Character code properties: customize what to show
>       name: BLACK SUN WITH RAYS
>       general-category: So (Symbol, Other)
>       decomposition: (9728) ('☀')
> 
>     There are text properties here:
>       fontified            t
> 
> 
> I also attach a screenshot where the coloured sun overlaps with a double
> quotes character.
> 
> -- 
> Protesilaos Stavrou
> https://protesilaos.com

It seems that position unit adjustment for bitmap fonts is no longer
necessary on HarfBuzz 5:

  https://github.com/harfbuzz/harfbuzz/issues/489

Could you test if the following patch works?

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

diff --git a/src/ftcrfont.c b/src/ftcrfont.c
index 39ea068556..42610ccd9d 100644
--- a/src/ftcrfont.c
+++ b/src/ftcrfont.c
@@ -273,7 +273,8 @@ ftcrfont_open (struct frame *f, Lisp_Object entity, int pixel_size)
 #ifdef HAVE_HARFBUZZ
   ftcrfont_info->hb_font = NULL;
 #endif	/* HAVE_HARFBUZZ */
-  if (ft_face->units_per_EM)
+  if (hb_version_atleast (5, 0, 0)
+      || ft_face->units_per_EM)
     ftcrfont_info->bitmap_position_unit = 0;
   else
     ftcrfont_info->bitmap_position_unit = (extents.height
diff --git a/src/ftfont.h b/src/ftfont.h
index f771dc159b..5248aef649 100644
--- a/src/ftfont.h
+++ b/src/ftfont.h
@@ -66,7 +66,9 @@ #define EMACS_FTFONT_H
   cairo_scaled_font_t *cr_scaled_font;
   /* Scale factor from the bitmap strike metrics in 1/64 pixels, used
      as the hb_position_t value in HarfBuzz, to those in (scaled)
-     pixels.  The value is 0 for scalable fonts.  */
+     pixels.  The value is 0 for scalable fonts.  This is only
+     necessary for HarfBuzz prior to version 5, and the value is
+     always 0 on later versions.  */
   double bitmap_position_unit;
   /* Font metrics cache.  */
   struct font_metrics **metrics;