We want to de-emphasise the accent in [YA] vs. [YÃ].
How about [“A] vs [“Ã]? Do we want these pairs to have nearly the same kerning as well? The symmetry test for this could be ["ÃA"] (including the straight quotes).
Or, is there a difference in concept between UC-UC and UC-punctuation? Even though Kern On mainly looks at shapes and makes few assumptions, it does apply this very coarse semantic distinction when it applies the de-emphasis to the lowercase: LC-LC gets full de-emphasis (rather: as much as deduced from the models, see above) whereas LC-punctuation receives less de-emphasis, using a hard-coded factor of 0.25 (determined from my personal taste, sorry, there are limits to deducing things from the models).
How about [“A] vs [“Ã]? Do we want these pairs to have nearly the same kerning as well? The symmetry test for this could be ["ÃA"] (including the straight quotes).
Or, is there a difference in concept between UC-UC and UC-punctuation?
this seems more dependent on the spacing than YA vs. YÃ.
if the typeface is more loosely spaced, I would expect [“A] and [“Ã] to have nearly/exactly the same kerning. the tighter it gets the more likely [“Ã] needs extra space. I would not expect straight quotes and left quotes to have the same values (imagine a round left quote that has an "overshoot" jutting out to the right, compared to the straight quote) but I would expect ["Ã] and ["A] to be nearly/exactly the same, again potentially diverging once the spacing gets tight enough
While looking at this and some potential approaches, here are a couple other pairing examples that are similar with unlocked exceptions/asymmetry questions that I couldn't quite solve (this is referencing the file that Tim has, but others might have encountered similar?)...
KA vs KÁ KÄ KÃ etc.
In this case, the KA was rendered unlocked by Kern On with a kern value of 71, but all the other diacritic glyph pairings of K and A share the same, manually set kern group name, but have a different value of 82.
So KÁ for example doesn’t seem to have visual tension/mass to compensate for like our earlier YÃ example did, but it and the others became a different value by 11 units than the now unlocked base KA pairing.
This base KA pairing is maybe more preferred and correct, so I’m just trying to sort out why it became unlocked and different from the rest of the grouping.
"Ă" vs "A" and its other diacritics. They all jump around. ("A" is ok)
The left vs right side kerning in "Ă" for example is a difference of almost 80 units.
A buried example that I wouldn’t have found unless toggling through (some other /A glyphs are more correct/consistent, others are more largely off). But /A and all its diacritics is ok with /quotesingle (which shares the same kern group name as quotedbl).
Thanks for exploring it Tim and the helpful results and feedback so far. I consider some of these pairings might never show up for a user, and maybe the tweaking to the "de-emphasis" of cap accents might help?
The “locked” and “unlocked” icons in Glyphs seem to be causing lots of confusion.
To be clear: There is nothing “locked” about the pairs that are shown with a locked icon in Glyphs. It’s a bad UI decision in my opinion.
The locked icon indicates that a pair is a class-class pair. The unlocked icon shows that is a glyph-glyph pair (sometimes referred to as “exception”). In Glyphs’ Kerning Window, you can see that some pairs have bold blue partners that start with an @ (class-class pairs), and green-brownish pairs that show the glyph names (glyph-glyph pairs). To me, that’s clearer than the lock symbol.
Can we please stop referring to “locked” or “unlocked” pairs. Let’s call them what they are: class-class pairs and glyph-glyph pairs. Thanks.
Sorry for any added confusion, it was just a visual indicator. Good to clarify. I think some of these examples boil down to why some pairs occasionally get treated different from their kern classes, specifically when the overall mass doesn't seem to create a visual conflict (understand the exceptions created when there is tension). Also why larger asymmetry in some cases (again rare, but popped up). Ultimately learning to trust the tool and what to watch for in review or not worry about.
We need to distinguish three types of potential issues:
1. Live kerning that is wrong according to your judgment. What you see while KO is running is the “ideal”, raw glyph-glyph pair, untainted by the class generation algorithm. If this is not as desired then this does not have anything to do with classes. While KO generates the autokerning, it does not know anything about classes or exceptions; it only knows glyph-glyph pairs.
2. KO writing class-class kerning and glyph-glyph kerning in a way you find surprising, while the effective final kerning is still correct. Short answer: Don’t worry about it, KO knows what it is doing. Also, note that KO does not aim at writing the kerning in a way that looks pretty to humans or facilitates manual changes afterwards.
3. Undesirable (inconsistent) effective final kerning although the raw live kerning was correct. This is because the class and glyph kerning compression is somewhat lossy. Like in other lossy compression systems, you get compression artifacts that are undesirable but inevitable under the given size restriction.
Understanding which of the three we are dealing with is a necessary first step for further discussion.
The FontLab autokerner is nothing like Kern On. The FontLab model is a simple black box that produces results that may or may not be good for a particular design or script. Kern On uses iterative input from the user to progressively refine its algorithm as it applies to a particular typeface and script.
I would love to see RMX tools available in the new versions of FontLab, as they were in FLS5. Kern On in FL would be great.
‘Comparable functionality’ would be okay, but since Tim has done all the work in inventing these tools, I am more interested in figuring out ways to fund their adaptation to FontLab’s scripting API.
FontLab 8 has many useful functions. I consider "Slanter" to be fundamentally important for the type design of italic fonts. That's why I don't understand why it hasn't yet been integrated in FontLab 8. Glyphs at least has Cursify.
Comments
"Ă" vs "A" and its other diacritics. They all jump around. ("A" is ok)
Thanks for exploring it Tim and the helpful results and feedback so far. I consider some of these pairings might never show up for a user, and maybe the tweaking to the "de-emphasis" of cap accents might help?
1. Live kerning that is wrong according to your judgment. What you see while KO is running is the “ideal”, raw glyph-glyph pair, untainted by the class generation algorithm. If this is not as desired then this does not have anything to do with classes. While KO generates the autokerning, it does not know anything about classes or exceptions; it only knows glyph-glyph pairs.
2. KO writing class-class kerning and glyph-glyph kerning in a way you find surprising, while the effective final kerning is still correct. Short answer: Don’t worry about it, KO knows what it is doing. Also, note that KO does not aim at writing the kerning in a way that looks pretty to humans or facilitates manual changes afterwards.
3. Undesirable (inconsistent) effective final kerning although the raw live kerning was correct. This is because the class and glyph kerning compression is somewhat lossy. Like in other lossy compression systems, you get compression artifacts that are undesirable but inevitable under the given size restriction.
https://help.fontlab.com/fontlab/8/tutorials/calfonts/3. Fitting and Spacing/3d-2 15 Second Autokerning/
‘Comparable functionality’ would be okay, but since Tim has done all the work in inventing these tools, I am more interested in figuring out ways to fund their adaptation to FontLab’s scripting API.