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

[Pip Cet]

On Mon, Jun 1, 2020 at 6:37 PM Eli Zaretskii <eliz@gnu.org> wrote:
> > From: Pip Cet <pipcet@gmail.com>
> > Date: Mon, 1 Jun 2020 18:09:27 +0000
> > Cc: dfussner@googlemail.com, 41645@debbugs.gnu.org
> >
> > The problem is a zero-width glyph in a gstring. Fixing the artifact is
> > easy (see attached patch), but that still means when the cursor is on
> > the CGJ it's invisible. My impression is most code paths avoid
> > zero-width glyphs for that reason.
>
> Sorry, I don't follow.  The composition-function-table entry for CGJ
> is this:
>
>   (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...)

> When the composition happens, what glyphs
> are returned from the shaper?

921          lgstring = safe_call (7, Vauto_composition_function, AREF
(rule, 2),
(gdb) n
925      return unbind_to (count, lgstring);
(gdb) pp lgstring
[[#<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]
(gdb) pp rule
[nil 0 compose-gstring-for-graphic]
(gdb) c
Continuing.

> On my system, with a font that supports
> that character, if I type "a b c d CGJ x y z" (without the spaces), I
> see just "abcdxyz" with nothing between d and x, not even a thin
> space.  And "C-u C-x =" on d then reports:
>
>                position: 149 of 153 (97%), column: 3
>               character: d (displayed as d) (codepoint 100, #o144, #x64)
>                 charset: ascii (ASCII (ISO646 IRV))
>   code point in charset: 0x64
>                  script: latin
>                  syntax: w      which means: word
>                category: .:Base, L:Left-to-right (strong), a:ASCII, l:Latin, 
> r:Roman
>                to input: type "C-x 8 RET 64" or "C-x 8 RET LATIN SMALL LETTER 
> D"
>             buffer code: #x64
>               file code: #x64 (encoded by coding system iso-latin-1-dos)
>                 display: composed to form "d͏" (see below)
>
>   Composed with the following character(s) "͏" using this font:
>     harfbuzz:-outline-Code2000-normal-normal-normal-*-16-*-*-*-p-*-iso8859-1
>   by these glyphs:
>     [0 1 100 71 10 0 9 11 0 nil]
>     [0 1 847 3 6 0 1 0 1 [0 0 0]]
>
> Is what you see on your system similar?

Not at all.

> If so, which glyph is
> zero-width, and why does it cause trouble on your system, but not on
> mine?

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

> > How about this, as a first stop-gap until we figure out how to
> > properly prevent automatic compositions resulting in zero-width struct
> > glyphs?
>
> Not sure yet.  I need to understand the problem better before I have
> an opinion about the proposed change.

As I said, it's a stop-gap at best.