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

[Eli Zaretskii]

> 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.

For example, if I type the following 4 characters:

  LATIN SMALL LETTER U (U+0075) + COMBINING GRAVE ACCENT (U+0300) +
  CGJ (U+034F) + COMBINING DIAERESIS (U+0308)

I see the composition working correctly, provided that I use a font
that supports all the 4 codepoints.

> > 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?