The differnce between rlig and liga

Yeshurun Kubi

Can not figure out the difference between rlig and liga.
I have tried to understand this by myself, but could not find the real difference.
Oh! I have noticed that on 'rlig' definition you will find the phrase 'required ligature', but both rlig & liga have the same purpuse:

Replaces a sequence of glyphs with a single glyph which is preferred for typographic purposes

And both have the same UI suggestion:

This feature should be active by default

Sorry for asking something that might be very simple for exports around here, but as a program designer that want to understand [at first] those features that should be active by default, i've found all this Microsoft documentation a bit confusing.

Thanks. 

Kent Lew

The distinguishing characteristic is that {rlig} is supposed to be non-turn-offable.

{liga} = recommended on by default, but can be deactivated in UI

{rlig} = recommended on by default, and should not be able to be deactivated in UI

Whether or not a given rendering environment respects this distinction is another matter.

John Hudson

OTL features have one of three recommended default states:

1. On by default and cannot be turned off (required features)

2. On by default by can be turned off (standard features)

3. Off by default but can be turned on (discretionary features)

'rlig' is required ligatures (1st state).

'liga' is standard ligatures (2nd state).

'dlig' is discretionary ligatures (3rd state).

The 'rlig' feature was defined initially for use with Arabic script, where there are some combinations of letters that always take a special form that it should not be possible to turn off, while other combinations can take different forms in some fonts, and so would be treated as standard or discretionary.

[The model is not as consistently applied as one might hope. So, for instance, some kinds of features have only 1st and 2nd state options, and no 3rd state, e.g. 'rclt' and 'calt'.]

John Hudson

PS. You might find my Enabling Typography paper helpful. It includes a recommended breakdown of OTL features into processing blocks, and identifies the recommended state of each feature.

John Hudson

PPS. Ignore the final section of the paper on 'topographical features'. That has been mostly resolved since I wrote the paper by redefining 'init' 'medi' etc. as specifically implementing Unicode ArabicShaping.txt behaviour.

Yeshurun Kubi

Thank you very much. It is really helpful information, and the way you put it is very simple and clear.
Am I wrong feeling that the Microsoft documentation is complicated and not unified, or it is just because of my poor English abilities?

John Hudson

The OpenType Layout feature registry is basically unchanged in format since it was first published in the late 1990s. The initial feature definitions were written prior to the actual implementation of those features anywhere, and then served as a template for all subsequent layout feature definitions. This resulted in two problems: inconsistency between the speculative feature descriptions and how the features actually ended up being implemented in software, and cumulative confusion around the meaning of repeated-but-not-understood statements in the definition template. I've suggested to Microsoft multiple times over the years that the whole registry should be reviewed and revised to a) simplify the information presented, b) check for consistency between the feature definitions and actual implementations*, and c) add systematic data regarding processing blocks, default state, and shaping engine interaction.

*We reviewed and revised a small number of feature definitions a couple of years ago, and I think this approach could serve as a model for review of the whole registry. We examined how the 'init', 'medi', 'fina' and 'isol' features are actually implemented in shaping engines, contra how they were previously described in the registry — which bore basically no relationship at all to the implementation —, and then re-defined the features in a way that explicitly linked them to the relevant Unicode shaping standard.

Nick Shinn

I have used rlig in a couple of typefaces, as a convenient hack for maintaining pseudo-randomness beyond the narrow range of tracking in which calt and liga work in Adobe applications.

In other words, I’ve put pseudo-random coding into the rlig feature, so that it is always non-turn-offable.

So that is one difference between liga and rlig, in Adobe (at least) applications, in which typographers are prohibited from having ligatures such as f_i appear in the middle of a tracked-out (letter spaced) word. But this behaviour may occur in rlig, should it be required by the type designer.