rvrn and rlig used together for switching shapes

Michal Chrastina

Is there any argument against using the same code for switching glyphs in two features (rvrn and rlig)? 
To be clear I am using this kind of substitution only on default (currency) glyphs, so rvrn should not cause problems (if I understand this argument correctly). 
I wanted to use just rlig, but unfortunately, Adobe Illustraotor seems to ignore rlig right now. 

John Hudson

In general, it is safe to have the same GSUB lookup associated with two different features so long as it won’t result in an additional substitution, i.e. where application of the lookup in the second feature unintentionally affects the output from the first feature. In most cases, if a substitution has already been applied by one feature, the substitution in the second feature ends up just having no effect. So, e.g. if you had substitutions

rvrn
a -> b

rlig
a -> b

that would be fine, because if the rvrn feature substitution has already been applied, the rlig feature would do nothing. But if you had

rvrn
a -> b
b -> c

rlig
a -> b
b -> c

the output of the rvrn substitution would be affected by the rlig feature.

Peter Constable

If two features are described as required and the text layout engine implements them that way, then it doesn't matter if an action is associated with either or both: the action will be applied, and applied once.

From a user perspective, features are a mechanism for indicating typographic intent. From the text layout engine perspective, they are a control mechanism for indicating which actions are to be applied over what spans of the text. The layout engine can scan the formatting on runs to see, for a given character, which features are activated and, then based on that, it builds a list of which actions are to be applied. But actions are never added to the list twice.

Btw, note that rlig and rvrn have different intended purposes: rlig for creating required ligatures (like Arabic lam-alef), and rvrn for substituting glyphs in a variable font contingent on selected axis values. The rlig feature can also have axis conditions in a variable font, however.

Michal Chrastina

Thank you, this is very helpful explanation.

John Hudson

If two features are described as required and the text layout engine implements them that way, then it doesn't matter if an action is associated with either or both: the action will be applied, and applied once.

To be clear, ‘action’ in this case means ‘lookup’? In that case, there could presumably be a difference in outcome if

a) the same lookup were associated with both features

vs

b) the same glyph substitutions were in separate lookups associated with respective features

In the first case, would the layout engine apply the lookup only once, on the basis that the features are specifying the same action?

Simon Cozens

Certainly for Harfbuzz, if you have one lookup assigned to two features, the number of times that the lookup will be applied depends on whether there is a "pause" between the features.

Oh, how I wish this stuff was actually specified.

John Hudson

‘pause’ meaning something like separate processing blocks?

Oh, how I wish this stuff was actually specified.

Indeed!

Georg Seifert

Peter Constable said:

Btw, note that rlig and rvrn have different intended purposes

that is true. But (as mentioned before) as rvrn is applied at the very beginning, it can’t be used to apply variations to glyphs that are substituted by other features. So we need to pick another required feature and rlig or rclt are the ones that have the widest support in app. They even work Adobe apps – sometimes. 

So the best solution would be to remove the restriction to apply rvrn at the beginning, or add a new feature that is intended for this. But in both cases we have to wait for everyone implementing it. 

Adam Twardoch

Quite often, the “intended purposes” have aged poorly, because they’ve been designed in-house, by engineers, with only a specific set of test fonts. On Windows, the intended purpose of a font family was once to provide means to turn on the bold and italic styles. In CSS, the intended purpose of font-weight was to give access to 9 weights. In Windows, the intended purpose of stylistic sets was for substitutions, but sadly not positioning. In TrueType GX, the intended purpose of fvar axes was to provide interpolation along straight lines. And so on. 

Font makers, on the other hand, are often creative, and run into conflict with these (sometimes implicit) intentions, or better said, limitations. 

Some “hacks” they employ are not useful or welcome in the longer perspective. But often, the font makers’ intentions are so genuine and important (because they contribute a creative mechanism or solve a real need of some community), that it should be the format designers and text engineers who relax on the original assumptions. 

Adam Twardoch

Fortunately, in recent years, the communications between font makers and text engineers has improved a lot, thanks to platforms like Microsoft’s Github and opensource development like that done by Google.