From: Madhu <enometh@meer.net>
To: 45557@debbugs.gnu.org
Subject: bug#45557: 27.1; Incorrect rendering of COMBINING OVERLINE
Date: Wed, 06 Jan 2021 08:08:03 +0530 (IST) [thread overview]
Message-ID: <20210106.080803.2277569991627697271.enometh@meer.net> (raw)
In-Reply-To: <87pn2rmmun.fsf@cam.ac.uk>
[-- Attachment #1: Type: Text/Plain, Size: 3210 bytes --]
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.
[-- Attachment #2: test.txt --]
[-- Type: Text/Plain, Size: 104 bytes --]
x̅
एमैक्स् व ईमेक्स् व एमक्स् व इमक्स्
next prev parent reply other threads:[~2021-01-06 2:38 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-30 13:42 bug#45557: 27.1; Incorrect rendering of COMBINING OVERLINE Stephen Eglen
2020-12-31 5:24 ` Lars Ingebrigtsen
2020-12-31 7:33 ` Eli Zaretskii
2020-12-31 9:06 ` Stephen Eglen
2020-12-31 14:15 ` Eli Zaretskii
2020-12-31 13:45 ` Eli Zaretskii
2020-12-31 14:12 ` Stephen Eglen
2020-12-31 15:14 ` Eli Zaretskii
2020-12-31 16:11 ` Stephen Eglen
2021-01-01 8:28 ` Stephen Eglen
2021-01-01 11:09 ` Lars Ingebrigtsen
2021-01-02 18:47 ` James Cloos
2021-01-06 2:38 ` Madhu [this message]
2021-01-06 15:10 ` Eli Zaretskii
2021-01-06 16:00 ` Madhu
2021-01-06 16:10 ` Eli Zaretskii
2021-01-07 6:10 ` Madhu
2021-01-07 14:16 ` Eli Zaretskii
2021-01-07 15:28 ` Robert Pluim
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210106.080803.2277569991627697271.enometh@meer.net \
--to=enometh@meer.net \
--cc=45557@debbugs.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).