bug#41645: 27.0.91; Combining Grapheme Joiner (#x34f) gui artifacts

[David Fussner via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

A couple of data points, in case they're helpful:

On 27.0.91 _unpatched_, I see the artifact whenever the font of the
CGJ is different from that of the glyph before it, no matter which
script I'm using. When the font of the CGJ and the previous glyph are
the same, I don't see the artifact, except in Hebrew, where it's still
present. C-u C-x = displays the CGJ on its own, as a separate glyph,
whenever it's used in Hebrew and also whenever its font doesn't match
that of the glyph before it. When the font does match, in Latin or
Greek script, the cursor doesn't stop on the CGJ, and C-u C-x = shows
it as composed with the previous character.

With Pip Cet's second patch, 27.0.91 shows exactly the same behavior
with C-u C-x =, but the visual artifact never appears, at least in my
testing, neither in Hebrew nor in the LTR scripts.

Hope this helps.

On Mon, 1 Jun 2020 at 23:37, Pip Cet <pipcet@gmail.com> wrote:
>
> On Mon, Jun 1, 2020 at 7:48 PM Pip Cet <pipcet@gmail.com> wrote:
> > > > Indeed, the composition gstring is a single zero-width glyph.
> > > See the composition information above: my interpretation of it is that
> > > the composed glyph is not zero-width.
> >
> > ... something is odd here, I agree.
>
> I think it's a very odd combination of things:
> 1. a font which defines an isolated CGJ to have zero width
> 2. an isolated CGJ appearing in the first place (in this case, because
> another font does not support CGJ)
> 3. the fall-back [nil 0 compose-gstring-for-graphic] rule defined for
> codepoint #x34f
> 4. compose-gstring-for-graphic attempting to salvage non-spacing
> characters not following base characters, and producing zero-width
> lgstrings from zero-width lglyphs
>
> Avoiding any of the four will avoid the problem. (1) is something we
> cannot fix directly. (2) is also something that a user may want. (3)
> could be dropped, and (4) could be expanded to take care of the
> zero-width case.
>
> However, as long as zero-width gstrings can somehow slip through, I
> suggest we also apply the patch I sent, assuming it fixes the problem.
>
> We might consider simply prohibiting zero-width zero-lbearing
> zero-rbearing gstrings, the way we prohibit zero-width zero-lbearing
> zero-rbearing characters in the code I posted.