bug#39554: 27.0.50; cairo not composing sequences

[Eli Zaretskii <eliz@gnu.org>]

> From: James Cloos <cloos@jhcloos.com>
> Date: Mon, 10 Feb 2020 15:53:32 -0500
> 
> Sequences like 0̸ fail to display composed in master --with-cairo but do
> when usin xft.

Please show a complete reproducing recipe for this problem.

> In a version w/o cairo I get:
> 
> Composed with the following character(s) "̸" using this font:
>   xft:-unknown-DejaVu Sans Mono-normal-normal-normal-*-22-*-*-*-m-0-iso10646-1
> by these glyphs:
> 
> and the single char takes up the same width as any ascii letter.
> 
> W/ cair i get:
> 
> Composed with the following character(s) "̸" using this font:
>   ftcrhb:-unknown-DejaVu Sans Mono-normal-normal-normal-*-22-*-*-*-m-0-iso10646-1
> by these glyphs:
>   [0 1 48 19 13 1 12 16 0 nil]
>   [0 1 824 704 13 0 13 17 1 nil]
> 
> and the single char takes twice the expected width, but still works as a
> sing;e char.  OTOH, in the *Help* buffer '"̸"' is three separate chars.
> Buth with xft '"̸"' displays with the slash overlaying the first ".
> As it should.

This means that the font backend couldn't produce a single glyph for
the character combination, for some reason, so it displayed the
original glyphs as a single grapheme cluster.  IOW, character
composition did work, it just didn't find a precomposed glyph in the
font, or maybe the precomposed glyph was rejected for some reason.

We need the detailed use case to investigate.

Please also tell what is your version of HarfBuzz, in case this
matters.

And in the XFT case, what was the shaping engine? was it libflt?

Thanks.