Numbers glyphs in aalt
mauro sacchetto
Posts: 353
I'm trying to understan the logic of aalt applied to numbers.
For instance, in PremierePro I find:
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
For instance, in PremierePro I find:
one (1) | one.oldstyle one.numerator one.denominator one.superior one.inferior(₁) one.taboldstyle one.fitted<br>one.fitted | one.oldstyle one(1)<br>one.oldstyle | one(1) one.fitted one.taboldstyle<br>one.taboldstyle | one(1) one.oldstyleNow:
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
0
Comments
-
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.0
-
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?0
-
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.0 -
I see. Infact, for example, MinionPro has different substitution logic for numbers... Thanx0
-
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.2
-
@Frode what do you mean?0
-
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.3
-
Yes, I see. For I'm a Linux user, it would be interesting to know if is FontForge able to export .fea files...0
-
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.2
Categories
- All Categories
- 43 Introductions
- 3.7K Typeface Design
- 799 Font Technology
- 1K Technique and Theory
- 617 Type Business
- 444 Type Design Critiques
- 541 Type Design Software
- 30 Punchcutting
- 136 Lettering and Calligraphy
- 83 Technique and Theory
- 53 Lettering Critiques
- 483 Typography
- 301 History of Typography
- 114 Education
- 68 Resources
- 498 Announcements
- 79 Events
- 105 Job Postings
- 148 Type Releases
- 165 Miscellaneous News
- 269 About TypeDrawers
- 53 TypeDrawers Announcements
- 116 Suggestions and Bug Reports