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

[Pip Cet <pipcet@gmail.com>]

On Mon, Jun 1, 2020 at 7:35 PM Eli Zaretskii <eliz@gnu.org> wrote:

> 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. In that rule, nchars is 1 in
compose-gstring-for-graphic, so all it does is set the adjustment on
the lglyph:

[[#<font-object "-PfEd-DejaVu
Sans-normal-normal-normal-*-22-*-*-*-*-0-iso10646-1"> 847] nil [0 0
847 768 0 0 0 0 0 nil] nil nil nil nil nil nil nil]

turns into

[[#<font-object "-PfEd-DejaVu
Sans-normal-normal-normal-*-22-*-*-*-*-0-iso10646-1"> 847] nil [0 0
847 768 0 0 0 0 0 [0 0 0]] nil nil nil nil nil nil nil]

> IOW, is the shaper+font producing the composed glyph,
> or is that the fallback Lisp code in compose-gstring-for-graphic,
> because font-shape-gstring returns nil?  Perhaps that's the reason for
> the differences between what you see and what I see.

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            }