bug#30874: 27.0.50; Emacs crashes

[Robert Pluim]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Robert Pluim <rpluim@gmail.com>
>> # Inconsolata is my system default monospace font. Now I insert #x274c :
>> 
>> FontFile /usr/share/fonts/inconsolata/Inconsolata-Regular.ttf/0 matches new
>> Loading file /usr/share/fonts/inconsolata/Inconsolata-Regular.ttf/0
>> FontFile /usr/share/fonts/vlgothic/VL-Gothic-Regular.ttf/0 matches new
>> Loading file /usr/share/fonts/vlgothic/VL-Gothic-Regular.ttf/0
>
> What does "matches new" mean in this log?  And what does "matches
> existing" (below) mean?

"matches new" means "this is the first time Xft has loaded this file",
similarly "matches existing" means "already loaded" (this is Xftʼs
debug, not mine)

>> # I think this means Inconsolata doesnʼt have a glyph for that
>> # codepoint, although I thought the default fontset specified Symbola
>> # for that codepoint (and Symbola is installed), so I donʼt understand
>> # why VL-Gothic is chosen.
>
> Strange indeed.  Does setting use-default-font-for-symbols to a nil
> value change this in any way?

No change. Iʼm beginning to suspect that when we query for the font
that Xft is doing font subsitution for us.

>> # Now I change the fontset, and this time it finds the
>> # emojione-android font :
>>   
>> FontFile /usr/share/fonts/dejavu/DejaVuSansMono.ttf/0 matches new
>> Loading file /usr/share/fonts/dejavu/DejaVuSansMono.ttf/0
>> FontFile /home/rpluim/.local/share/fonts/Inconsolata-Regular.ttf/0 matches 
>> existing (2)
>> FontFile /usr/share/fonts/eosrei-emojione/emojione-android.ttf/0 matches new
>> Loading file /usr/share/fonts/eosrei-emojione/emojione-android.ttf/0
>
> Right.  Does use-default-font-for-symbols change anything in this
> case?

No change

>> > The question now becomes: how do we avoid loading such fonts, at least
>> > when the xftfont back-end is in use?  Is there any alternative except
>> > telling users to "move such fonts out of the way"?
>> 
>> Accoding to that bug, the solution is for the application to 'move
>> away from legacy Xft to fontconfig', whatever that means. I can say
>> that building '--without-xft' is definitely sub-optimal (the buffer
>> text isnʼt scaled, and Emacs doesnʼt find a font to display #x274c).
>

Actually, I think this is because '--without-xft' also disables
Freetype, according to the configure log.

> We already use fontconfig to some extent, and xftfont is AFAIK the
> most advanced font backend we have.  Patches for switching to using
> more of fontconfig's features (assuming it can replace Xft), or for
> switching to a more modern back-end (harfbuzz?) are welcome, but I
> don't hold my breath, as I don't think we have expert on board who
> know enough about complex script shaping to make progress in those
> directions.

As I understand it, we should use fontconfig for finding fonts,
harfbuzz for doing the layout, and cairo to actually render the
result, but this is definitely not my area (plus itʼs Emacs redisplay,
which Iʼm told is scary)

I do note we have an Xft font backend, a freetype one, and a
freetype+cairo one already, which seems excessive.

> As a stopgap, I think we should find a way of ignoring the problematic
> fonts.  Is there some way of detecting them?

You mean short of running ftfont_get_bitmap over every available
codepoint in the font and skipping it if the resulting width * height
is > 4096 [1]?  That would probably detect a problematic font pretty
quickly, but is not very elegant. Also Iʼm not sure we get to
intervene before Xft decides that it needs to fall back to that font.

> AFAICT, we could do that
> either in ftfont_match or in its subroutine ftfont_spec_pattern.  We
> could then pretend that these fonts don't match any font spec, perhaps
> subject to some variable (which would provide a 'fire escape"), which
> I think would fix the problem.

Iʼm hoping that matching on something like !'family emoji' would work,
although Iʼve not figured out how to express that in fontconfig-speak.

> Failing that, we could have a non-empty list in face-ignored-fonts,
> but that would be an inferior solution, and it would take us more time
> to come up with the full list of the problematic fonts.

That works, but it also feels hacky.

Robert

Footnotes:
[1]  If only the calculation were that simple