1. 20
  1.  

  2. 4

    These releases are the last ones that contain Xft support, which will be removed in the releases to follow. The Xft mess has to be retired in favour for plain old Xfonts.

    Curious. There’s a little bit of info available on some other pages:

    https://suckless.org/project_ideas/

    Suckless font rendering library

    There is libdrw in suckless now, which still uses xft and fontconfig. Fontconfig and xft are ugly and require too much internal knowledge to be useful. The next logical layer evolved as pango and cairo. Both of course added HTML formatting and vector drawing. This is not needed to simply draw some text somewhere. And this is what a suckless font rendering library should do: Give it a font string and render at some position the given font without having to care about font specifics.

    Also http://wiki.bitbinary.com/index.php/Dmenu_Xft

    I’m not sure if X11 can handle ttf fonts on its own, or if it’s limited to things like ppf. Either way it probably won’t cause me issues with how I use dmenu, I’m not too caring about the font in it as long as it’s not blurry.

    1. 6

      I’ve written a bit on that topic if it interests you:

      And yeah, I agree, this stuff requires too much internal knowledge.

      1. 4

        These releases are the last ones that contain Xft support, which will be removed in the releases to follow. The Xft mess has to be retired in favour for plain old Xfonts.

        This is a mistake. Not because XFT is good, but because X11 fonts are terrible. It’s possible to write a better font rendering library than XFT: The XRender font rendering bits are agnostic to what library you use to draw, so it’s not particularly hard to slot in a different way of rendering your fonts.

        1. 3

          Xorg learned to use TTF fonts many years ago, but the core X11 font APIs only support 1-bit-per-pixel images. That’s probably fine if you’re using properly-hinted early-90s TTFs designed for System 7 or Windows 3.1, but most fonts these days assume some level of anti-aliasing. I’m not sure, but I’m guessing core fonts probably also don’t support kerning or Arabic/Thai/Devanagari/etc. either.

          1. 1

            X.org has no direct TTF handling. The Xrender X11 extension can draw ARGB glyphs, and that’s it.

            1. 1

              It certainly does:

              $ mkfontscale ~/.local/share/fonts
              $ mkfontdir ~/.local/share/fonts
              $ xset fp+ ~/.local/share/fonts
              $ xlsfonts | grep "microsoft-segoe ui.*iso10646" | head -5
              -microsoft-segoe ui light-light-r-normal--0-0-0-0-p-0-iso10646-1
              -microsoft-segoe ui semibold-semibold-r-normal--0-0-0-0-p-0-iso10646-1
              -microsoft-segoe ui symbol-medium-r-normal--0-0-0-0-p-0-iso10646-1
              -microsoft-segoe ui-bold-i-normal--0-0-0-0-p-0-iso10646-1
              -microsoft-segoe ui-bold-r-normal--0-0-0-0-p-0-iso10646-1
              

              …but like I said, it only handles 1-bit-per-pixel glyphs, so you don’t get anti-aliasing.

              1. 1

                Interesting, since it’s Microsoft Segoe I’ll assume those are not simply embedded bitmaps. What is it for? The older Microsoft fonts? I’d expect many more problems than just antialiasing, TTF is more complex than the core protocol’s model, although not as much as OTF.

                Edit: I understood your original comment as claiming that it has some kind of more sophisticated support, although the bitmap rendering is new to me.

                1. 1

                  I don’t know that it’s for anything in particular. It’s the usual story: lots of people wanted to use TrueType fonts on X11, one group of people decided the only practical solution was to build TTF support into the existing model, so it would work with all existing software, while a different group invented a whole new graphics model (XRender) and font API (Xft) and demand that everyone in the world update their applications to use it.

                  Surprisingly enough, the boil-the-ocean approach actually worked out.

        2. 3

          For those curious, the move away from Xft seems to have been motivated by this pervasive Xft bug:

          Apparently color fonts would cause a Xft to encounter an X protocol error. This is fixed in new releases but seems to have been broken for a while.

          1. 2

            This is fixed in new releases but seems to have been broken for a while.

            It’s not fixed in Xft AFAIK, and in dwm/dmenu it’s “fixed” by just never using a font that has the color property set (which is of course not really a fix).

          2. 1

            I’m really curious. Who does not use Xft nowadays?

            1. 3

              Lots of things? You can use freetype directly if you do your own rendering. Or if you go the pango route, it mostly does the same thing without actually linking Xft. All the shiny new GPU accelerated terminals are probably skipping Xft.

              1. 3

                What is a GPU-accelerated terminal for?

                1. 2

                  Fast display refresh with less CPU use, mostly.

                  1. 1

                    The only thing I can think of is cool-retro-term. Otherwise: I can’t see why software rendering wouldn’t be simpler.

                    As it is I can’t stand many “modern” terms. My urxvt already feels slow (hopefully only due to my screen and keyboard), when I try a more flashy (read: blurrier default fonts >:D) term I tend to dislike the extra delay.

                    Of course I might be imagining all of this. But I swear I feel the frames. Time for double-blind termination?