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

Previous Next

Package: emacs;

Reported by: talchas <at> talchas.net

Date: Mon, 22 Jan 2018 06:45:02 UTC

Severity: normal

Merged with 22780

Found in versions 25.1.50, 25.3

Full log


View this message in rfc822 format

From: talchas <at> talchas.net
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: talchas <at> talchas.net, Kenichi Handa <handa <at> gnu.org>, 30203 <at> debbugs.gnu.org
Subject: bug#30203: 25.3; without-xft fonts don't properly inherit from default face
Date: Mon, 22 Jan 2018 08:59:52 -0800
Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: talchas <at> 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.




This bug report was last modified 5 years and 221 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.