Excluding Small Caps from Ligatures

brandnewtype

What is the most effective way to exclude small caps from ligature feature in OpenType? In other words, Liga feature should be inactive when Smcp feature is applied. 

Grzegorz Luk (gluk)

Have you tried to change the order of features in font? 

As far as I know, 'smcp' feature before 'liga' should solve your problem...

brandnewtype

@Grzegorz Luk (gluk) let me give it a try. Thanks

brandnewtype

@Grzegorz Luk (gluk) It worked! amazing! Thank you!

Grzegorz Luk (gluk)

<joke>

features order matters

</joke>

 

John Hudson

In this case, it is lookup order that matters. The liga and smcp features are applied simultaneously by layout engines, so what affects the outcome is the ordering of the lookups associated with the features. This is somewhat occluded in some ways of working with .fea code in font tools, since it looks like one is ordering features whereas what one is actually doing is ordering the lookups associated with those features.

Grzegorz Luk (gluk)

John Hudson said:

... The liga and smcp features are applied simultaneously by layout engines, ...

Let me disagree.

I don't know much about layout engines (I've only written my own very primitive one) but that's enough for me to suspect that "features are applied simultaneously" is unlikely. Can you point me to some links about this?

Florian Pircher

Features are applied by applying their lookups. If two features both use the same lookup, then you could say that both features are applied simultaneously.

Grzegorz Luk (gluk)

Florian Pircher said:

... then you could say that both features are applied simultaneously.

this is good but you forgot to add <joke></joke> tags

John Hudson

Layout engines process features in blocks, the specifics of which depend on the shaping model used for the glyph run as itemised according to Unicode script properties.* So, for example, the features applied in each block for an Indic script such as Devanagari differ from those applied for a European script such as Latin. Within each block, some shaping engines may also apply features in a specific order, but this is generally the case for a few features that are applied at the beginning of glyph processing (rvrn, locl, ccmp), and a couple of Indic shaping features (akhn, rphf), which set up input for subsequent lookups.* Other than those specific features, OpenType Layout is applied according to lookup order within the processing of each feature block. This means that all the active features within a block are indeed being applied at the same time, with only the lookup order affecting the sequence of operations. This is an important aspect of OpenType Layout, because it means that lookups associated with different features can be interleaved and affect each other, which would not be possible if the features themselves were being processed sequentially rather than simultaneously.

*I documented the feature processing blocks here. I am working on an update to that document to cover some layout features that have been registered since 2014, and to explain the change to the definition of the topographical (init, medi, fina, isol) features that were made in the OT/OFF registries in response to my analysis of their application.

**The initial design of OpenType Layout was that all processing would proceed according to lookup order, but Microsoft then decided to standardise some feature order processing to aid complex script shaping.

Grzegorz Luk (gluk)

@John Hudson thank You for detailed explanations and link

John Hudson said:

... This means that all the active features within a block are indeed being applied at the same time, with only the lookup order affecting the sequence of operations. ...

the issue resulted from my understanding the word simultaneously too closely (to me it almost sounded like a use of parallel programming
We agree, there is always some order in which operations are applied, simultaneity is a "conventional' term here.

John Hudson

Another way to think about this is to say that features are not ‘processed’ at all, they are only active or inactive, and the active features determine which lookups are processed. This is nicely evident in the VOLT proofing tool, in which you can see exactly which lookups will be processed when you activate specific features on the input glyph string.

Grzegorz Luk (gluk)

or even better: features are only active or inactive on Layout&User side, font "contains only" lookups with the 'feature' tag. That better explains the fact that you can have 'liga' before and after 'smcp':

 - Lookup with index '0' and feature tag 'liga' (e.g. base part of ligatures)

 - Lookup with index '1' and feature tag 'smcp'

 - Lookup with index '2' and feature tag 'liga' (e.g. rest of ligatures)

k.l.

The statement that ‘features are applied simultaneously’ is somewhat strange.
Features are not applied at all. It is lookups that are applied, one after the other, in order of appearance, and once.
Scripts and Features merely serve as filters, determining *which* lookups are applied. (And determining *when* lookups are applied, i.e. at which stage, in case that USE’s extra complications come into play.)

John Butler

I vaguely recall in the early days of AFDKO, it was possible to write a .fea file with code inside each feature that never divided it into lookups. I suppose the lookups were always there, even if not made explicit.

John Hudson

Features are not applied at all.

That is the better understanding: talking about applying features is really talking about features being active at particular stages of the OTL processing. In some cases the features are active because the shaping engine is activating them, which is a bit more like ‘applying’ the features as part of the layout operations than e.g. a smallcap feature that is activated by the user.