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

[David Fussner]

Addendum to my previous email: my apologies for the inaccuracy in my
initial bug report -- I believe I failed to notice in the Latin script
that the letter glyphs were from DejaVu Sans Mono and the CGJ from
DejaVu Sans, hence the artifacts there. When both are DejaVu Sans, the
issue doesn't appear, except in the Hebrew examples.

On Tue, 2 Jun 2020 at 14:45, David Fussner <dfussner@googlemail.com> wrote:
>
> 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.