aalt type 3 and <glyphclass>

mauro sacchetto
mauro sacchetto Posts: 353
edited June 2019 in Font Technology
Referring to this tread:
https://typedrawers.com/discussion/1319/opentype-aalt-feature
I don't understand the two types of lookups that it is possible / convenient (or not?) to carry out.
I refer to the fonts that I saw that present two aalt lookups, the first one of "single substitution" type, the second one of "alternate substitution".
Type 1 is simple: it involves setting a 1: 1 substitution.
As far as type 3 is concerned, the concept of <glyphclass> (or "group") is not clear to me.
In the first lookup (single replacement) I find for example the glyphs of lowercase letters and the replacement with the small caps version (i.dot -> i.dotsc.
In the second lookup (alternate substitution) the glyphs of letters that are passable of innumerable substitutions (i -> i.superior i.inferior .dot i.sc).
But then what are the glyphclasses with only one member?

Comments

  • André G. Isaak
    André G. Isaak Posts: 633

    A glyph class with only one member is just that.

    aalt is basically only used by applications which display a list of glyph alternates (e.g. if you click on one of the little triangles in InDesign's glyph palette).

    So the following would both be admissible:

    Example 1:

    <p>sub i from [i.sups, i.inf i.sc]; # displays three alternates</p><p><br></p><p><span style="color: inherit; font-size: inherit; background-color: transparent; font-family: "Alright Sans from Webtype", "Lucida Sans Unicode", "Lucida Sans", "Lucida Grande";">sub </span><b style="color: inherit; font-size: inherit; font-family: "Alright Sans from Webtype", "Lucida Sans Unicode", "Lucida Sans", "Lucida Grande";">h from [h.sc];</b><span style="color: inherit; font-size: inherit; background-color: transparent; font-family: "Alright Sans from Webtype", "Lucida Sans Unicode", "Lucida Sans", "Lucida Grande";"> # displays only one alternate</span></p>

    Example 2:

    <p>sub i from [i.sups, i.inf i.sc]; # displays three alternates</p><p><br></p><p><span style="color: inherit; font-size: inherit; background-color: transparent; font-family: "Alright Sans from Webtype", "Lucida Sans Unicode", "Lucida Sans", "Lucida Grande";">sub </span><b style="color: inherit; font-size: inherit; font-family: "Alright Sans from Webtype", "Lucida Sans Unicode", "Lucida Sans", "Lucida Grande";">h by h.sc;</b><span style="color: inherit; font-size: inherit; background-color: transparent; font-family: "Alright Sans from Webtype", "Lucida Sans Unicode", "Lucida Sans", "Lucida Grande";"> # display only one alternate</span></p>

    The difference between the two is that in the second example the compiler will be forced to split these two substitutions into separate lookups because the substitution rules are of different types (one to one vs one from many).

    Ergo, there will be cases where you might want a singleton glyph class just to avoid having extra lookups.

    Note that, if you're using AFDKO (including FontLab), you don't really need to worry about this since it will construct your aalt feature for you given a list of features.

  • mauro sacchetto
    mauro sacchetto Posts: 353
    You write
    there will be cases where you might want a singleton glyph class just to avoid having extra lookups.
    I understand that you support the (occamistic) logic of saving on useless lookups.
    However, I wonder why many fonts (for example from Adobe, such as ArnoPro, BriosoPro, CaslonPro, GaramondPremierePro etc.) have all a double lookup for aalt, precisely the first one for single substitution (type 1) and the second one for alternate substitutions ( type 3).
    A particular meticulousness or are there structural reasons?

    PS
    I have a specific reason for these questions, relating to the Turkish <i>, but on this I will open a separate tread

  • André G. Isaak
    André G. Isaak Posts: 633
    That's probably just how AFDKO does it. BTW, I wasn't advocating limiting the number of lookups; I was simply pointing out a reason why the syntax allows for a singleton class — that way you can force a type 3 lookup if for some reason you should want one. It's likely (ever so slightly) more complex to write a compiler that excludes singleton classes, and there's no real reason to exclude them.

Categories