Provide demo strings for OpenType features

[n8willis]

The GTK+ project is interested in automatically showing demo/sample strings for the OpenType features that are included in a font binary. The use case is rapidly presenting features to the user for a font, such as in a font selector: the demo string could be displayed once with the feature disabled, and next to that, once with the feature enabled, illustrating the difference.

For some features, it is easy to come up with sample strings likely to demonstrate the feature. The onum feature, for example, should almost certainly show the digits 0–9.

But many others are problematic.The liga feature for a Latin font is likely to include and f_i ligature, so the string "fi" might make sense, but there is no way to know in advance if the font contains a non-ligating f or simply does not implement an f_i ligature. Quite a few feature tags are impossible to guess at, such as which swash letters are appropriate examples for an arbitrary font.

The proposed solution we would like to make a case for is to include a short "demo string" for each feature that is present in the font file, and to store those feature/demo-string pairs in the font's meta table.

The meta table allows privately-defined tags in four-character uppercase. The proposal is thus to map OpenType features to meta tags one-to-one: liga becomes LIGA in the meta table, and so on. The value associated with LIGA would then be a Unicode string capable of showcasing the effect of enabling and disabling the corresponding feature.

Not every feature tag makes sense to showcase in this context (the fundamental script-shaping tags being the obvious example). But, for discretionary features and those that offer creative design decisions, it may be more appropriate than guessing or using a generic string.

This usage of meta is comparable to the purpose of the existing, reserved dlng ("design languages") and slng ("supported languages") tags, so we feel it a good fit for the feature, and it does not require any changes to the format.

[n8willis]

Addendum: had a discussion with Sascha Brawer, who pointed out that using the name table might be preferrable for storing demo strings, both because it is geared towards strings anyway and because it would support having multiple demo-strings per feature, one per language ID.

So the concept would then be a meta entry, per feature, that stores a high-order nameID, and each corresponding nameID could host a demo string for the supported language(s).

[davelab6]

I don't believe this metadata belongs in the font, because its life cycle is separate to the font. I believe something more like MusicBrainz would be better.

[rsheeter]

Providing a tool that gives you a set of (feature, activation sequence(s)) for a font makes sense and may be useful in generating test scenarios, specimen pages, etc.

I don't think we'd want to stuff that data into the fonts for our collection but given the tool it would be easy for anyone who wants that to do it.

[felipesanches]

@rsheeter The best-informed actor tends to be the original type-designer who's most certainly prepared to provide sensible strings meant to showcase the actual design intent of a font family. Automated tools can help indeed, but human input would likely be much better.

The challenge, I think, is that there's not much (at least not immediate) reward for the type-designers to provide such samples. If applications displayed nicely these samples in their UI, then designers would be more likely to learn about such strings and their usefulness and thus feel more compelled to put that extra effort, since it could convey a sense of higher quality for their font projects.

But that seems to be a chicken & egg problem...

[n8willis]

I'm not sure I follow the "lifecycle" metaphor, @davelab6 ....

As @felipesanches notes, this is about the designer (or publisher) providing strings that show the application of the actual lookups as they are implemented in the binary. How is the lifecycle of those lookups not the same as the lifecycle of the font binary?

Relying on an automated method is what the GTK+ folks report is not workable in practice. A font-manager app or webpage might be able to see that a font contains a set of chaining lookups for calt, but that alone doesn't help it know whether it's a feature that implements handwriting-like variations for doubled letters, or changes connecting strokes in certain circumstances, or something else. Not without parsing the entire GSUB, and even then stumbling onto an example that's visually informative is trial-and-error.

E.g., whether the particular feature will be best demonstrated with the string "minimum" or the string "bookkeeper" (or, when the font has both Latin and Arabic, that it's "بيت" and not Latin at all) is tightly bound to what's in the binary and that's what the designer knows. When application developers have to guess at constructing those for every feature, they're wasting cycles at least, and might not even find a good option.

As to embedding it in the font binary, the advantage is that it doesn't get separated from the font, regardless of the distribution chain. Having to go request that information from a third-party web service doesn't sound efficient, either. What happens when FeaBrainz shuts down or is unreachable? If it's in meta, it travels with the font.

Don't know if there's a quick solution to the chickeneggery. It may take design-time tooling to really pick up supporters. But this is all really an extension of the idea already specified in sampleTextNameId for cv00-99. Why that was defined solely for cvNN is a historical mystery, I suppose.