New OT discretionary feature: Legible forms (legi / lgbl)

[twardoch]

I’d like to propose registering a new user-discretionary (off by default) feature “Legible forms” (draft tag: legi or lgbl).

The feature provides a standardized way for font vendors to include glyph forms that increase the legibility of the characters. One typical example might be providing access to a “serifed“ letter “I” and a “bent” letter “l” in a sanserif design where the default forms of those letters are intentionally similar.

But a font vendor might provide access to other forms that visually disambiguate the characters (not just letters) from other confusables, in some cases perhaps across scripts.

Making such forms default may not always be a good idea, because such forms tend to be a bit “awkward” and may disturb the natural reading flow of continuous text.

Font vendors are already free to provide access to such forms via stylistic sets, and many have done so. But here we have a case of clearly defined purpose of the feature, and there would be some benefit of devising a dedicated tag.

Using legible forms may be the preferrable way to typeset proper names (places, people), in technical or geographical context, in contexts where differrent writing systems are used, in scholarly or educational publications, and anywhere where the reader may be exposed to unfamiliar formations.

[twardoch]

As the maintainer of the Lato fonts, I've received requests over the years to disambiguate "I" and "l", which I recently did, adding them as a stylistic set. I also know that the Noto project has received similar requests. I think that this is a very common case, so it'd be useful to designate a common feature for the purpose. Vendors may continue to also map these forms to a stylistic set for backward-compatibility reasons.

[twardoch]

Ref:

Unicode confusables

• https://en.wikipedia.org/wiki/Homoglyph
• https://www.unicode.org/reports/tr36/
• https://www.unicode.org/Public/security/8.0.0/confusables.txt
• https://unicode.org/cldr/utility/confusables.jsp
• http://conference.hitb.org/files/hitbsecconf2019ams/materials/D2T2%20-%20Improving%20Unicode%20Encoding%20Attacks%20with%20Deep%20Learning%20-%20Alfonso%20Munoz%20&%20Miguel%20Hernandez%20Boza.pdf

[davelab6]

The Noto fonts had this in reverse; it had default legible forms and a user wanted a discretionary feature to turn them off.

[davelab6]

Seems to me that we could make a backwards compatible polyfill by standardization of a specific stylistic set label?

[tiroj]

I've considered something like this ever since Adobe registered the 'zero' feature, which does this for a single character. My only concern is that what constitutes legibility depends to some degree on the reader'a context and purpose.

[twardoch]

John — I think a suggestion could be contained in the feature description, but there should be discretion left for the type designer.

After all, discretionary features are partly identified by some stylistic recommendation, and sometimes by a description of the problem they're supposed to solve. "Localized forms" or "case-sensitive forms" aren't presprictive in terms of how the glyphs should look.

Yes, the "zero" feature is way too narrowly defined, being one of the very early additions (even "mandating" that the 0 should be "slashed", though it may just as well have a dot inside). I'm sure it world have been formulated differently today.

I also know that we're way past the gold rush of registering new features. I think we still might want to do an exception in this case, esp. given how features are implemented in CSS.

One could easily imagine adding the feature quickly to a bunch of cloud-hosted fonts, and then speculatively adding "font-feature-settings: 'legi'" to all HTML form elements in a popular UI design package such as Bootstrap, and suddenly, the next morning, the world is a better place. :)

[twardoch]

Note that I'm suggesting the name "Legible forms", which I think is reasonably restrained. A name such as "Legibility" would too far-reaching.

[twardoch]

Ref: notofonts/noto-fonts#821

[schriftgestalt]

I just had a (not very serious) idea.
When the Noto fonts have the legible as default, this feature is not really helpful as it would need a "Not Legible Forms" feature to deactivate them. So if there could be a flag that negates the feature. It would mean that the UI would show that feature to be active (even through the app wouldn’t do anything). But if you deactivate the feature, it would apply the lookups that replace the legible default forms with the "not legible" alternates.
The same logic could be applied to the numbers features (where we now need the pairs of proportional/tabular and lining/old style).

[tiroj]

I also have a (not very serious) idea.
Early versions of Segoe UI had more distinctive forms of I l 1, but the Windows design teams rejected them because they wanted a cleaner look. So I think we need paired features — like tabular and proportional for numerals — so font makers can decide which should be default. Obviously, Legible Forms and Illegible Forms strikes the wrong tone, so I'm thinking Enhanced Legibility Forms and Modernist Forms. :)

[PeterCon]

What are the contexts in which you anticipate this feature (or these paired features) would be used?

[tiroj]

Air traffic control. :)

The context would be situations in which distinguishing often similar characters is particularly important. I can imagine using enhanced legibility forms in addresses, esp. alphanumeric postal codes. So the context may be social — particular communities or professions — or provided by the kind of text being set.

[PeterCon]

But what kinds of apps? Will this be used mainly on the Web? Are there sites that are asking for this?

[tiroj]

Enhanced legibilty forms are already being used in design and text processing apps, but via stylistic sets, which don't translate well to CSS or other environments where the font displayed to the reader isn't always known and where stylistic sets may have different results depending on that font. Adam's proposal recognises that this kind of glyph variation constitutes a category of conventional design, so would benefit from a dedicated feature that would enable CSS users to evoke the feature with predictable results when such variant forms are available in fonts.

[PeterCon]

Thanks, the kind of info I was looking for with that question.

[ghost]

Instead of a feature that negates legi, it’d be useful to have separate features to tell a font to focus on forms that make it easier to distinguish individual characters and to tell it to focus on harmonizing forms. Because for some fonts, the forms that allow easier disambiguation are also the ones that best harmonize, so if the feature was only meant to negate legi, it couldn’t be set on running text without knowing the font in advance, which could become an interesting use case in the future.

[schriftgestalt]

To add to my thoughts: In OTVar, axes have a range and a default. That same logic could be applied to OT features, too (except no sliders).

[twardoch]

Georg — the last thing you said reminds me of my idea that I prototyped in https://github.com/twardoch/varfonts-ofl/blob/master/ZinzinVF-OFL/README.md that we could bulk-register many axes with tags identical to features (like is already the case with 'ital').

Maybe even make it a principal rule, at least for the user-controlled features.

All those features, I think, could have a user scale from 0 to 1 or from 0 to 100 (as in %) or to 1000, which would effectively be used to express completeness.

A "swsh" or "ss01" or "case" or "dlig" feature could be implemented via rvrn or via glyph variation or combination thereof. The "smcp" axis would most likely control the SIZE of the small caps, the "liga" axis the intensity of ligation.

That's just an early idea, but I think it would be worth exploring and could be done systematically.

[PeterCon]

Are there different kinds of "enhanced legibility" that might be relevant for different scenarios?

Examples given are things like distinguishing "l" from "1" and "0" from "O", which can be helpful for general user audiences in many scenarios. But a different scenario might involve URLs or other identifiers with security implications where even-more-careful disambiguation might be useful. Or there might be cases in which a certain style might be preferred but some users could have a reading limitation with that style -- e.g., 2nd-language speakers that haven't learned to read cursive, or Fraktur, etc. And then there are any number of visual impairments or reading disabilities in which some mitigations for "enhanced legibility" might be possible.

Does this proposal encompass all such scenarios?

[twardoch]

Peter — I’d say, principally, yes. Sanserif Latin fonts could disambiguate by the seriffed I and curly l, but for example a Cyrillic script font could provide legible forms for штпи done like in the image below (source). This is a standardized practice for “increasing legibility” of Cyrillic cursive writing, and it’s discretionary. Typically, it’s only used in ambiguous words.

[IgorFreiberger]

Adam, the feature would allow just 1:1 substitutions or it also would allow contextual replacement? The lowercase rn seems a m in many, if not most, sans fonts. A different r or n would be also an obvious candidate to legi feature.

[twardoch]

The legi feature should not impose any limitations on lookup types. It could break apart ligatures, form ligatures, perform 1:1 substitutions on base glyphs and on marks, and all of this might be contextual.

Various world scripts may have different notions of how to achieve “legible” forms, or in other words, how to reduce ambiguity. The implementation should be up to the type designers.