bug#30203: 25.3; without-xft fonts don't properly inherit from default face

[talchas@talchas.net]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: talchas@talchas.net
>> Date: Sun, 21 Jan 2018 21:23:20 -0800
>> 
>> When built without xft, faces that specify weight such as bold don't
>> take their family from the default face if it doesn't match weight.
>> 
>> You can see this with:
>> emacs -Q
>> (set-frame-font "-xos4-terminus-medium-r-normal--14-*-72-72-c-80-iso10646-1")
>> 
>> and look at the mode line buffer display - on my system it is
>> -misc-fixed-... according to dump-face. This still occurs on git HEAD
>> (b3fb0d47c158cb0d1acdce5008628e1d1a337bbb) as well as the system 25.3 below.
>> 
>> When built with xft this does not occur (still selected via the X font
>> name), and neither does it on 24.5. The proximate cause of the
>> regression appears to be bf0d3f76dcfe7881cb3058169b51cf6602fdcdcb,
>> reversing the
>> 
>> -	  = font_load_for_lface (f, attrs, attrs[LFACE_FONT_INDEX]);
>> +	  = font_load_for_lface (f, attrs, Ffont_spec (0, NULL));
>> 
>> gives the old behavior despite --without-xft. Given that xft is fine
>> on 25.3, there presumably is some more correct fix to font selection.
>
> That change was made to fix two bugs, whose numbers are mentioned in
> the log entry and in the discussion of the bug.  Can you try
> reproducing those bugs in the build without xft?  If those bugs only
> happen with xft, then the fix is easy.  Otherwise, we will have to
> investigate more thoroughly.
>
> Thanks.

Unfortunately not, reverting that hunk goes from a very thin space to a
large missing-character symbol, and reverting the patch entirely just
gives a full space again.