unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
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̅
एमैक्स् व ईमेक्स् व एमक्स् व इमक्स्



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