bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#70989: 29.3; Calling isearch-forward when using Unifont throws error


From: Eli Zaretskii
Subject: bug#70989: 29.3; Calling isearch-forward when using Unifont throws error "Invalid font name"
Date: Sun, 19 May 2024 10:49:58 +0300

> From: Po Lu <luangruo@yahoo.com>
> Cc: me@rodrigomorales.site,  70989@debbugs.gnu.org
> Date: Sun, 19 May 2024 15:37:09 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > What I see there is the call to fond_intern_prop, and if the result is
> > accepted by font_style_to_value as a valid value of FONT_WIDTH_INDEX,
> > it is returned.  But "Sans-Serif" is not supposed to be a valid width
> > of a font, so I'm confused.
> 
> Where does FONT_WIDTH_INDEX come into play?

Inside get_adstyle_property:

  adstyle = font_intern_prop (str, end - str, 1);
  if (font_style_to_value (FONT_WIDTH_INDEX, adstyle, 0) >= 0)
    return Qnil;
  return adstyle;

> The attribute responsible is FONT_ADSTYLE_INDEX, which is set to
> "Sans-Serif" by:
> 
>        font. */
>       FT_Face ft_face;
> 
>       ASET (entity, FONT_ADSTYLE_INDEX, get_adstyle_property (p));
>       if ((ft_library || FT_Init_FreeType (&ft_library) == 0)
> 
> in ftfont_pattern_entity.  The XLFD generated from a font with such an
> adstyle is not parsable, the character `-' being the field separator in
> XLFDs, and gives rise to parser errors such as Rodrigo encountered when
> I-search, by proxy, attempted to deconstruct the XLFD back into a font
> spec.

Yes, I understand all that.  That was not my question.

So what is the patch you'd propose.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]