bug#20984: 25.0.50; Combining accents don't display properly in certain fonts

[handa]

In article <83oajkbkbo.fsf@gnu.org>, Eli Zaretskii <eliz@gnu.org> writes:

> Btw, I wonder why xftfont and libotf don't do the same as Uniscribe,
> i.e. instruct Emacs to display the à character.  This is what the
> composition data I see here says:

>   [0 1 97 231 8 1 7 12 4 nil]

> This single vector tells Emacs to display one glyph, and 231 is its
> code in the font.

> It is strange that libotf doesn't take this shortcut, although I'm
> quite sure a glyph for à is available both in DejaVu Sans Mono and in
> Source Code Pro.  But I don't know enough about libotf.

Sorry, I found that my build of emacs-24.5 was without m17n-flt (and
libotf).  So, the combining was done by Emacs itself using the function
compose-gstring-for-graphic.

I've just rebuild emacs-24.5 with m17n-flt, and see the same problem as
the trunk, which means that the culprit may be in m17n-flt or libotf.

So, I checked m17n-flt and found that the rule for combining latin
characters has a bug when a font has such OTF features as subs, sups.

Please try the attached COMBINING.flt by these steps:
1. make the directory ~/.m17n.d
2. put COMBINING.flt under that directory.
3. run emacs

By the why, the reason of m17n-flt/libotf not taking the shortcut above
is that the Source Code Pro font doesn't have such a feature.  I suspect
Uniscribe has a special code for using precomposed glyph without asking
a font about its features.  So, perhaps, even with TTF font (i.e. a font
of no OTF features), Uniscribe can display a-grave sequence with the
precomposed glyph.

---
K. Handa
handa@gnu.org

COMBINING.flt
Description: Binary data