bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#45557: 27.1; Incorrect rendering of COMBINING OVERLINE


From: Madhu
Subject: bug#45557: 27.1; Incorrect rendering of COMBINING OVERLINE
Date: Wed, 06 Jan 2021 21:30:51 +0530 (IST)

*  Eli Zaretskii <eliz@gnu.org> <83k0sq2j9m.fsf@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?

reply via email to

[Prev in Thread] Current Thread [Next in Thread]