bug#53924: 26.1; fontification sometimes fails for some characters despite available glyphs

["Greg A. Woods" <woods@robohack.ca>]

[-- Attachment #1: Type: text/plain, Size: 3998 bytes --]

At Wed, 16 Feb 2022 05:36:24 +0200, Eli Zaretskii <eliz@gnu.org> 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" <woods@robohack.ca>
> > 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 <return>
> >
> > 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 <gwoods@acm.org>

Kelowna, BC     +1 250 762-7675           RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com>     Avoncote Farms <woods@avoncote.ca>

[-- Attachment #2: OpenPGP Digital Signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]