GNU bug report logs - #45557
27.1; Incorrect rendering of COMBINING OVERLINE

Previous Next

Package: emacs;

Reported by: Stephen Eglen <sje30 <at> cam.ac.uk>

Date: Wed, 30 Dec 2020 17:38:02 UTC

Severity: normal

Tags: notabug

Found in version 27.1

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Madhu <enometh <at> meer.net>
To: eliz <at> gnu.org
Cc: 45557 <at> debbugs.gnu.org
Subject: bug#45557: 27.1; Incorrect rendering of COMBINING OVERLINE
Date: Wed, 06 Jan 2021 21:30:51 +0530 (IST)
*  Eli Zaretskii <eliz <at> gnu.org> <83k0sq2j9m.fsf <at> gnu.org>
Wrote on Wed, 06 Jan 2021 17:10:45 +0200

>> 1. emacs -Q -fn Monaco ~/test.txt
>> ---------------------
>> M-: auto-composition-mode ; => t.
>> Those are *not* composeḍ.
>
> They are not composed because Emacs didn't find a glyph in the Monaco
> font for the COMBINING OVERLINE character.  Emacs only composes
> characters if they have glyphs in the same font.
>
>> 2. M-: (set-frame-font "JuliaMonoLatin-14:hintstyle=none" nil nil)
>> ----------------
>> - Everything should look the same except the first line is rendered in
>> Julia mono. The x and the overbar are still not composed.
>
> For the same reason.
>
> (On my system, with a different font, they _are_ composed.)

Right. JuliaMono will compose them, JuliaMonoLatin won't.

>> 3.  M-x auto-composition-mode  ; to toggle
>> ----------------
>> ;; Auto-Composition mode disabled in current buffer
>> M-: auto-composition-mode ; => nil
>>
>> and voilà! Now the first line is rendered "correctly" with x and
>> overbar composed and the second line is now incorrect: the k + s
>> appear decomposed.
>
> This can only happen if some other software involved in the display
> (Cairo?) composes them.  In any case, this is not an Emacs issue.

I have a build compiled with --without-cairo --without-harfbuzz
--with-xft where it happens.  But xft pulls in both harfbuzz and cairo
anyway for its implementation.

Since emacs now hard-depends on harfbuzz, harfbuzz issues become emacs
issues!

>> 4. emacs -Q -fn JuliaMono test.txt
>>
>> Then it all works as I think it was intended.
>
> Which might mean the hintstyle=none may be a factor here?

just the difference between JuliaMono and JuliaMonoLatin I think,
which I was blind to. Thanks for checking

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

I assume the mswindows and applemac systems dont pull in harfbuzz?

This bug report was last modified 4 years and 134 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.