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: 3121 bytes --]

At Fri, 11 Feb 2022 09:15:09 +0200, Eli Zaretskii <eliz@gnu.org> wrote:
Subject: Re: bug#53924: 26.1; fontification sometimes fails for some characters despite available glyphs
>
> It might look inconsistent from your POV, but Emacs has its own ideas
> about this, and they are consistent as soon as one understands the
> code and its design ideas.

The inconsistency I'm observing seems to be within Emacs itself, or
perhaps in the way it uses the GTK2 toolkit (gbdfed, also using GTK2,
does not have any problem, either directly on the problem fonts, or via
fetching them from the X11 server).

I probably shouldn't have mentioned Xterm since, as you say, it has an
even more restrictive view of how to manage fonts, and specifically
can't deal with proportional fonts at all.

So Emacs+GTK2 can display some fonts perfectly, but not others, despite
the fact the underlying system (i.e. X11) and its related tools
(e.g. xfontsel, xfd, gbdfed, etc.) can display and find (xlsfonts) all
those fonts with no problem.

There's also nothing whatsoever in any available documentation I can
find which even remotely suggests that what I expect Emacs to do will
not happen for some reason.

If you can point me to any such documentation, that would be excellent.

If not then this is a real bug, though as I've said I'm not sure the bug
is in Emacs -- it could well be some otherwise hidden defect in the
fonts, their encodings, and/or how they are loaded by the X11 server.

I just can't find anything whatsoever, so far, to point responsibility
to anything other than Emacs, and specifically in an Emacs built with
the GTK2 toolkit.

Have you run the function I supply to see how it fares in your
environment with your available font families?


> How can xfontsel know which problems are relevant to Emacs use of
> fonts and Emacs display engine in general?

It doesn't of course -- but it (and the other related tools, including
gbdfed) demonstrates that the font, and its encoding, and the underlying
X11 display engine, are all perfectly happy to load and correctly
display the glyphs for the problem fonts.

What could possibly be different about a font that would lead Emacs+GTK2
to ignore some/all of the available glyphs for the ASCII characters in
that font (but not ignore them in the Emacs+nextstep variant)?

> So maybe what you see is specific to that OS (NetBSD, AFAIU).

I would think that's literally impossible.  The Emacs code is all very
portable (and is indeed running on NetBSD), as is the font handling and
most of the X11 server itself (which is running on macOS) -- the only
thing that's unique in my specific test scenario (the macOS part) is
demonstrably not a problem because it is all perfectly happy to display
all available fonts in all other contexts, both in native macOS as well
as in the X11 server running on it (e.g. Emacs+nextstep in native macOS,
or gbdfed, and all the X11 font tools running on macOS).

--
					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 --]