So, after my last blog post, I ended up taking another few months to get the fonts branch just right, but now we have font resource that can be tagged, filtered and searched upon.
After that, I needed my next text editing project to be a bit more manageable. Given that I had already made some head start on it at the beginning of last year, I continued with UI for the OpenType features.
OpenType Features
Usually, OpenType features are explained away as “that’s for ligatures and stuff”, which, while not incorrect, is maybe a little simple. “It enables advanced typographic features” is a little more correct, but it makes OpenType feature support sound less rudimentary than it really is these days.
What might be more clear is to think of a font file as a mapping between input characters and their glyphs. This is fine for simple Latin. But what if you want to show Arabic connected? Well, then you need a second table to keep track of the glyphs for start, middle and end of a word, and substitute the correct glyph as necessary.
Or maybe you want to have kerning, so that A and V nest into each other nicely. Another table for that then, that keeps track of the position adjustment between two consecutive glyphs.
How about small caps? Substitution table. Dynamically placing diacritics? Positioning table. Cyrillic has different glyph traditions in Serbia and Bulgaria, similarly for Han script use in East-Asia: Substitution table. Han script is usually typeset in mono space, but when two brackets follow one another, they often have extraneous white space that should be removed: Positioning table. These are all OpenType features.
The more you look into it, the more it becomes clear that if you want your text layout to support more than plain English, you will need to allow these extra tables to be used and read through. This is in short what Harfbuzz does for us. You can enable and disable these features by taking their name (A 4 letter tag), and indicating to Harfbuzz you want them enabled for a given section by sending a number (0 for off, 1 for on… and 2, 3, 4, […] 256 for indicating which alternate you’d like if the font has multiple alternates available for that feature).
Some of these features are enabled by default, and the basic text layout will process them just fine. However, others are optional, and within CSS all of them can be turned off and on at the typesetters’ wish. Which brings us to the widgets.
CSS font variants
There’s two types of CSS opentype toggles. The first of these are the font-variants, which have a somewhat confusing name in this day and age of OpenType variable fonts, but at the time they were named font-variants were limited to Small Caps, and expected to be separate font files.
The font-variant features more of a guidance suggestion, meaning that you turn them on or off for a piece of text, unrelated to whether the current font actually supports the feature in question. The idea being that you could set a different font elsewhere in the text, and that if this font supports those features, they could be controlled this way.
This means that the UI for these features is somewhat straight forward and unopinionated, being a collection of drop-downs and check boxes. I renamed them “glyphs:” in the UI to avoid confusion with Variable fonts, which is also possible because the majority of them represented which glyphs are being used.
CSS Font Feature Settings and the Glyph Palette
font-variants only cover the most common features, and as of writing, there’s over 120 registered OpenType feature tags. CSS allows controlling this via the second type of properly “font-feature-settings”. A property that wants you to be very specific about which tag you want to enable, and whether you want to have it not just enabled, but also which sub index of the feature you would like to enable.
Now, there’s a bit of a problem here: 120 features is a bit much. Furthermore, two of those registered features, Character Variants and Stylistic Sets, are registered 99 and 20 times respectively, meaning the total is closer to over 230 features. And, further furthermore, fonts may have custom OpenType feature tags.
And that’s not the only problem: Access All Alternates, Stylistic Alternates and Stylistic Sets are very common features, but the way they are configured in CSS as a font-variant feature is somewhat complex, and to have each manually enabled inside the OpenType Features widget is going to feel very clunky for artists.
For these reasons, I ended up building two controls for this CSS property. A main widget for the text property docker that allows artists to enable and disable any OpenType feature that can be found inside the font, and the second being a glyph palette, that allows artists to select alternate glyphs.
The glyph palette was actually made first, so lets go over that. It is in effect a character selection map that allows artists to select alternates to the current glyph or to any glyph inside the font. Filtering can be done with Unicode blocks and search.
It uses KoFontGlyphModel, a QAbstractItemModel, that collects all the available characters inside the font, as well as their Unicode variations (Unicode variations are an extra code point added behind a character to indicate it needs to be a specific version of that glyph. It’s main use is to ensure people’s names are written with the correct glyph variant).
It then takes the locale of the text, and uses those to go over the OpenType tables with Harfbuzz. The locale of the text, or “text language” is necessary because some OpenType features are only available for certain locales. Furthermore, the aforementioned Character Variants and Stylistic Sets may have been named inside the font, meaning that it also takes the interface languages to get the correct name for the current localization of Krita.
Of course, using these alternate names means we need default names first. Which is why I also spend some time on creating a factory where each known OpenType tag is stored with its proper name from the official registry and a hand written summary of the feature for the tool tip. These can now be localized.
Then when we have the feature, we go over the glyphs marked by the table and if that glyph coheres with a Unicode code point, add the table as a potential sub glyph for that Unicode value.
Now here another problem rears its head: We need to know which glyph coheres with which Unicode code point, and while for basic values that isn’t a problem, it is when decomposition comes into play.
Decomposition in this case, is a feature that allows for replacing a given glyph with two other glyphs. A reverse ligature, if you will. It is frequently used to match Unicode decomposition: Ä according to Unicode can be decomposed into A (U+0041) and ◌̈ (U+0308, combining diaeresis). So then, the glyph for Ä can be decomposed into those two glyphs. Afterwards, OpenType allows positioning that diaeresis accurately with the mark positioning feature. This is useful, because we can then take that A glyph, and use things like the Small Caps feature, or a Stylistic Set to turn it into a small A or a decorative A, and as long as these alternate glyphs have been configured for mark positioning, they’ll by themselves support Ä.
So that’s pretty neat. But the problem is that Harfbuzz doesn’t provide enough information for me to discover how a glyph gets decomposed. Meaning that for fonts that are structured this way, I can’t tell whether style sets or the like can be applied to these glyphs, so these don’t show up in the character map. I have a similar problem with ligatures, but that is also compounded by having trouble with the user interface.
For the glyph palette, the way you use it is either by using the glyph alternates, where double clicking one will replace the current grapheme (that’s a set of Unicode values that is often treated as the smallest editable chunk of text) with one that either has the appropriate Unicode variation selectors attached, or one that has the appropriate OpenType features enabled.
The other option is to use the character map, which is much like character maps in other software, allowing you to scroll over all available Unicode values in a font, and sorting them by Unicode block, or searching them. Clicking on a glyph with variants ops out a context menu with the glyph alternates.
The glyph palette itself is written with QML, but because the rest of Krita is not in QML, it is embedded into a QQuickWidget, that is inside a QDialog, which in turn means the context menu needed to be inside a QQuickWidget inside a QPopup, because QQuickWidget will clip any QML pop-up items. QML side, we use DelegateModel to show the child indices of a given character map index.
I’m not sure yet how ligatures would be handled here, maybe list them for each glyph, or maybe have a separate model that shows up underneath the glyph alternates and only shows for the current text. There’s also the fact that stylistic alts and the like can apply to ligatures, so that’s another thing to consider. A similar issue is with emoji zero-width-joiner sequences. This is stuff like “fireman + woman + Fitzpatrick skin tone modifier 5” = 👩🏿🚒 . This is typically implemented as a kind of ligature as well, and while Unicode keeps a list of these, I’d prefer to get them from the font.
For the “OpenType features” control in the text properties docker, we reuse the glyph model, but this time its only to figure out which features are available in the font. Because CSS allows for font fallback, we only do this for the first font, but also allow setting any other officially registered OpenType feature on or off. It also shows a sample for the given feature. This widget is mostly useful for the stylistic sets and the positioning features.
Speed-ups
Now, setting up the glyph model can get quite slow, so some trade-offs were established:
- The glyph palette right now only shows a handful of substitution features, to avoid slowing down initialization. These also decide the sample depicted in the OpenType features drop down.
- When a sample is retrieved, it is limited to the first 6 entries. This should be good enough, because the main purpose is to indicate something is going to happen when selecting this feature.
- The QQuickPaintedItem that draws the glyph uses our text layout under the hood, which on one hand is good: this means we always draw something we can show in our text layout. But at the other end, we had to disable some conveniences, like the dynamic fallback (possible because we always know if an input text can be rendered), as well as disabling automatic relayout.
Final Thoughts
One of the things that struck me when writing the original svg text layout post a few years back is that a decade ago, you’d really boast about your OpenType support, but nowadays, OpenType support is so rudimentary, it didn’t make sense to dwell on it in that post. This might also be a consequence by how easy Harfbuzz makes using OpenType these days.
That meant I really wanted to get the UI for this feature nice. There was a big post over a decade ago by a UI designer doing UI for free software, where he went into extensive detail about how most software implementing controls for OpenType features is really bad at communicating whether the feature does anything. I think I managed to somewhat get that part working right.
Still, the glyph palette could use more love, and I really need to sit down for the whole ligature UI issue. I’m pretty happy with it none the less, and it is very hackable, meaning that it doesn’t necessarily need to be me personally improving it.
I do need to really get going on that language selector though…
Appendix
About the font scanning code
The code for retrieving the OpenType tables was largely based on Inkscape’s, and then extended. Inkscape doesn’t test on language, and only tests for substitution features, while we test on both substitution and positioning features. Similarly, Inkscape’s was written in a time when Harfbuzz could only give information about whether a feature could be turned only on or off, but not whether it had multiple alternates, so it is not yet able to do that.
Of interest is that Inkscape does show a few ligatures, but the only reason those are visible is that there’s a handful of ligatures that are encoded into Unicode in the “Alphabetic Presentation Forms” block. Fonts that implement ligatures tend to also setup these Unicode values, but this is not self-evident, which is why I’d prefer not doing this.
(As a random factoid: Adobe’s Smart Quote feature will use these Unicode encoded ligatures when the font isn’t able to provide them via OpenType.)
I did manage to get ligature samples by simply testing every combination of glyphs that Harfbuzz could tell me were probably relevant to a given table, but this was slow, leading to a 5~ second initialization time on a feature heavy font like Junicode. Maybe the glyph model code can be at some point modified to allow incremental loading, though that wouldn’t provide me a quick sample text in the text properties docker…
Shaping Technology
I feel I should probably mention that OpenType isn’t the only technology that provides shaping. Apple’s Advanced Typography Tables (ATT) and the Graphite shaping language are existing alternatives, but OpenType is far more popular than either, and the CSS working group doesn’t give much guidance on how to use anything but OpenType.
Widgets and Items
Qt currently has two UI toolkits: QML and QWidget. The former uses the terminology “Item” instead of “Widget” to refer to UI controls. I find this somewhat difficult to get used to, so when I don’t prepend a widget name with Q, assume that I mean a generic UI control. I think most people never even consider what the different UI bits are called, so usually it isn’t a problem.
