Subject: bug#37473: 27.0.50; antialias setting is not preserved by, inheriting

From: Eli Zaretskii <[email-masked]>
Date: Thu, 30 Jun 2022 09:17:07 +0300

Ping!  Kenichi, could you please chime in on this issue and help us
resolve it?

> Date: Mon, 20 Jun 2022 17:11:49 +0300
> From: Eli Zaretskii <[email-masked]>
> Cc: [email-masked], [email-masked],
>  Stefan Monnier <[email-masked]>
> 
> > Cc: [email-masked], [email-masked], [email-masked], [email-masked]
> > Date: Mon, 20 Jun 2022 16:37:32 +0300
> > From: Eli Zaretskii <[email-masked]>
> > 
> > > From: Po Lu <[email-masked]>
> > > Cc: [email-masked],  [email-masked],  [email-masked],  [email-masked]
> > > Date: Mon, 20 Jun 2022 21:20:09 +0800
> > > 
> > > Eli Zaretskii <[email-masked]> writes:
> > > 
> > > > ??? The original bug report talked about antialiasing, but it didn't
> > > > say that other attributes in the :extra property don't exhibit the
> > > > same issue.
> > > 
> > > They might, but apparently :antialias is the only one to have caused
> > > enough of a problem for someone to open a bug report.
> > > 
> > > I guess copying the entire extras alist would work too, if that's what
> > > you would prefer.
> > 
> > Yes, I think that's what we should do, at least as long as the
> > solution is based on this technique.
> 
> Actually, why not go to the code we had in realize_gui_face before
> commit bf0d3f7?  The problem described in bug#1793, which led to that
> commit, only happens if one uses a specific (misc-fixed) font family,
> not for the usual default fonts used by Emacs, and I'm not sure what's
> described there is a bug at all.  At least for the purposes of
> text-scale-adjust, it makes no sense to ignore the
> foundry/family/adstyle of the original font, because we _want_ the
> same (or very similar) font, just of a different size.
> 
> And likely in other use cases: if the :font attribute of a face
> specifies some font properties, we want to keep them all, not
> arbitrarily to ignore some of them.  And definitely catering to an
> obscure use case such as the one cited in bug#17973 is NOT a good
> reason to make such radical changes in face-realization behavior.
> 
> So I think we should just back out that part of commit bf0d3f7, and if
> we decide that this causes bug#17973 in too many situations we care
> about, I'd rather find a kludge for that specific case than do that
> for every face realization.
> 
> Specifically, I propose the change for the master branch.  Any
> objections?
> 
> diff --git a/src/xfaces.c b/src/xfaces.c
> index f70fe87..10bde40 100644
> --- a/src/xfaces.c
> +++ b/src/xfaces.c
> @@ -5952,28 +5952,8 @@ realize_gui_face (struct face_cache *cache, Lisp_Object attrs[LFACE_VECTOR_SIZE]
>  	    emacs_abort ();
>  	}
>        if (! FONT_OBJECT_P (attrs[LFACE_FONT_INDEX]))
> -	{
> -	  /* We want attrs to allow overriding most elements in the
> -	     spec (IOW, to start out as an empty font spec), but
> -	     preserve the antialiasing attribute.  (bug#17973,
> -	     bug#37473).  */
> -	  temp_spec = Ffont_spec (0, NULL);
> -	  temp_extra = AREF (attrs[LFACE_FONT_INDEX],
> -			     FONT_EXTRA_INDEX);
> -	  /* If `:antialias' wasn't specified, keep it unspecified
> -	     instead of changing it to nil.  */
> -
> -	  if (CONSP (temp_extra))
> -	    antialias = Fassq (QCantialias, temp_extra);
> -	  else
> -	    antialias = Qnil;
> -
> -	  if (FONTP (attrs[LFACE_FONT_INDEX]) && !NILP (antialias))
> -	    Ffont_put (temp_spec, QCantialias, Fcdr (antialias));
> -
> -	  attrs[LFACE_FONT_INDEX]
> -	    = font_load_for_lface (f, attrs, temp_spec);
> -	}
> +	attrs[LFACE_FONT_INDEX]
> +	  = font_load_for_lface (f, attrs, attrs[LFACE_FONT_INDEX]);
>        if (FONT_OBJECT_P (attrs[LFACE_FONT_INDEX]))
>  	{
>  	  face->font = XFONT_OBJECT (attrs[LFACE_FONT_INDEX]);
> 
> 
> 
>