Re: [hackers] [st] [PATCH] Work around BadLength error by disallowing color fonts

From: Hiltjo Posthuma <>
Date: Wed, 24 Apr 2019 23:04:45 +0200

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_AT_ 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,

Received on Wed Apr 24 2019 - 23:04:45 CEST

This archive was generated by hypermail 2.3.0 : Wed Apr 24 2019 - 23:12:26 CEST