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

[Eli Zaretskii]

> 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.  When the composition happens, what glyphs
are returned from the shaper?  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?  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.

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