Fonts Across the Libre Desktop: Design and Graphics Focus

Today, each application, and each toolkit, offers font selection. But fonts have become gradualy more complex, and none of the interfaces seem really excellent. None of the libre graphics programs support the range of font features avaiable in newer or more “mainstream” commercial software such as Photoshop or Figma. It’s not a race, we dont have to copy other software, but the additional complexity of fonts, and OpenType in particular, was added to meet real needs that we can’t easily serve today.

Desktop packaging systems were not designed for packaging individual fonts (and users end up searching 100,000 packages without previews).

We could improve things one program at a time (I originally wanted to start with GIMP) but that leaves the user frustrated.

We could improve one toolkit at a time, such as Gtk or Qt.

Or we could make a desktop-wide service that any toolkit could use, and that’s client-agnostic, so people could write multiple font tools. That way, we could maybe pool our knowledge, too.

This proposal is to see how far we can plausibly take the idea of a desktop font service for font management, selection, configuration, searching. Perhaps the service could sit on top of dbus, with a font client being started automatically by the desktop (dbus is cross-platform).

vi and emacs

Years ago as an undergraduate I spent a holiday working for a CAD/CAM software firm and used emacs there. The alternative was an ancient line editor on PR1MOS... so I got pretty used to emacs.

When I got back to University I was for a while a convert. It meant using the department's VAX in the evening, because emacs was banned in busy hours (it used to many system resources).

One day I was with some friends and happened on an insight that a block of C code should be in a loop. I logged in but, not wanting to keep people waiting, used vi to edit the code. There was already an if statement and I just needed to indent the block, so withot thinking I used the vi command >% to do that.

Afterwards I reflected. I had never indented a block using >% before. The reason I knew the command was not that I'd memorized thousands of weird keystrokes in case I ever needed them. It was because > is the vi command to indent by one tab stop, and % means from here to the matching bracket. I knew both of those separately and could do, for example, >L to indent every line from the current one to the bottom of the screen, or >1G to indent from here back to the start of a file, and I knew y% to yank (copy) from here to matching bracket, d% to delete, so >% just came naturally. It's a language, verb noun.

If I’d needed to do the same thing in emacs I'd have probably researched whether there was a command for it - not impossible but this was James Gosling’s emacs in 1983 or so, and it was still relatively minimal. When there wasn't, I'd have written a LISP function, documented it, added it to my personal library, bound it to a key, and, by this time, would have entirely forgotten why I wanted it.

For me, the simple clear language means I don’t need to think about editing, I can just do it. But maybe it’s more like the “Unix Philosophy” of having distinct commands that one can combine, rather than a few giant applications that don’t interact with each other, the dominant design pattern at the time.

It’s not about one being better than another, because people are individuals and different tools have different strengths and weaknesses for different people. You do have to learn a language with vi, and understand that it’s a language rather than just a set of weird and arbitrary commands, so the initial learning curve is much steeper than for, say, Windows Notepad. For me it was well worth it.