From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?UTF-8?Q?=E0=A4=B8=E0=A4=AE=E0=A5=80=E0=A4=B0_?= =?UTF-8?Q?=E0=A4=B8=E0=A4=BF=E0=A4=82=E0=A4=B9?= Sameer Singh Newsgroups: gmane.emacs.bugs Subject: bug#58184: Faulty font selection for Latin characters Date: Fri, 30 Sep 2022 18:25:31 +0530 Message-ID: References: <831qrtflg3.fsf@gnu.org> <83h70pdqx0.fsf@gnu.org> <83bkqxdnxl.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000f3df5905e9e4821e" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="31052"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 58184@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Sep 30 14:56:32 2022 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 1oeFZ9-0007uh-AY for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 30 Sep 2022 14:56:31 +0200 Original-Received: from localhost ([::1]:40480 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oeFZ7-0005Gt-RZ for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 30 Sep 2022 08:56:29 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:49722) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oeFYh-0005Gc-0z for bug-gnu-emacs@gnu.org; Fri, 30 Sep 2022 08:56:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:41662) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oeFYg-0008Hf-HS for bug-gnu-emacs@gnu.org; Fri, 30 Sep 2022 08:56:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oeFYg-0001mh-79 for bug-gnu-emacs@gnu.org; Fri, 30 Sep 2022 08:56:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: =?UTF-8?Q?=E0=A4=B8=E0=A4=AE=E0=A5=80=E0=A4=B0_?= =?UTF-8?Q?=E0=A4=B8=E0=A4=BF=E0=A4=82=E0=A4=B9?= Sameer Singh Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 30 Sep 2022 12:56:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 58184 X-GNU-PR-Package: emacs Original-Received: via spool by 58184-submit@debbugs.gnu.org id=B58184.16645425506839 (code B ref 58184); Fri, 30 Sep 2022 12:56:02 +0000 Original-Received: (at 58184) by debbugs.gnu.org; 30 Sep 2022 12:55:50 +0000 Original-Received: from localhost ([127.0.0.1]:40740 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oeFYT-0001mE-Q9 for submit@debbugs.gnu.org; Fri, 30 Sep 2022 08:55:50 -0400 Original-Received: from mail-yw1-f181.google.com ([209.85.128.181]:43695) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oeFYS-0001m1-15 for 58184@debbugs.gnu.org; Fri, 30 Sep 2022 08:55:48 -0400 Original-Received: by mail-yw1-f181.google.com with SMTP id 00721157ae682-333a4a5d495so43126147b3.10 for <58184@debbugs.gnu.org>; Fri, 30 Sep 2022 05:55:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=N39BK3F9ExonHzAjec2ECycN3OOiDWkV5O1vDyDodQs=; b=UIQdreNhOwDPxwhC+L8mujozhw9ZwshD1oUBMvPYw9VTzPv2NixaadCydvIukjOCBV SPkrpSANtt6rN56EUwX5/kSa2241pEEQJrUEPDrPxgLJ8qcEgjhhyviz+41rFisKfX0v yXbHz3TK1Sxd6VRD9HYI+23IswjqblB8/wnv3oZvXB9A3bB8E2eTTz9LqUqA9d3IRSb/ 4WDqggu8X3CuwUYdf3OWWnz+FCJDkFPllkBrG4HS98btR1/GNMZW+hALiei6uAynE4lV Y+zSTLq/e86pxDDL1t2MV9p2K4RE1TYGqolcPqbl6bxMH6tOsSNiCCWZL2DBCJBzJLtQ GARA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=N39BK3F9ExonHzAjec2ECycN3OOiDWkV5O1vDyDodQs=; b=WQxyI2YcqVnWvrLQaa5ZJ6my18cRkxoanxg6KvIBleGGzABmOBRNhPsowj62P/y20t P1t+wSJ+rQ1BzgmIy/Q1djgg4xZKXMiLscUbF6XHIpQpB+kuDpKzJTh/c5okKj61QykD gT9QqcyOB/D+IiYy0NKVWK+6DqeTjksy4WSQUyiiA0xgGyFhlvcL7SCu+1rkI3uBanA9 AyQt1tXVTUtacuQiqmeCdAguh+Y9GrBa9Zfh+BD2pYK3GMgzvY2QaBcHf5WsezVIxLqz MrGvEMaSw1UEPRBG64Nx625/D4QYb6DhjXkSwzNOckPJsVWLzy7I2vBp4GmM/5lcdS++ wehA== X-Gm-Message-State: ACrzQf3PKCu+tC9TZTZDiRAJMmTxVGYRBr0qul6EahiERByJngiUqs8O 5aS2EZ1zb91EXdeGzMZjjIMt5tOsDGl+4GuH1DEm69yFu2+h4w== X-Google-Smtp-Source: AMsMyM4hdidXgkYNONbJY2tkRVWiRoOKX1YWia+72+6G+pkWmfqcgPJbwWUPcE0y0scmjgJIskGARU3MkDJ23EiqOxA= X-Received: by 2002:a81:4786:0:b0:348:9544:69a7 with SMTP id u128-20020a814786000000b00348954469a7mr8280623ywa.501.1664542542387; Fri, 30 Sep 2022 05:55:42 -0700 (PDT) In-Reply-To: <83bkqxdnxl.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list 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:244000 Archived-At: --000000000000f3df5905e9e4821e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable It's ok, at least I found the cause of my problem. You can close the bug report. Thanks On Fri, Sep 30, 2022 at 6:22 PM Eli Zaretskii wrote: > > From: =E0=A4=B8=E0=A4=AE=E0=A5=80=E0=A4=B0 =E0=A4=B8=E0=A4=BF=E0=A4=82= =E0=A4=B9 Sameer Singh > > Date: Fri, 30 Sep 2022 18:05:02 +0530 > > Cc: 58184@debbugs.gnu.org > > > > I think I may have found the problem here, JetBrains Mono does not have > the glyphs for these > > "faulty" characters that is why Emacs chooses a different font for them= , > but the thing is these characters > > can still be displayed in the correct font i.e. JetBrains Mono by > combining the glyphs which made up the > > unsupported glyph, this is why hb-view was able to display them I guess= . > > For example entering =E1=B9=83 (#x1e43 Latin small letter m with a dot = below) > will result in it being displayed in a > > different font, > > but entering m=CC=A3 (m + #x323 Combining dot below) will result in it = being > displayed with JetBrains Mono. > > > > So now the question is should these characters be decomposed to better > fit with other characters when the > > font does not support them? > > We cannot do that in the buffer text, because that would mean > modifying the text behind user's back. And doing this in display code > woul mean activating character composition where none should happen. > > I think fonts that don't have glyphs for precomposed characters > shouldn't be used in Emacs for text that could have the codepoints of > those characters. Emacs doesn't pass every character to the shaping > engine, and so the tricks of decomposing characters to get them > displayed are something we cannot be expected to do. Sorry. > --000000000000f3df5905e9e4821e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
It's ok, at least I found the cause of my problem= .
You can close the bug report.

Thanks

On Fri, Sep 30, 2022 at 6:22 PM Eli Zaretskii <eliz@gnu.org> wrote:
> From: =E0=A4=B8=E0=A4=AE=E0=A5=80=E0=A4=B0 = =E0=A4=B8=E0=A4=BF=E0=A4=82=E0=A4=B9 Sameer Singh <lumarzeli30@gmail.com>
> Date: Fri, 30 Sep 2022 18:05:02 +0530
> Cc: 58184@d= ebbugs.gnu.org
>
> I think I may have found the problem here, JetBrains Mono does not hav= e the glyphs for these
> "faulty" characters that is why Emacs chooses a different fo= nt for them, but the thing is these characters
> can still be displayed in the correct font i.e. JetBrains Mono by comb= ining the glyphs which made up the
> unsupported glyph, this is why hb-view was able to display them I gues= s.
> For example entering =E1=B9=83 (#x1e43 Latin small letter m with a dot= below) will result in it being displayed in a
> different font,
> but entering m=CC=A3 (m + #x323 Combining dot below) will result in it= being displayed with JetBrains Mono.
>
> So now the question is should these characters be decomposed to better= fit with other characters when the
> font does not support them?

We cannot do that in the buffer text, because that would mean
modifying the text behind user's back.=C2=A0 And doing this in display = code
woul mean activating character composition where none should happen.

I think fonts that don't have glyphs for precomposed characters
shouldn't be used in Emacs for text that could have the codepoints of those characters.=C2=A0 Emacs doesn't pass every character to the shapi= ng
engine, and so the tricks of decomposing characters to get them
displayed are something we cannot be expected to do.=C2=A0 Sorry.
--000000000000f3df5905e9e4821e--