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

[David Fussner]

I've tried Eli's fix on master, and it looks exactly right in both
Hebrew and the LTR scripts. The only place where I can still get the
CGJ as an independent glyph to turn up in C-u C-x =, assuming the same
font is used for it and for the surrounding glyphs, is at the
beginning of a line, both LTR and RTL. I'm struggling to think of a
use case for this (?)

I'll test other fixes that come along for the artifacts -- thanks again.

On Tue, 2 Jun 2020 at 20:21, Pip Cet <pipcet@gmail.com> wrote:
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> >> From: Pip Cet <pipcet@gmail.com>
> >> Date: Mon, 1 Jun 2020 19:48:15 +0000
> >> Cc: dfussner@googlemail.com, 41645@debbugs.gnu.org
> >>
> >> >   (aref composition-function-table #x34f)
> >> >    => (["\\c.\\c^+" 1 compose-gstring-for-graphic]
> >> >        [nil 0 compose-gstring-for-graphic])
> >>
> >> > So CGJ is supposed to be composed with the previous character,
> >> > similarly to diacritics.
> >>
> >> (BTW, isn't that regexp wrong? a base character can be followed by two
> >> diacritics, then a CGJ, then another diacritic...)
> >
> > No, I don't think the regexp is wrong.  Every character whose Unicode
> > general-category property is Mn is given the '^' ("combining")
> > category, see characters.el.  The CGJ is one of them, but all the
> > accents and diacritics are also of that class.  So the above matches
> > any sequence of Mn characters in any order and permutation -- which is
> > of course more than is needed, but we rely on the shaper to combine
> > only those that should be.
>
> You're right, thanks for the explanation.
>
> >> > And another question: in the cases where you see artifacts, does the
> >> > call to font-shape-gstring inside compose-gstring-for-graphic return
> >> > nil or non-nil?
> >>
> >> Neither, it's never reached. The first rule fails because font_range
> >> restricts the composition range to a single character, so the second
> >> rule applies.
> >
> > OK, that's the crucial fact: it means that the font used for CGJ is
> > not the same one as used for the surrounding text.  This is a
> > situation I never saw on my systems.  In addition, the font used for
> > the CGJ has a zero-width glyph for it, which is another thing I never
> > saw (I meanwhile tried almost 20 different fonts supporting the CGJ,
> > and all of them either produce a 1-pixel thin space or the funny box
> > with a circle inside).
> >
> > So I think now it's clear what is going when this particular font is
> > present, and we are left...
> >
> >> I think we're just failing to deal with a zero-width autocomposition
> >> glyph, because we're dealing fine with the same glyph when
> >> autocomposition is off.
> >>
> >> xdisp.c:
> >> 30008          if (get_char_glyph_code (it->char_to_display, font, 
> >> &char2b))
> >> 30009            {
> >> 30010              pcm = get_per_char_metric (font, &char2b);
> >> 30011              if (pcm->width == 0
> >> 30012              && pcm->rbearing == 0 && pcm->lbearing == 0)
> >> 30013            pcm = NULL;
> >> 30014            }
> >>
> >
> > ...with this.  I think you are right, and we should do the same with
> > zero-width LGLYPH_STRING, forcing it->glyph_not_available_p to
> > non-zero, and then doing something like this in
> > fill_gstring_glyph_string:
> >
> >   if (s->font == NULL || glyph_not_available_p)
> >     {
> >       s->font_not_found_p = true;
> >       s->font = FRAME_FONT (s->f);
> >     }
> >
> > similar to what fill_glyph_string does.  WDYT?
>
> I agree; the more I think about it, the more dangerous zero-sized
> characters seem to me.
>
> And almost all of my concerns apply to characters with zero x advance,
> no matter whether they have lbearing or rbearing > 0.
>
> Maybe, for master, we should reject those as well? I was going to say
> "or force their width to be at least a single pixel", but I'm not even
> sure that's sufficient on hidpi screens...
>
> So, in summary, I'd like to do the following:
>
> 1. abort if we ever find ourselves drawing a zero-width cursor
> 2. reject lgstrings of zero width
> 3. reject all glyphs of zero width outside of compositions
> 4. allow users to specify a minimum width, perhaps relative to the font
> size, so they can always see their cursor
>
> ...which would be quite a different patch.