Hi Laslo
Thanks for giving this a shot!
A comment below.
Laslo Hunhold <dev_AT_frign.de> wrote:
> Dear fellow hackers,
>
> this patch will hopefully resolve the many mails we get on dev_AT_ and
> hackers_AT_ 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
> _AT_@ -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
Received on Tue Apr 23 2019 - 22:08:30 CEST