At Wed, 16 Feb 2022 05:36:24 +0200, Eli Zaretskii wrote: Subject: Re: bug#53924: 26.1; fontification sometimes fails for some characters despite available glyphs > > > Date: Tue, 15 Feb 2022 18:32:23 -0800 > > From: "Greg A. Woods" > > CC: GNU Emacs Bug Reports <53924@debbugs.gnu.org> > > > > Hopefully this message encodes properly, it should be text/plain, in > > the ISO10646-1 charset, with BASE64 encoding. > > > > Run "emacs -q" in the debugger, switch to the *scratch* buffer and > > insert the forms below, then: > > > > M-x eval-buffer > > > > Switch to the new *Font Families* buffer and scroll slowly through it. > > Depending on how many fonts you have installed, and how, and what kind > > of resources your system(s) have, this could take quite a long time. > > > > If that doesn't trigger a crash try going back to the beginning, > > increase the text scale with C-u C-x C-+ and scroll through again. > > > > This seems to reliably cause the crash for me, at least with the Git > > master version I have built using the lucid toolkit.. > > Like I said before: please try to figure out which font causes the > crashes, and post a recipe with that font alone. Otherwise, trying to > reproduce this is a huge waste of time, because the results depend > critically on the fonts actually installed on the system. Sorry, I really can't be bothered to waste more of my own time on this aspect of the problem until I know that you, or someone else, has at least tried the very simple test I've provided. It is really very simple, and it really would be useful if someone other than myself, in my limited test environment, can try it out to see what happens. I've even already identified suspect fonts (e.g. in comments in the code I supplied), and if you don't have them google will almost instantly tell you where you can find them to try for yourself. Any crash is very bad of course, but, the main issue central to this bug report remains, which is the question of why Emacs chooses to use the frame's default font for ASCII characters when displaying some fonts but not others (even simultaneously with both fonts rendered in the same frame), even when all fonts appear (via other tools) to have all necessary glyphs for all these same ASCII characters. The algorithms for this choice do not seem to be very well documented outside of the code itself, and the code is extremely convoluted and non-modular. If there's something "odd" or otherwise wrong/different with the fonts that don't display properly, that's fine, I just want to know exactly what the problem is. However without knowing even what could be wrong it's impossible to identify and perhaps fix or otherwise change these differences using other tools. My only other available test environment is native macOS with Emacs using the "nextstep" toolkit. There it seems Emacs has very a different and quite opposite "opinion" about ASCII vs. other Unicode characters (than under X11) -- the macOS native version is happy to show empty boxes for ASCII characters if the font has none, but it always cobbles together other Unicode glyphs, e.g. in my sample text, from a variety of other fonts if the requested font has no glyphs for them. I have not seen any crashes in the native macOS environment either. Anyway this X11 font display issue seems to be central to Emacs' ability to accurately display things like web pages and other formatted documents in a more WYSIWYG manner. It also doesn't make a very good demo if Emacs can't even show samples of all available fonts in a given environment. The crash, which for example might be triggered by an attempt to use one of the more problematic fonts in displaying a formatted web page or document, is still secondary to my main issue. -- Greg A. Woods Kelowna, BC +1 250 762-7675 RoboHack Planix, Inc. Avoncote Farms