On Tue, Dec 21 2021, Eli Zaretskii wrote: >> From: Yuri D'Elia >> Cc: Dmitry Gutov , monnier@iro.umontreal.ca, >> larsi@gnus.org, emacs-devel@gnu.org >> Date: Tue, 21 Dec 2021 13:27:03 +0100 >> >> The annoying fact is that font selection is called in so many contexts >> it's just time consuming to drill down and/or set a good breakpoint >> condition. > > I usually set a breakpoint in xfaces.c where the face attribute(s) > is/are being changed, and then step into the functions it calls to > select the font. It's a bit slow, since you have a lot to step > through, but it makes sure it's the right calls you are tracing. After looking at this through a couple of times, I came up with the attached patch. When changing the default face, the resulting font name/pattern is stored as a string. Whenever a new frame is created, the string is used to re-open the face again. I guess this is done to support creating frames across different terminal types preserving the closest available font. This is done by calling font_open_by_name, which builds up a font spec again from the stored string (which at this point _should_ be fully specified), then calls the font_open_by_spec. The problem seems that font_open_by_spec is _explicitly_ requesting a normal weight/slant/width. So if multiple candidates were available while enumerating fonts, the regular variant was always picked irregardless of our preference. This used to work before since only a single variant was generally enumerated. In the patch, instead of just resetting/overriding the spec, we just preset a normal variant if the spec is incomplete. I included also the family/foundry in the spec, which can be used during selection instead of blindly ignoring it. This seems to work correctly for me now, however I'm only testing on x11. font_open_by_name is not used in many places aside frame creation. This change seems coherent to me looking at the other calls.