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).
Font Management
Basic font management, like basic file management, should be part of the operating system. But it’s not enough, so there are font programs, such as Font Book on the Mac, or font-manager and (no longer developed actively) fontmatrix on Linux.
Users need to:
- Install fonts they have downloaded, purchased, made, etc.; this includes seeing a preview of the font before installing it, and perhaps finding detailed information. They need to know whether this will move the original font file, or copy it, or what.
- Uninstall fonts they no longer want (or that caused problems!), again with a preview, and knowing whether this will delete the font file. High quality commercial fonts can cost over US$1,000 so people dont want to lose them.
- Install or uninstall fonts from the operating system (for example, Noto Sans or Linux Libertine) while understanding the implication.
- Manage font directories, disable or enable anti-aliasing and hinting, and other font configuration tasks. This may need to be done on a per-program basis (e.g. you don’t want sub-pixel positioning in a bitmap editor as it will introduce colour fringes!)
Selection
Someone wanting to choose a default font for a text editor, Web browser, drawing program, is typically presented with a list, possibly filtered (e.g. monospace only for a terminal). Usually there’s a preview. With more than a few thousands fonts installed, some of the toolkits reach height limits for menus.
In most cases, choosing a font by family name, weight, style, width, seems like it ought to work, but then you encounter variable fonts. One font file can provide twenty or a hundred or more font instances in the font menu. Google Fonts provides around 3,200 font files; fontconfig by default expands that to over 6,100 fonts, and as the number of variable fonts rises that number will increase.
Some fonts are designed to be used in sets, such as layered fonts for circus-style colour, as well as in families.
So the user needs to choose one or more fonts and possible configure instances.
After selecting a font, the user may also want to select specific characters, including alternate glyphs.
Configuration
OpenType fonts have a number of configurable aspects. Some of these are:
OpenType features, ranging from kerning to stylistic sets, character variants, and language or script specific features;
Colour palettes, where the user can choose a predesigned set of colours or supply their own;
Variation axes, where a font can have multiple “axes” to make a multidimensional coordinate space, such as weight from light to ultra-bold, or optical size, or happiness (axes do not need to come from a fixed list). In some cases (with AVAR2 or FVAR-HOI) the variation can be non-linear;
Alternate characters (often chosen as default by enabling a stylistic set, but not always)
System-level variant characters (Variation Sequences) used to distinguish e.g. different Japanese character sets
Filled (white on black) numerals in circles, or open (black on white), for Chinese and Japanese especially (another feature).
Users need clear ways to make selections, and we need to experiment with user interface. Typing “kern 1, dlig 1, hlig 1, aalt 0, ss12” into a dialogue box is not ideal, but neither is a dialogue box with a couple of dozen or more checkboxes with mysterious jargon-filled labels.
Once a user has selected a combination of features, this needs to be stored in a way it can be used and returned to later. OpenOffice used to use a URI-style syntax for this, for example, and now uses a colon, e.g. :hist for historical forms, visible in the active font name.
Searching
Once you’ve installed some fonts, likely you want to use them! Some reasonable questions software can answer might include
which fonts have a c_t ligature and the long s glyph?
which fonts will work for Vietnamese text? Chinese? English and French?
which fonts have an optical size axis?
As with a file manager or photograph or music manager, users might want to tag individual fonts (or fontinstances!) and search by tags. People might want to share tags, and system-packaged fonts could even include suggested tags, perhaps.
You might want to see fonts only under a specific folder, or only with a specific tag (or without it, or without any tags), or show only colour or variable fonts.
Who cares?
The people who need more advanced font support are our target users in libre graphics. It’s us. But also, even people using a word processor may need stylistic sets or language features.
LibreOffice supports some of these features; so does Inkscape. Scribus seems to have limited support.
Blender and GIMP do not have built-in support for OpenType features today (theres a gegl plug-in for GIMP but it does not have a happy user interface). Neither does Krita (which also seems to go wrong today if a font has a space in its name, and has no font previews in its font chooser).
Quite a few programs go wrong if two fonts are distinguished by something other than the CSS 2.1 family + weight + width triple, but in graphic design this is common. GIMP now copes with this case, but it was a lot of work.
Scribus can support PostScript Type 1 fonts complete with Expert Sets, which makes sense because a lot of people bought them, and there were a lot of free fonts in that format. Harfbuzz no longer supports loading them, along with bitmap fonts, but supports them with a FreeType wrapper. So people contact us to say their fonts don’t all work.
So there’s a lot that could still be done. There’s nothing wrong with being a barefoot orphan step-shild, but let’s give fonts some loving.
Ups and Downs
Possible downsides of a Desktop Service
It’s more work up front than improving just GIMP (but it helps mroe people, if more projects are on-board)
It introduces a new possible point of failure, if the service is not running.
We need to make sure the desktop copes with a separate program providing a utility window; GIMP plug-ins already do this, to some extent.
Security: the font server must not gleefully share commercially-licenced fonts across the network!
Some Possible Upsides
If we do get other projects on board, the users benefit from improved font support;
A font cache/database that records glyph sets can easily be larger than a gigabyte: enough data that there’s benefit in sharing. Fontconfig does not cache this much data.
There can be multiple user interfaces (e.g. for GNOME, KDE, others) and even command-line clients. We don’t have to write them all if we describe a protocol!
When I’ve talked to users, they want better font support. When I’ve talked to application developers, they do too, but the expertise is very specialized.
Is this a sensible proposition?
No comments:
Post a Comment