Numbers glyphs in aalt

I'm trying to understan the logic of aalt applied to numbers.
For instance, in PremierePro I find:
one (1)&nbsp; &nbsp; &nbsp; &nbsp;  | one.oldstyle one.numerator one.denominator one.superior one.inferior(₁) one.taboldstyle one.fitted<br>one.fitted&nbsp; &nbsp;&nbsp;  | one.oldstyle one(1)<br>one.oldstyle&nbsp; &nbsp; | one(1) one.fitted one.taboldstyle<br>one.taboldstyle | one(1) one.oldstyle
1) what determines the fact that in certain cases one(1) is choosen as the first substitution, in other ones as the second substitution?
2) why in one.fitted there isn't one.taboldstyle? Which is the reason?
Thank you


  • aalt is used to show where appropriate (for instance in the Glyphs palette in Adobe apps) all possible alternate glyphs for a character. It is usually written by listing all features (salt, ssXX, subs, sinf, tnum, pnum, etc.) that do substitutions.
  • mauro sacchettomauro sacchetto Posts: 275
    edited December 2018
    Yes, I already realized it. But I asked about the choise and about the order of alternatives, as in the case I quoted. Why in <one.taboldstyle> one(1) is the first alternative, but in <one.fitted> one(1) is the second one? Why in <one.oldstyle> there is one.taboldstyle and in <one.fitted> not? Which logic oversees?
  • It may be because there is no feature defined which substitutes one.fitted by one.taboldstyle. As to the order, it doesn't really matter, since all the alternates are presented to the user at once. The type designer may prefer a certain order, but I'm not sure how that would be implemented.

    If you want all possibilities to be included and control the order, you can write it that way yourself. It doesn't have to be implemented by listing all the features that do substitutions. That's just how it's often done.
  • I see. Infact, for example, MinionPro has different substitution logic for numbers... Thanx
  • Keep in mind that the code you see when opening an .otf in a font editor likely does not match the code the designer put into the font.
  • @Frode what do you mean?
  • Frode HellandFrode Helland Posts: 157
    edited December 2018
    My technical vocabulary is not that strong, but I’ll try: Font editors write OT features in a human-readable syntax (for the most part AFDKO). When fonts are exported, these features are flattened and compiled, and no longer readable to humans. When you open an exported font, the editor guess how the original features were written by looking at the compiled code, but there are a number of things it might not be able to deduct – such as, for example, classes.
  • Yes, I see. For I'm a Linux user, it would be interesting to know if is FontForge able to export .fea files...
  • Further to what Frode said:

    There is no built-in mechanism to store names of classes in an OT font, that is purely on the font editor side. So that is lost when you compile to OTF or TTF.

    The nature of classes themselves is tricky. Older editors maintain the classes users create, but at the potential cost of a larger compiled font, and even compile failure. FontLab VI uses KLTF optimization to make a smaller output OTF/TTF font (avoiding kern subtable overflow). But this means that the organization of the kerning may be different than what the user put in. The font functions the same, but you can't necessarily open that font back up and have the same class kern setup you started with.
Sign In or Register to comment.