From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#39799: 28.0.50; Most emoji sequences =?UTF-8?Q?don=E2=80=99t?= render correctly Date: Sat, 29 Feb 2020 12:04:54 +0200 Message-ID: <83k145emk9.fsf@gnu.org> References: <83lfongp4p.fsf@gnu.org> <835zfrglu5.fsf@gnu.org> <83wo86g8pg.fsf@gnu.org> <83k146g46x.fsf@gnu.org> <83imjqg1iv.fsf@gnu.org> <837e06foof.fsf@gnu.org> <83y2sme617.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="32379"; mail-complaints-to="usenet@ciao.gmane.io" Cc: rpluim@gmail.com, 39799@debbugs.gnu.org To: Mike FABIAN Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Feb 29 11:06:14 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1j7z0f-0008Lm-G8 for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 29 Feb 2020 11:06:13 +0100 Original-Received: from localhost ([::1]:59016 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j7z0d-0007rA-EX for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 29 Feb 2020 05:06:11 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:46341) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j7z0V-0007qx-Kt for bug-gnu-emacs@gnu.org; Sat, 29 Feb 2020 05:06:04 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1j7z0U-0004Vr-L4 for bug-gnu-emacs@gnu.org; Sat, 29 Feb 2020 05:06:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:56523) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1j7z0U-0004Vh-HR for bug-gnu-emacs@gnu.org; Sat, 29 Feb 2020 05:06:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1j7z0U-0001rL-BT for bug-gnu-emacs@gnu.org; Sat, 29 Feb 2020 05:06:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 29 Feb 2020 10:06:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 39799 X-GNU-PR-Package: emacs Original-Received: via spool by 39799-submit@debbugs.gnu.org id=B39799.15829707157063 (code B ref 39799); Sat, 29 Feb 2020 10:06:02 +0000 Original-Received: (at 39799) by debbugs.gnu.org; 29 Feb 2020 10:05:15 +0000 Original-Received: from localhost ([127.0.0.1]:34263 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1j7yzi-0001pr-TV for submit@debbugs.gnu.org; Sat, 29 Feb 2020 05:05:15 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:59368) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1j7yzg-0001pO-5i for 39799@debbugs.gnu.org; Sat, 29 Feb 2020 05:05:13 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:58699) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1j7yza-00043h-QF; Sat, 29 Feb 2020 05:05:06 -0500 Original-Received: from [176.228.60.248] (port=1463 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1j7yzZ-0005K9-F9; Sat, 29 Feb 2020 05:05:06 -0500 In-reply-to: (message from Mike FABIAN on Sat, 29 Feb 2020 08:59:49 +0100) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:176664 Archived-At: > From: Mike FABIAN > Cc: rpluim@gmail.com, 39799@debbugs.gnu.org > Date: Sat, 29 Feb 2020 08:59:49 +0100 > > Eli Zaretskii さんはかきました: > > > If Gedit selects a font by looking at more than one codepoint (and I'm > > not sure this is how it works in Gedit), then Emacs doesn't work that > > way. > > Yes, Gedit does this somehow with pango. It tries to avoid switching > fonts in places where it would look bad. For example, if you have a > default font supporting only ASCII and then there is a word containing > some non-ASCII character like “grün” it chooses a font containing the > “ü” for the whole word to avoid the “ü” looking out of place. Well, "somehow" is not enough to see whether we have any additional work to do in Emacs, because Emacs also tries to achieve that same goal. There are many different ways to achieve it, though; for example, Emacs will AFAIK by default not even use a font that could support ASCII, but not Latin-1 blocks as the default face's font. What you say about Gedit makes sense in general, but questions immediately pop up: how does Gedit define a "word" (Emacs, as you know, has very a flexible definition that can be controlled from Lisp), how does it "know" that a word like "grün" belongs to the same script (otherwise displaying a character from another script using a different font, as in, say, "grאn" might make sense), etc. IOW, what we need is a detailed description of what Pango does here, and how does Gedit affect that by configuring its default fonts. Only then we can reason about the differences between that and what Emacs does. > > In any case, are these sequences displayed as composed characters? > > Does "C-u C-x =" tell that the base character U+24C2 was composed with > > the following variation selector? According to the setup in > > japanese.el, they should compose, if the font used for U+24C2 also > > supports the variation selectors. > > Yes, it does tell that it was composed with the following character: And the resulting display is what you expect? If not, then I think you need to find a font which supports Emoji presentation of characters such as Ⓜ, and make Emacs use it for those sequences. If you think this Emacs requirement for a capable font is incorrect, I suggest to post a question about this to the HarfBuzz mailing list, harfbuzz@lists.freedesktop.org, maybe HarfBuzz has capabilities in this regard that we somehow don't yet utilize.