Re: [hackers] [st] [PATCH] Work around BadLength error by disallowing color fonts
On Wed, Apr 24, 2019 at 09:59:13PM +0200, Laslo Hunhold wrote: > On Wed, 24 Apr 2019 21:47:39 +0200 > Hiltjo Posthuma wrote: > > Dear Hiltjo, > > > I'm not in favor of this. I think this should be fixed upstream. > > > > Now that there has been a release of dwm and dmenu with the > > workaround it should be removed I think. > > > > There is no nice workaround except making the code more ugly. Should > > every project using fontconfig add this stupid workaround? I don't > > think so. One of the things that flow from the UNIX philosophy as I > > see it is solving things at the appropriate layer (or try to). > > > > There have also been reports of FC_COLOR patch "not working", because > > distros (in particular Debian stable, Slackware etc) using 4+ year > > old backported fontconfig versions. FC_COLOR is not known there. > > #define FC_COLOR "color" is a workaround which does not fix anything > > #except make it compile. It will still > > crash there. > > > > The whole concept of colored fonts is anti-suckless and retarded in > > general. > > I agree with your sentiment, but still wanted to open the discussion of > this possibility here. We can't fix the issues upstream, but it's a > real concern that Xft will never be fixed in this regard. After all, > the best course will be to have a real suckless font rendering library > like the one you started working on a while ago. > Regarding st, I also must note that the handholding my patch does might > be a bit too much relative to other suckless projects. > > I sometimes have the impression that the big library makers like > FreeType, HarfBuzz, Pango and so forth want to make you believe that > it's an impossible feat, overflowing you with their set of features, > tweaks, performance hacks and LCD-rendering-tricks. You've shown that > it is possible with much less code, so maybe we should be the ones, as > suckless, to lead the way. Maybe you could make a short write-up on > hackers@ of your results. From what I remember, you tweaked on it for > quite a while, and it could save other collaborators from spending a > lot of time you did on some issues. > > The use of stone-age old libraries in Debian stable, Slackware, Fedora > and others is a sin against human kind and in my opinion one reason why > the Linux desktop never really took off until a few years ago when > other, more bleeding edge distros, entered the playing field. I _never_ > _ever_ saw an example were using old, backported versions was a benefit > over new code. Granted, one should not use the bleeding edge on > production systems, but that's what major and minor versioning is for. > Debian stable discarded minor versions just the same and it takes a lot > of man-hours to preserve this bloody museum of software over there that > could be spent much better on other things! > > With best regards > > Laslo > > -- > Laslo Hunhold It is not a sentiment, this workaround will not be in st. I'm not actively working on this font library anymore. The code is there. I disagree with the version statement, but won't address it, it's too off-topic, so best left out imho. -- Kind regards, Hiltjo signature.asc Description: PGP signature
Re: [hackers] [st] [PATCH] Work around BadLength error by disallowing color fonts
On Thu, Apr 25, 2019, at 07:48, Hiltjo Posthuma wrote: > I'm not in favor of this. I think this should be fixed upstream. > > Now that there has been a release of dwm and dmenu with the workaround it > should be removed I think. > > There is no nice workaround except making the code more ugly. Should every > project using fontconfig add this stupid workaround? I don't think so. One of > the things that flow from the UNIX philosophy as I see it is solving things at > the appropriate layer (or try to). I don't think anyone disagrees with that in principle, but it seems that an upstream fix is not forthcoming, because reasons. A simple workaround is better than a crash. This seems like a good example where practicality should beat purity. pgpP4MnZItxsz.pgp Description: OpenPGP digital signature
Re: [hackers] [st] [PATCH] Work around BadLength error by disallowing color fonts
On Wed, 24 Apr 2019 21:47:39 +0200 Hiltjo Posthuma wrote: Dear Hiltjo, > I'm not in favor of this. I think this should be fixed upstream. > > Now that there has been a release of dwm and dmenu with the > workaround it should be removed I think. > > There is no nice workaround except making the code more ugly. Should > every project using fontconfig add this stupid workaround? I don't > think so. One of the things that flow from the UNIX philosophy as I > see it is solving things at the appropriate layer (or try to). > > There have also been reports of FC_COLOR patch "not working", because > distros (in particular Debian stable, Slackware etc) using 4+ year > old backported fontconfig versions. FC_COLOR is not known there. > #define FC_COLOR "color" is a workaround which does not fix anything > #except make it compile. It will still > crash there. > > The whole concept of colored fonts is anti-suckless and retarded in > general. I agree with your sentiment, but still wanted to open the discussion of this possibility here. We can't fix the issues upstream, but it's a real concern that Xft will never be fixed in this regard. After all, the best course will be to have a real suckless font rendering library like the one you started working on a while ago. Regarding st, I also must note that the handholding my patch does might be a bit too much relative to other suckless projects. I sometimes have the impression that the big library makers like FreeType, HarfBuzz, Pango and so forth want to make you believe that it's an impossible feat, overflowing you with their set of features, tweaks, performance hacks and LCD-rendering-tricks. You've shown that it is possible with much less code, so maybe we should be the ones, as suckless, to lead the way. Maybe you could make a short write-up on hackers@ of your results. From what I remember, you tweaked on it for quite a while, and it could save other collaborators from spending a lot of time you did on some issues. The use of stone-age old libraries in Debian stable, Slackware, Fedora and others is a sin against human kind and in my opinion one reason why the Linux desktop never really took off until a few years ago when other, more bleeding edge distros, entered the playing field. I _never_ _ever_ saw an example were using old, backported versions was a benefit over new code. Granted, one should not use the bleeding edge on production systems, but that's what major and minor versioning is for. Debian stable discarded minor versions just the same and it takes a lot of man-hours to preserve this bloody museum of software over there that could be spent much better on other things! With best regards Laslo -- Laslo Hunhold pgpXyoiSQlRZM.pgp Description: PGP signature
Re: [hackers] [st] [PATCH] Work around BadLength error by disallowing color fonts
On Tue, Apr 23, 2019 at 10:14:32AM +0200, Laslo Hunhold 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
>
> --
> Laslo Hunhold
> From 69cfb2193f5e7bb8dda42b3dc5474e3d04170ad1 Mon Sep 17 00:00:00 2001
> From: Laslo Hunhold
> Date: Tue, 23 Apr 2019 10:02:14 +0200
> Subject: [PATCH] Work around BadLength error by disallowing color fonts
>
> This problem has given us enough trouble on the ML alone and is a
> bug in the Xft library that probably won't ever be fixed.
>
> This change is a port of Anselm's commit to dwm
> (cb3f58ad06993f7ef3a7d8f61468012e2b786cab).
> ---
> LICENSE | 4 ++--
> x.c | 12
> 2 files changed, 14 insertions(+), 2 deletions(-)
>
> diff --git a/LICENSE b/LICENSE
> index c356c39..07518e3 100644
> --- a/LICENSE
> +++ b/LICENSE
> @@ -4,7 +4,7 @@ MIT/X Consortium License
> ?? 2018 Devin J. Pohly
> ?? 2014-2017 Quentin Rameau
> ?? 2009-2012 Aur??lien APTEL
> -?? 2008-2017 Anselm R Garbe
> +?? 2008-2019 Anselm R Garbe
> ?? 2012-2017 Roberto E. Vargas Caballero
> ?? 2012-2016 Christoph Lohmann <20h at r-36 dot net>
> ?? 2013 Eon S. Jeon
> @@ -13,7 +13,7 @@ MIT/X Consortium License
> ?? 2013-2014 Eric Pruitt
> ?? 2013 Michael Forney
> ?? 2013-2014 Markus Teich
> -?? 2014-2015 Laslo Hunhold
> +?? 2014-2019 Laslo Hunhold
>
> Permission is hereby granted, free of charge, to any person obtaining a
> copy of this software and associated documentation files (the "Software"),
> 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, ) == FcResultMatch &&
> iscol) {
> + return 1;
> + }
> +
> /*
>* Manually configure instead of calling XftMatchFont
>* so that we can use the configured pattern for
> --
> 2.21.0
>
I'm not in favor of this. I think this should be fixed upstream.
Now that there has been a release of dwm and dmenu with the workaround it
should be removed I think.
There is no nice workaround except making the code more ugly. Should every
project using fontconfig add this stupid workaround? I don't think so. One of
the things that flow from the UNIX philosophy as I see it is solving things at
the appropriate layer (or try to).
There have also been reports of FC_COLOR patch "not working", because distros
(in
particular Debian stable, Slackware etc) using 4+ year old backported
fontconfig versions. FC_COLOR is not known there. #define FC_COLOR "color" is
a workaround which does not fix anything except make it compile. It will still
crash there.
The whole concept of colored fonts is anti-suckless and retarded in general.
--
Kind regards,
Hiltjo
signature.asc
Description: PGP signature
Re: [hackers] [st] [PATCH] Work around BadLength error by disallowing color fonts
Hi Laslo
Thanks for giving this a shot!
A comment below.
Laslo Hunhold 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, ) == 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
[hackers] [st] [PATCH] Work around BadLength error by disallowing color fonts
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
--
Laslo Hunhold
>From 69cfb2193f5e7bb8dda42b3dc5474e3d04170ad1 Mon Sep 17 00:00:00 2001
From: Laslo Hunhold
Date: Tue, 23 Apr 2019 10:02:14 +0200
Subject: [PATCH] Work around BadLength error by disallowing color fonts
This problem has given us enough trouble on the ML alone and is a
bug in the Xft library that probably won't ever be fixed.
This change is a port of Anselm's commit to dwm
(cb3f58ad06993f7ef3a7d8f61468012e2b786cab).
---
LICENSE | 4 ++--
x.c | 12
2 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/LICENSE b/LICENSE
index c356c39..07518e3 100644
--- a/LICENSE
+++ b/LICENSE
@@ -4,7 +4,7 @@ MIT/X Consortium License
© 2018 Devin J. Pohly
© 2014-2017 Quentin Rameau
© 2009-2012 Aurélien APTEL
-© 2008-2017 Anselm R Garbe
+© 2008-2019 Anselm R Garbe
© 2012-2017 Roberto E. Vargas Caballero
© 2012-2016 Christoph Lohmann <20h at r-36 dot net>
© 2013 Eon S. Jeon
@@ -13,7 +13,7 @@ MIT/X Consortium License
© 2013-2014 Eric Pruitt
© 2013 Michael Forney
© 2013-2014 Markus Teich
-© 2014-2015 Laslo Hunhold
+© 2014-2019 Laslo Hunhold
Permission is hereby granted, free of charge, to any person obtaining a
copy of this software and associated documentation files (the "Software"),
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, ) == FcResultMatch && iscol) {
+ return 1;
+ }
+
/*
* Manually configure instead of calling XftMatchFont
* so that we can use the configured pattern for
--
2.21.0
pgphRfiDcoPen.pgp
Description: PGP signature
