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

[Artur Malabarba <bruce.connor.am@gmail.com>]

Indeed, this works.

2015-07-10 17:06 GMT+01:00 handa <handa@gnu.org>:
> 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
>