Options

Excluding Small Caps from Ligatures

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. 

Comments

  • Options
    Have you tried to change the order of features in font? 
    As far as I know, 'smcp' feature before 'liga' should solve your problem...

  • Options
    @Grzegorz Luk (gluk) let me give it a try. Thanks
  • Options
    @Grzegorz Luk (gluk) It worked! amazing! Thank you!
  • Options
    Grzegorz Luk (gluk)Grzegorz Luk (gluk) Posts: 157
    edited February 11
    <joke>
    features order matters
    </joke>
    :smiley::smiley: :smiley:
  • Options
    John HudsonJohn Hudson Posts: 2,980
    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.
  • Options
    ... 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?
  • Options
    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.
  • Options
    Grzegorz Luk (gluk)Grzegorz Luk (gluk) Posts: 157
    edited February 11
    ... then you could say that both features are applied simultaneously.
    this is good :smiley: but you forgot to add <joke></joke> tags
  • Options
    John HudsonJohn Hudson Posts: 2,980
    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.
  • Options
    Grzegorz Luk (gluk)Grzegorz Luk (gluk) Posts: 157
    edited February 11
    @John Hudson thank You for detailed explanations and link
    ... 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 :smile:
    We agree, there is always some order in which operations are applied, simultaneity is a "conventional' term here.
  • Options
    John HudsonJohn Hudson Posts: 2,980
    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.
  • Options
    Grzegorz Luk (gluk)Grzegorz Luk (gluk) Posts: 157
    edited February 12
    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)
  • Options
    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.
  • Options
    John HudsonJohn Hudson Posts: 2,980
    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.
Sign In or Register to comment.