From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Suggest installing more fonts? Date: Sat, 17 Oct 2020 15:13:13 +0300 Message-ID: <83a6wlt5ie.fsf@gnu.org> References: <87wnzqa1be.fsf@gnus.org> <83zh4lthv4.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="14907"; mail-complaints-to="usenet@ciao.gmane.io" Cc: larsi@gnus.org, monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Gregory Heytings Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Oct 17 14:13:57 2020 Return-path: Envelope-to: ged-emacs-devel@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 1kTl5w-0003lt-MQ for ged-emacs-devel@m.gmane-mx.org; Sat, 17 Oct 2020 14:13:56 +0200 Original-Received: from localhost ([::1]:56198 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kTl5v-0005lv-Od for ged-emacs-devel@m.gmane-mx.org; Sat, 17 Oct 2020 08:13:55 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:49586) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kTl5H-0005G7-3y for emacs-devel@gnu.org; Sat, 17 Oct 2020 08:13:16 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:54774) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kTl5G-0000JF-Cj; Sat, 17 Oct 2020 08:13:14 -0400 Original-Received: from [176.228.60.248] (port=1972 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1kTl5F-0001nB-OB; Sat, 17 Oct 2020 08:13:14 -0400 In-Reply-To: (message from Gregory Heytings on Sat, 17 Oct 2020 11:21:52 +0000) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:257933 Archived-At: > Date: Sat, 17 Oct 2020 11:21:52 +0000 > From: Gregory Heytings > cc: larsi@gnus.org, monnier@iro.umontreal.ca, emacs-devel@gnu.org > > >> So IMO for these users it would be much better to display characters > >> with a low-resolution font, together with a warning (and perhaps a > >> pointer to a short guide) (as a help-echo and/or in the echo area), > >> instead of a tofu. > > > > Then the problem will become "Emacs uses an ugly font where other apps > > don't", and we are none the wiser. > > _All_ apps have that problem, it is _not_ an Emacs-specific problem. Let's keep the discussion in context, okay? The context was the complaints that Emacs displays tofu where other applications display characters from installed fonts (which aren't GNU Unifont). It is those use cases that I was talking about. Where Emacs behaves no worse than other apps is in a different category. More about that below. > FWIW, here is my solution for Emojis (on Debian, after installing the > fonts-noto-color-emoji package): > > fc-match --format='%{charset}\n' NotoColorEmoji | tr ' ' '\n' | grep '^[^-][^-][^-][^-]' | grep -v '^200d$' | sed 's/^/#x/;s/-/ . #x/;s/^\(#[^#]*#[^#]*\)/!(\1)/;s/^\(.*\)$/(set-fontset-font "fontset-default" \1 "NotoColorEmoji")/' | tr '!' "'" > > This creates 154 calls to "set-fontset-font", and as a result > https://unicode.org/Public/UNIDATA/emoji/emoji-data.txt is displayed > nicely by Emacs. I'm sure you will tell me that you don't like that > solution ;-) But I doubt it is possible to do really better, because > Emojis are scattered across the whole Unicode code space. The Emoji problem was already analyzed and a solution is in the works which will not look anywhere like the above (setting up the fontset is not enough, btw). Let's move on to problems for which we don't yet have a solution, okay? > > IOW, using Unifont is simply a kind of admission of defeat: we don't > > really know why Emacs doesn't find a good font, so we take the easy path > > of providing _some_ font that will always work, albeit show ugly glyphs. > > I see no need to declare defeat, as we have facilities in Emacs to solve > > these problems in a better way, once we understand them. We should > > therefore try to understand the problems better, and once understood, > > solve them properly. > > The meaning of my proposal was, in fact, the exact opposite of an > admission of defeat, it was to make Emacs better in that respect than all > other apps. Displaying a tofu is an admission of defeat, and it's what > all other apps do. Using Unifont is a defeat in the sense that we don't do better by finding a good font. The Unifont "solution" is already in Emacs, see the setting of fontset-default. So if you are willing to settle for Unifont, we already do that. IMO, we should try to find ways to do better than that. > Another example: I have no fonts to display tamil characters on my > computer. Which means every app, including Emacs, displays tamil > characters as a sequence of tofus. I attach three pictures of the same > short tamil text displayed by Emacs, one with its current behavior > (tamil-no-font.png), one if it used Unifont as a fallback > (tamil-unifont.png), and one if a proper tamil font (the Debian package > fonts-lohit-taml) is installed (tamil-good-font.png). I do agree (of > course) that tamil-good-font.png is better than tamil-unifont.png, but I > really can't understand how tamil-no-font.png could be considered better > than tamil-unifont.png. Do you read the Tamil script (I don't)? If not, we should ask someone who does what they think about the Unifont glyphs. (To my un-expert eyes, the right-most glyph looks completely unrecognizable with Unifont, but that's me.) In any case, it is never a bad idea to try find better ways of handling this situation than we already have. For starters, I'm not sure I understand what kinds of situation is it that the user wants to read Tamil text, but the system isn't ready for that wrt installed fonts. When we understand the relevant use case, we might be able to come up with useful features for them. For example, perhaps we should have a command to report on fonts suitable to display a certain script or a certain block of Unicode codepoints -- it should be easy to write such a command, and it could be advertised as something users should run when they are about to start using a new script or range of characters. We could then provide some specific advice in the text displayed by that command if no suitable fonts were found.