bug#45557: 27.1; Incorrect rendering of COMBINING OVERLINE

[Robert Pluim <rpluim@gmail.com>]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Thu, 07 Jan 2021 11:40:31 +0530 (IST)
>> Cc: 45557@debbugs.gnu.org
>> From: Madhu <enometh@meer.net>
>> 
>> *  Eli Zaretskii <eliz@gnu.org> <83turu11xm.fsf@gnu.org>
>> Wrote on Wed, 06 Jan 2021 18:10:29 +0200
>> >> From: Madhu <enometh@meer.net>
>> >> > Anyway, I see no Emacs problems in your description, only font
>> >> > problems.  The text you sent is displayed correctly on my system, both
>> >> > of its lines.
>> Can you try using a font with emacs which does not compose the x and
>> overbar?
>
> I already did.  The results are as I'd expect: the characters are
> rendered separately.
>
>> >> I assume the mswindows and applemac systems dont pull in harfbuzz?
>> > No, the Windows build does use HarfBuzz.
>> Whatever is doing the visual composition of x + overbar (when emacs is
>> explicitly asked not to do it by turning auto-composition-mode off) -
>> it isn't harfbuzz.  It happens on an emacs (--without-all) which links
>> to freetype without harfbuzz/cairo (and even when emacs isn't using m17n-lib)
>> Very puzzling.
>
> Indeed.

I can reproduce this behaviour using Bitstream Vera Mono and Julia
Mono. The display may show the two characters as composed, but they
actually aren't: after the 'x' thereʼs what is visually a space, but
'C-x =' says itʼs a COMBINING OVERLINE. If you then toggle
auto-composition again that visual space gets redrawn as an
OVERLINE. (and if I play with it some more, sometimes the OVERLINE
over the 'x' does not get cleared).

I can reproduce with a pgtk build as well.

Robert