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

[Pip Cet]

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.