OpenType Features documentation

Yves Michel
Yves Michel Posts: 218
in Type Design Technique & Theory

A client used one of my connected script fonts to write a book in the education domain. She’s a computer rookie and wasn’t aware of the calt and liga OpenType features present in the font. 

My fault as I didn’t document this. The result was not without some inelegant connections between letters.

My question: how do you document your fonts about the features when you sell them through a distribution platform?


Tagged:

Comments

  • Paul Hanslow
    Paul Hanslow Posts: 190
    edited September 21
    This is a little tricky to answer. If you own your own distribution platform (ie foundry website) it's a little easier as you control how your website looks, what's shown, and what opentype features you wish to hero.

    When distributing on other websites (my fonts, I Love typography) you're sort of at the mercy of how they wish their type-testers to look, whats shown etc. One method is to display certain features in the hero images at the top of the font's page. Another way to is to show certain features in the type specimen pdf. This all assumes buyers will look at the graphics and specimen and in my honest opinion most don't. 

    There are plenty of typefaces out there with multiple stylistic sets and clever opentype coding which is either overlooked, underutilized or completely unknown about by the general type user. Kind of sad really. 

    I hope this somewhat answers your question. I personally put opentype in the specimen and outline what's included in the font. Then if I wish to hero a something it also goes in the carousel graphic. 
  • Yves Michel
    Yves Michel Posts: 218
    Paul Hanslow said:

    ... When distributing on other websites (my fonts, I Love typography) you're sort of at the mercy of how they wish their type-testers to look, whats shown etc.  
    Exactly, and it's frustrating.
    Thanks Paul!

  • Paul Hanslow
    Paul Hanslow Posts: 190
    In addition, it's not only an issue isolated to distribution platforms. Adobe InDesign requires clicking the smallest button to find Opentype features that can be enabled by the user. IMO it's sad how a type designer can spend a lot of time on opentype features (designing additional characters etc) only to never see them utilised. 

    House Industries did a good job in the early 2000's of explaining their opentype features within their PDF specimens, many of which can still be seen be using the Wayback Machine to access said PDFs. 

     
  • Nick Shinn
    Nick Shinn Posts: 2,300
    You might put use <rlig> instead of <calt>.
    No documentation required.
  • Yves Michel
    Yves Michel Posts: 218
    Nick Shinn said:
    You might put use <rlig> instead of <calt>.
    No documentation required.
    Sorry but I don't understand the meaning of this.
  • Nick Shinn
    Nick Shinn Posts: 2,300
    Thanks John. The rlig feature is also useful for the “pseudo-random” effect, because Adobe apps disable calt and liga when tracking exceeds a relatively small amount, but rlig will preserve the alternates when, for instance, capitals are widely letterspaced.
  • Yves Michel
    Yves Michel Posts: 218
    @Nick Shinn
    Thank you! I didn't know the rlig feature and its difference with calt and liga in terms of activation/deactivation in different software.
    @John Hudson
    Thanks for the explanation (and I read your "Enabling Typography" article).

    Does this mean I can simply put my lines of code inside:

       feature calt {
       } calt; 
    and
       feature liga {
       } liga;

    into
       feature rlig {
       } rlig;

    without any other modification or differences in syntax ?

    By the way, my client used Canva (free) to write her book. I've read only the Pro and Education versions support OpenType features. I suppose it will support rlig.

    Thanks anyway for your kind and useful answers !


  • John Hudson
    John Hudson Posts: 3,514
    Yes, the same lookup substitution code will work within rlig the same way as in the other features.
    I've read only the Pro and Education versions support OpenType features. I suppose it will support rlig.
    ‘Support’ in that context probably means ‘Provides access to in the UI’. The rlig feature is applied directly by the layout engine, and is active by default, so should work regardless of whether a particular app or environment provides UI interaction for discretionary features, unless that environment is actively bypassing common text layout libraries and not activating any OTL, which is unlikely.
  • Yves Michel
    Yves Michel Posts: 218
    Thank you John! 
    Yes, the same lookup substitution code will work within rlig the same way as in the other features.
    I'll try to change my code. I suppose I keep the order (original calt before original liga) within rlig.
  • Kent Lew
    Kent Lew Posts: 1,018
    If you are combining two sets of different rules from those other features, you may want to evaluate whether you need to explicitly declare them as separate lookups within {rlig}. 
    If they truly are different lookup types — i.e. GSUB Type 1 single sub for {calt} rules and GSUB Type 4 ligature sub for {liga} rules — then this would not be necessary, as the compiler will necessarily create separate lookups. But if you happen to have mixed types, then you may not want to leave it to the compiler to potentially combine rules from across the original features.
    And as you’ve already said, you’ll want to keep the same order as your original features.
  • Yves Michel
    Yves Michel Posts: 218
    Thank you Kent!
    Just one more question:
    My original liga included subs for every "a" glyph, "e" glyph, etc. If I try to simplify that by using OT classes (like in the first line in grey) and, of course, suppressing the subs for the "a" glyphs, I get the following errors, one in lookup FINAL and one on line 119.
    Help, please ?




  • Kent Lew
    Kent Lew Posts: 1,018
    For the first error, it looks like your font software is enforcing a perceived requirement of {rlig} that it only contain rules of GSUB Type 4, whereas your lookup FINAL consists of Type 6 rules. 
    The font should be compilable with Type 6 rules assigned to {rlig}. This may be a warning-only report, because some software may only interpret Type 4 rules in {rlig}. I can’t tell if this specific error is preventing compilation.
    The intended use case of {rlig} is Type 4 ligature substitutions, and that is certainly the recommended behavior; but I don’t think it is an *absolute* constraint. You should be able to include such contextual subs there, as others suggested. If this is causing an error, you might need to use a different program to compile.
    Or you could put those rules in {rclt} instead, which should accomplish the same desired default, nondiscretionary results.

    For the second error, you simply cannot use a glyph class as a result in Type 4 rules. Only as a target.
    Your repetitive situation is an example of why it may be more efficient to handle such interactions with alternate glyphs that are modified to connect with each other in combination, rather than single, fixed ligature glyphs.
    By which I mean: draw an alternate A.beforex that adjusts the right side however needed to merge with the x, and if necessary draw an alternate x.afterA with an adjusted left side. Adjust sidebearings so that they naturally create the desired joining behavior when set in sequence.
    If you use anchors and components for your accents, then maintaining all the related Aaccent.beforex glyphs should be straightforward.
    Then you can use a sequence of contextual substitutions in your “ligature” feature (whether {liga}/{rlig} or {calt}/{rclt}):

    lookup Ax_lig1 {
        sub @AFam' x by @AFam.beforex;
    } Ax_lig1;
    lookup Ax_lig2 {
        sub @AFam.beforex x' by x.afterA;
    }Ax_lig2;

    You will need to declare these explicitly as distinct lookups to keep the two rules separate, as they need to be applied sequentially. First the A is replaced when followed by x; then in a second run, the x is replaced when preceded by the alternate A. (If one or the other of your A or x don’t need to be drawn any differently to fit together, then this becomes that much simpler.)
    Since you’ve already presumably drawn all your individual ligature glyphs, there may be zero advantage at this point to reconceiving your approach. But for future, this may be an strategy worth contemplating.
    This becomes even more effective if, for example, the adjustment to the A allows it to merge with several different following glyphs for on-the-fly ligatures.
  • John Hudson
    John Hudson Posts: 3,514
    The intended use case of {rlig} is Type 4 ligature substitutions, and that is certainly the recommended behavior; but I don’t think it is an *absolute* constraint.
    It definitely isn’t a constraint of the OpenType format. Any feature can have any kind of lookup type associated with it, and I wouldn’t even say that type 4 substitutions are the intent or recommended behaviour for a feature like rlig. The intent is that some ligations between glyphs are active by default and cannot be disabled. How those ligations are implemented at the lookup level is supposed to be up to the font maker, not the compiler. The OTL feature registration template includes a ‘Recommended implementation’ section, but that is really a suggestion of how a feature may be implement, and an artifact of the early days of OpenType. 
  • Yves Michel
    Yves Michel Posts: 218
    @Kent Lew @John Hudson @Nick Shinn
    I'm not sure I understand all about Types 4 and 6.
    But, I'll follow your advice, Kent and leave my extensive list of subs untouched.
    Thank you all for your help. 
  • Yves Michel
    Yves Michel Posts: 218
    I forgot to mention I use Fontlab 8.
  • John Hudson
    John Hudson Posts: 3,514
    I'm not sure I understand all about Types 4 and 6.

    OpenType Layout features are implemented via lookups, which is what you are coding in the Features panel in FontLab. Several different types of lookup are defined in the OpenType specification for the GSUB and GPOS tables. Kent was talking about GSUB lookups type 4 (many-to-one substitutions) and type 6 (chained contextual substitution). Mostly, you don’t need to think about things at this level, because the OTL code compiler will automatically write the appropriate lookup type, but you may occasionally get an error report if you mix incompatible substitution types within the same code block.
  • Kent Lew
    Kent Lew Posts: 1,018
    As John says, the average designer doesn’t generally need to be too concerned about the different lookup types. (Until you run into compiling errors or unintended behaviors perhaps. 😉)
    That said, anyone who is interested in understanding the nuances of different types of GSUB lookups can find explanations in Adobe’s OpenType Feature File Specification. 
  • Yves Michel
    Yves Michel Posts: 218
    John Hudson said:
    Kent was talking about GSUB lookups type 4 (many-to-one substitutions)
    John, I understand that Type 4 "many-to-one" is a synonym of "ligature".

    Kent Lew said:
    Until you run into compiling errors or unintended behaviors perhaps. 😉)
    When that's the case, goto Typedrawers !

    To understand a little more, I read Simon Cozens article onGithub with explanations and, most important for me, examples.

    Thanks again John and Kent!!

  • John Hudson
    John Hudson Posts: 3,514
    I understand that Type 4 "many-to-one" is a synonym of "ligature".
    Yes, but in the technical sense of a single glyph representing more than one character, so encompassing a lot more than traditional ligation of letters. So, for example, a ccmp feature lookup that precomposes a base plus one or more combining marks into a single glyph also uses a Type 4 GSUB lookup.

    Conversely, traditional ligation of letter may not use a Type 4 lookup, because the same visual result can also be achieved more flexibly using contextual variant forms of the letters that create dynamic ligations.
  • Peter Constable
    Peter Constable Posts: 267
    John Hudson said:
    I understand that Type 4 "many-to-one" is a synonym of "ligature".
    Yes, but in the technical sense of a single glyph representing more than one character, so encompassing a lot more than traditional ligation of letters...

    I agree with the latter statement, "encompassing a lot more than traditional ligation of letters", but not the former, "a single glyph representing more than one character". A type 4 lookup substitutes some sequence of glyphs with one glyph, but there's no constraint on how that sequence of glyphs was derived.

    For example—albeit absurd—the character "a" could be mapped by default to glyph_a, which then undergoes a one-to-many substution glyph_a --> glyph_a.top glyph_a.bottom, and then that sequence could subsequently undergo substitution via a type 4 lookup, glyph_a.top glyph_a.bottom --> glyph_a. Now, while that's an absurd example, I have encountered fonts that use a type 4 lookup to absorb an extraneous glyph from a sequence, something like glyphX glyphY --> glyphY.
  • John Hudson
    John Hudson Posts: 3,514
    A type 4 lookup substitutes some sequence of glyphs with one glyph, but there's no constraint on how that sequence of glyphs was derived.
    Yes, that is technically more accurate. It’s all downstream of character-to-glyph mapping.

Categories