My inferior glyphs are the exact same as .subs and .sinf glyphs. Is there any way to automatically generate feature code for this setup without having to duplicate the glyphs?
What I’ve found is that by having inferior glyphs Glyphs app generates the subs feature with this code:
sub zero by zeroinferior;
sub one by oneinferior;
sub two by twoinferior;
sub three by threeinferior;
sub four by fourinferior;
sub five by fiveinferior;
sub six by sixinferior;
sub seven by seveninferior;
sub eight by eightinferior;
sub nine by nineinferior;
but does not generate the sinf feature. When I add the .subs glyphs then the sinf feature is auto-generated. And when I remove them it is removed. Before removing the .subs glyphs I unchecked “generate automatically” for the sinf feature, and then after removing the .subs glyphs I copied the subs feature code (above) and pasted to the now manual sinf feature. It seems a bit confusing that the .subs glyphs do not correspond to the subs feature.
Since inferior, subs, and sinf are all identical in my typeface, I wanted to use only one set and still generate both subs and sinf features from it. I thought to go with inferior since they have unicode points, but if I’m understanding the tutorial correctly, I should set be using .subs glyphs since it generates the subs and sinf features automatically; does this also mean I don’t need inferior glyphs? Or is it best to just include both inferior glyphs and .subs glyphs, since using only inferiors would imply the sinf feature making semantic changes?
Here is how I do it: The only small figures with Unicode you should care about are onesuperior twosuperior threesuperior because these typeable on Windows keyboards, the rest are OpenType variants. I usually start with .dnom because they are on the baseline, and then derive all the other from them:
Then use Filter > Transformation > Transform to vertically offset the small compound figures. Let the compounds inherit the same kerning groups as the .dnom figures with the Set Kerning Groups script by schriftgestalt.
What’s benefit to using .sinf glyphs for inferiors over .subs glyphs?
Also, is there any disadvantage to not including a full set of encoded superior glyphs (and likewise inferior glyphs) other than not being able to properly copy and paste them?
In short, they trigger different features. subs is not specific for figures.
Even though they have Unicode values, they cannot be typed (except for the three I mentioned above) and take up space. You may regret including them if you want to keep filesize low.
other than not being able to properly copy and paste them?
The filesize impact of having a glyph encoded is very small - smaller than making the glyph accessible through an OpenType feature!
While they can not be typed, if the glyph is designed as 1:1 the same, then it seems better to encode it so copy & paste works everywhere.
So much text is still in non-OT-aware environments. In fact I am curious which “rich text” environments support truly support OT feature styling across copy & paste… Do you know of any?
I think the point is that, if you want all 3 kinds of lower numerals (subs/sinf/inferior), you shouldn’t need to have duplicate glyphs for the 2 OT features (subs/sinf) to be generated automatically.
IN the Glyphs tutorial it says that “if you want your subs figures to be identical to your sinf figures. You can achieve that if you employ the .subs suffix. Glyphs will then generate both the subs and the sinf feature with them.”
They also note that you MIGHT want to have separate designs and have a model for that - but leaving that aside - it seems like just having .subs in the source file and letting Glyphs do its thing is enough. No?
I admit and agree that it is relevant what he says, only 1-3 exist on a Windows keyboard, but, there are unicode character codepoints existing for 4 through 0 and I would like to see them used even though they can’t be typed directly and perhaps are most commonly accessed using the other 2 methods.
So, since I want all 3 ways to access these numerals (and I am requiring that for GF fonts then as a GlyphsApp user, I need only have zeroinferior and friends, and then set up both sinf and sups features to access them using those features too.
But the problem with this situation today is that I need to do that setting up of features carefully - such as having duplicated glyphs with the .subs naming, so the sinf and sups be auto-generated by glyphsapp for the full glyphs set, and then, at the end of my development process (like the traditional hinting phase), then adjust these features’ codes to be manual and refer instead to the inferior glyphs, and then delete the .sups glyphs that are no longer referenced by the OT code (and then be sad that OT code is no longer auto-maintained by GlyphsApp.)
I fixed this. Only having the inferior numbers will give this feature code now:
feature subs {
sub zero by zeroinferior;
sub one by oneinferior;
…
} subs ;
feature sinf {
sub zero by zeroinferior;
sub one by oneinferior;
…
} sinf ;
