Hi Laslo

Thanks for giving this a shot!

A comment below.

Laslo Hunhold <d...@frign.de> wrote:
> Dear fellow hackers,
> 
> this patch will hopefully resolve the many mails we get on dev@ and
> hackers@ regarding crashes of st due to emoji-fonts triggering some
> voodoo-condition in Xft.
> 
> I hope my port of Anselm's change to dwm to st is correct and would
> love to hear feedback.
> 
> With best regards
> 
> Laslo Hunhold
>
> [...]
> 
> diff --git a/x.c b/x.c
> index 5828a3b..074df47 100644
> --- a/x.c
> +++ b/x.c
> @@ -837,12 +837,24 @@ xgeommasktogravity(int mask)
>  int
>  xloadfont(Font *f, FcPattern *pattern)
>  {
> +       FcBool iscol;
>         FcPattern *configured;
>         FcPattern *match;
>         FcResult result;
>         XGlyphInfo extents;
>         int wantattr, haveattr;
> 
> +       /* Do not allow using color fonts. This is a workaround for a 
> BadLength
> +        * error from Xft with color glyphs. Modelled on the Xterm 
> workaround. See
> +        * https://bugzilla.redhat.com/show_bug.cgi?id=1498269
> +        * https://lists.suckless.org/dev/1701/30932.html
> +        * https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=916349
> +        * and lots more all over the internet.
> +        */
> +       if(FcPatternGetBool(pattern, FC_COLOR, 0, &iscol) == FcResultMatch && 
> iscol) {
> +               return 1;
> +       }
> +

From what I can tell, returning 1 in this case won't work because st
calls die() when xloadfont returns non-0 at all call sites. We would
have to load a fallback font instead, I think.

The dwm patch for for this issue [0] also adds this call to choose the
fallback font.

+     FcPatternAddBool(fcpattern, FC_COLOR, FcFalse);

We probably have to do the same in st.


Cheers,

Silvan


[0] 
https://git.suckless.org/libsl/commit/53ebcb48c6b12882c6dbe352ee43c96b2fb01b84.html

Reply via email to