bug#34035: 26.1; Arabic shadda-kasrah renders incorrectly

[Eli Zaretskii]

> From: Stephen Berman <stephen.berman@gmx.net>
> Cc: craven@gmx.net,  34035@debbugs.gnu.org
> Date: Fri, 11 Jan 2019 11:54:06 +0100
> 
> > This clearly says that Emacs uses DejaVu Sans for this grapheme
> > cluster, so I wonder what does "switch the font to Symbola" mean in
> > this case.  Can you tell what you did to switch to Symbola?
> 
> I started emacs with -Q, then I selected the "Set Default Font..." entry
> from the Options menu, clicked on "Symbola Regular" and pressed the
> select button.  After doing that, `C-u C-x =' on a character in
> *scratch* shows this:
> 
> xft:-UFAS-Symbola-normal-normal-semicondensed-*-15-*-*-*-*-0-iso10646-1 (#x37)

Symbola supports only 10 characters from the Arabic block, so Emacs
selects a different font for these characters.  What I don't
understand is why the default font has any effect on how characters in
a non-default font are displayed.  CC'ing Handa-san, in the hope that
he might have some insights.

> >>   [0 2 1587 6022 0 1 6 16 -8 [0 3 0]]
> >>   [0 2 1587 1377 16 0 16 6 4 nil]
> >> 
> >> Note the second line here is identical to the first line of glyphs on
> >> master.
> >
> > I would hardly call this "identical", since the offsets are also
> > different.  But I don't think that matters at this point.
> 
> I don't know if it's significant, but it's only first glyph line from
> the harfbuzz build:
> [0 2 1587 6022 0 1 6 16 -8 [0 3 0]]
> that differs from the second glyph line from the master build:
> [0 2 0 6022 0 -15 -10 13 -11 [-16 2 0]]
> The second glyph line from the harfbuzz build:
> [0 2 1587 1377 16 0 16 6 4 nil]
> is identical to the first glyph line from the master build:
> [0 2 1587 1377 16 0 16 6 4 nil]

The identical line describes the base character (1587 is its Unicode
codepoint) in the same font, so it's small wonder that it is the same
with both shaping engines.  The different lines describe the
shadda-kasra diacritics.  (I'm mildly bothered by the fact that the
harfbuzz branch displays the information in reverse order, it might
mean some bug there.)

You can read more about the values displayed there in the doc string
of composition-get-gstring.