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

Previous Next

Full log

Message #51 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Madhu <enometh <at> meer.net>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#45557: 27.1; Incorrect rendering of COMBINING OVERLINE
Date: Wed, 06 Jan 2021 08:08:03 +0530 (IST)

[Message part 1 (text/plain, inline)]

I'm not asking to reopen this bug but I'm seeing repeatable weirdness
over the state of auto-composition-mode.  Pardon the complicated
clunky test case. The important thing is that Emacs should start off
with a font which is unable to compose the combining character
correctly.

The attached file test.txt has two lines - the first line is from the
test case upthread.  LATIN SMALL LETTER X + COMBINING OVERLINE.

The second line has tentative alternative Devanagari spellings for
Emacs (all wrong).  The interesting composition is in the last
consonant K+S of the word Emacs.  Without composition it should read

DEVANAGARI LETTER KA + DEVANAGARI SIGN VIRAMA + DEVANAGARI LETTER SA +
DEVANAGARI SIGN VIRAMA

and with composition it should read

DEVANAGARI LETTER KA Composed with DEVANAGARI SIGN VIRAMA +
DEVANAGARI LETTER SA Composed with DEVANAGARI SIGN VIRAMA

Assuming you have JuliaMono (or some font which does compose x with
overbar), Monaco (or BitstreamVeraSansMono or some font which does not
compose x with overbar), and NotoSans (which handles composed
Devanagari combining characters)

1. emacs -Q -fn Monaco ~/test.txt
---------------------
M-: auto-composition-mode ; => t.

This always gets the first line "wrong":

LATIN SMALL LETTER X
              display: by this font (glyph code)
    ftcrhb:-APPL-Monaco-normal-normal-normal-*-22-*-*-*-*-0-iso10646-1 (#x5B)
+
COMBINING OVERLINE
              display: by this font (glyph code)
    ftcrhb:-SIL -Charis SIL-normal-normal-normal-*-22-*-*-*-*-0-iso10646-1 (#x8C

Those are *not* composeḍ.
But The second line is "right".  The K+S consonants show up as

DEVANAGARI LETTER KA
 Composed with the following character(s) "्" using this font:
  ftcrhb:-GOOG-Noto Sans Devanagari UI-normal-normal-normal-*-22-*-*-*-*-0-iso10646-1
by these glyphs:
  [0 1 2325 180 13 0 14 14 0 [0 0 12]]
with these character(s):
  ् (#x94d) DEVANAGARI SIGN VIRAMA

DEVANAGARI LETTER SA"
Composed with the following character(s) "्" using this font:
  ftcrhb:-GOOG-Noto Sans Devanagari UI-normal-normal-normal-*-22-*-*-*-*-0-iso10646-1
by these glyphs:
  [2 3 2360 60 15 0 16 14 2 nil]
  [2 3 2381 80 0 -4 4 0 6 nil]
with these character(s):
  ् (#x94d) DEVANAGARI SIGN VIRAMA


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.


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.

Toggling auto-composition-mode again reverses this.

Creating a different frame with a a problematic font and then toggling
auto-composition-mode also exposes this behaviour, and it is confusing
when the same buffer is displayed in two frames

If emacs starts off with the correct font:

4. emacs -Q -fn JuliaMono test.txt

Then it all works as I think it was intended.

[test.txt (text/plain, inline)]

x̅
एमैक्स् व ईमेक्स् व एमक्स् व इमक्स्

Previous Next

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