[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 08:08:03 +0530 (IST) |
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.
x̅
एमैक्स् व ईमेक्स् व एमक्स् व इमक्स्
- bug#45557: 27.1; Incorrect rendering of COMBINING OVERLINE, Stephen Eglen, 2021/01/01
- bug#45557: 27.1; Incorrect rendering of COMBINING OVERLINE,
Madhu <=
- bug#45557: 27.1; Incorrect rendering of COMBINING OVERLINE, Eli Zaretskii, 2021/01/06
- bug#45557: 27.1; Incorrect rendering of COMBINING OVERLINE, Madhu, 2021/01/06
- bug#45557: 27.1; Incorrect rendering of COMBINING OVERLINE, Eli Zaretskii, 2021/01/06
- bug#45557: 27.1; Incorrect rendering of COMBINING OVERLINE, Madhu, 2021/01/07
- bug#45557: 27.1; Incorrect rendering of COMBINING OVERLINE, Eli Zaretskii, 2021/01/07
- bug#45557: 27.1; Incorrect rendering of COMBINING OVERLINE, Robert Pluim, 2021/01/07