bug#73752: 29.4; Ligatures are randomly rendered with extra spaces

[Eli Zaretskii <eliz@gnu.org>]

> From: Tim Ruffing <dev@real-or-random.org>
> Cc: dev@real-or-random.org, xuan@xlk.me, 73752@debbugs.gnu.org
> Date: Mon, 04 Nov 2024 01:11:39 +0100
> 
> This fixes the problem:  

Thanks.  But do you understand why?

And how did you arrive to the conclusion that this is the change which
might help?

> diff --git a/src/ftfont.c b/src/ftfont.c
> index 882d3eec256..2be443108f1 100644
> --- a/src/ftfont.c
> +++ b/src/ftfont.c
> @@ -2994,9 +2994,8 @@ fthbfont_begin_hb_font (struct font *font, double
> *position_unit)
>    struct font_info *ftfont_info = (struct font_info *) font;
>  
>    *position_unit = 1.0 / (1 << 6);
> -  if (! ftfont_info->hb_font)
> -    ftfont_info->hb_font
> -      = hb_ft_font_create_referenced (ftfont_info->ft_size->face);
> +  ftfont_info->hb_font
> +    = hb_ft_font_create_referenced (ftfont_info->ft_size->face);
>    return ftfont_info->hb_font;
>  }
>  
> That is, it makes at least the bug with Yixuan's script disappear. I
> haven't yet verified if this fixes what I often see during my daily
> usage.

That code was written by a leading HarfBuzz developer, so it's hard
for me to believe that it is so incorrect.

OTOH, I see that ftcrhbfont is the _only_ HarfBuzz-based font backend
which implements the end_hb_font method, and I think you both told me
that only the Cairo build has this problem?  If so, I think the code
to look at is the end_hb_font method and what it does to the hb_font
object.  The end_hb_font method is called each time the shaper is
called, so whatever it does to the hb_font object is inherited by the
next call to the shaper.

Visuwesh, do the problems you see also disappear when you install the
change in fthbfont_begin_hb_font which removes the
!ftfont_info->hb_font condition for calling
hb_ft_font_create_referenced?

I'm also adding Yamamoto-san to this discussion, in the hope that he
could have some ideas or suggestions.