google / google/fonts

Provide demo strings for OpenType features

Open
#1,539 5 comments 0 reactions 0 assignees View on GitHub
Dominant language
HTML
Stars
20.5k
Forks
2.9k
Avg merge
1d 21h
Merged PRs (30d)
95

Description

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.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.