Kerning groups and missing glyphs

[federicoparra]

I've been testing Kern On and see a lot of potential in this plugin. I know it might be a bit contradictory but I think it would be nice to retain control over the kerning groups prior to use Kern On (e.g. I would like to have the same kerning for different accentuated A's). I was also wondering how to include characters that Kern On seems to ignore, as the .case variations? I know that I could add "User-set autopairs" but I'd have to add each possible combination.

[Tim Ahrens]

Regarding the missing kerning for the .case variations: They should be generated automatically. What are the pairs you would expect to be generated? Do you have the case feature defined? To determine which pairs are necessary, Kern On applies the OT features in the font, just like they would be applied when the font is used. It ignores the glyph names. Sorry, this information is not in the initial tutorial as I tried to keep it short. I’ll cover it in the next, more in-depth video. Hope this helps for now!

As for the kerning groups, sorry, Kern On doesn’t let you set them manually. One less thing to worry about! Before you push the Kern On button, all pairs are glyph-glyph pairs, and the classes are generated only as the very last step.

The reasoning when generating kerning classes is:

• Ensure the given kerning data size is not exceeded, and
• Optimize the kerning so that the important pairs are exported, and have a value close to the ideal value (the precise value determined by autokerning). So, the algorithm aims to minimize the sum of all errors (error means missing pairs or values that deviate from the ideal), considering the pairs’ frequencies.

The result sometimes looks a little unusual for human eyes but keep in mind that the aim is not to have pretty-looking kerning groups, but good results when the font is used.

In the final kerning, are there any pairs you are unhappy with? Anything missing? Any wrong values? Just let me know and I’ll investigate.

[federicoparra]

It works pretty well after updating the features, as you mentioned. As @Gini did, I also added some pairs with "dcaron" and "lcaron" (mainly accentuated letters) but probably there are no words with those occurrences. One thing that I feel could be useful is the kerning pairs of ".numr" and ".dnom" with "fraction", since this is how I generate fractions.

[Tim Ahrens]

Agreed, the pairs necessary for the fractions would be helpful. Maybe this should be generalized to include all ligature-type composites in the font? I’ll put that on my list.

[Philip L]

When two glyphs have the same base, why would it result in a bigger kerning data size when putting them in the same kerning group? A font export doesn’t split them into glyph-glyph kerning pairs. I haven’t understood the reason why excluding them then so far. Do I worry too much about strange type setting and strange proper names let’s say? Or maybe I need to understand better why (statistically) the KO logic is better. Is the data base and the resulting extent still bigger than I think or than a classic manual group kerning. Sorry, I ought to worry less, but so far the result does not match my expectations so easily. Hopefully I’ll get more into it (without studying or spamming the whole forum).

[Tim Ahrens]

> When two glyphs have the same base

I assume you are referring to two accented glyphs with the same base letter? Since they do not have the same shape (including the accents), combining them in the same kerning group usually leads to additional glyph-glyph pairs (exceptions) while eliminating the cost of one subtable row or column. In total, this may use more space, it may use less space.

> A font export doesn’t split them into glyph-glyph kerning pairs

If you have group-to-glyph kerning pairs (which KO does not generate) then they are expanded into glyph-glyph pairs on export.

> Do I worry too much about strange type setting

Not sure I understand what you mean.

> strange proper names

Are you referring to the names of the kerning groups? They are completely ignored when the font is exported but KO uses the dominant glyph as the basis for the group name so as to quickly give the user an idea of the group members.

> Is the data base and the resulting extent still bigger than I think or than a classic manual group kerning.

Sorry, can you explain in more detail what you mean?

[Philip L]

Thank you for the reply.

> combining them in the same kerning group usually leads to additional glyph-glyph pairs

Okay, too many questions here. I guess for now I skip that part where I try to understand the kern subtable. Google and FontTableViewer couldn’t help me.

> strange type settings

I mean character combinations that the KO character pair data base does not cover. “Proper names“ are just an example of potencial unusual combinations. But I begin to understand the KO character pair data base. If the KO result still covers many more other important kerned character pairs within the same data size than a classic (and kerning group based) kerning process, then it should be fine.

> Is the data base and the resulting extent still bigger than I think or than a classic manual group kerning.

I can see that the KO character pair data base is big. I imagined that the result of kerning with KO is still excluding relevant pairs when using the font. In former projects (with less characters) I used Kernkraft, checked all vector-based and some component glyphs and was lucky with the result. The GPOS table had no error when exporting the font. Now using KO the glyph pairs become mathematically more balanced, but i need to limit the kerning data size and the extent of the result excludes glyph pairs. I don’t know if a classic kerning for my current project would exceed 36 kb of kerning data or if I would have to exclude some pairs to respect the same kerning data size. Maybe KO kerns letter-symbol combinations where readers are used to quirky spaces? Especially in special spacing, I would say, we are used to condone a space being 15 units off (in a 1000 unit em) or so. So what if the KO character pair data base prioritizes letter-symbol combinations (found in wikipedia articles and twitter tweets) over letter-letter combinations existential to minorities? Regarding my question, all the special cases I mention, are they covered by a KO result compared to the result of a classic kerning as mentioned above of the same data size?

[Identity-Letters]

I will jump into this thread, I also have a problem with .case symbols, that are only generated perfectly with a high kb limit, which results in a larger filesize.

I am talking about a simple sans serif, ca. 750 glyphs (Latin only, no Small Caps)

guilsinglright.case V gets kerned with a 24kb limit.
V guilsinglleft.case gets not kerned with a 24kb limit; even with a 36kb limit it's not kerned. With 48kb it's kerned, it might already be kerned with 37kb though.

But then I take a look at the brackets and see, that bracketleft.case V is kerned, while V bracketright.case is not kerned, although the shapes are symmetrical. I need to set the kerning filesize to more than 56kb, that its getting kerned symmetrically. At a 60kb filesize it gets kerned. (It's hard to see, it's neon green)

I know, the "normal" users won't see any difference, but I can see it. Are .case symbols that unimportant within the logic?

Setting the limit to 60kb results in a quite high font-file size.

Filesize without kerning:
Static Fonts: 66 kb
Variable Fonts: 170 kb

Filesize with KernOn set on 60kb:
Static Fonts: ca. 126 kb
Variable Fonts: 428 kb

I know I can run "Remove Small Kerning" from Mekkablu, but this won't solve it.

[Tim Ahrens]

Some thoughts on the questions you raised:

[...] which results in a larger filesize.

[...]

Filesize without kerning:
Static Fonts: 66 kb
Variable Fonts: 170 kb

Filesize with KernOn set on 60kb:
Static Fonts: ca. 126 kb
Variable Fonts: 428 kb

It seems you are referring to uncompressed desktop fonts? The file size of uncompressed fonts is completely irrelevant, don’t you think?

guilsinglright.case V gets kerned with a 24kb limit.

I realized that the number of pairs generated by the case feature is typically rather small, so I bumped up the factor internally a bit. In future, this will make them more likely to survive the final kerning generation (at the cost of omitting others, of course).

Another thought: Maybe your font has more non-zero pairs than necessary? If it is a typical sans then you can check e.g. whether there are any non-zero kerning pairs for the H or for the left side of h, or right side of d. The “Pairs” drop-down menus will help you check this, and possibly identify glyphs that need sidebearing adjustment so as to be un-kerned against the flat sides. This may reduce the overall number of pairs that need to be written into the file, and Kern On will fit more of the rare pairs in.

But then I take a look at the brackets and see, that bracketleft.case V is kerned, while V bracketright.case is not kerned, although the shapes are symmetrical.

That’s an interesting question. I agree that having neither of these pairs may be better than only one of them. However, Kern On currently does not detect symmetry, so things like these cannot be implemented easily.

To be honest, though, do you know of a real-world example in which {V} would be used (with an active case feature)?

Are .case symbols that unimportant within the logic?

No, Kern On considers all kerning pairs to be important. It never omits a pair because it thinks it is unimportant, only because it thinks something else is more important. We don’t have an output that tells us which other pairs would be omitted if certain pairs were included but I am sure you would consider them to be important, too.

[Identity-Letters]

Thanks for the explanation.

[quote="Tim Ahrens" post_id=10487 time=1741286779 user_id=2]
To be honest, though, do you know of a real-world example in which {V} would be used (with an active case feature)?
[/quote]

No one will notice, only the actually type designer or any other type designer, who opens the file within a font editor. Even in a word like {WOW} with active case feature, I doubt that any real user will notice that. And in a word like {WONDERFUL} this problem is completely irrelevant.

I advertise within the promo images, that the font contains Case Sensitive Forms. So I want this feature to work well. When ›V is kerned, V‹ also needs to be kerned. As you said, either both sides are kerned, or neither. That's the problem.

I am looking forward for the update.

[SCarewe]

I would also like to add my mustard to the discussion, since this is something that comes up regularly when I work on client projects. My main question is why .case variants are treated as less important than their normal counterparts. I would expect them to be treated with the same importance. Are OpenType features treated with differing importance? As in, are .ss variants treated with a higher importance in regards to the base glyphs than .case?

To follow up on the question about whether there were a lot of non-zero pairs in Moritz' project: Yes, especially for symbols/parentheses, but even after I cleaned those up, the missing kerning for .case variants was there. questiondown.case–W is of course a very obscure pair (can only occur in Spanish, which doesn't natively have w, and the only words that start with a w are loanword nouns, which in Spanish are almost always preceded by an article). However, brackets are somewhat more frequent. This is reflected by Kern On kerning the normal variants, so I really just want to know why OT-feature-invoked variants are treated with (much) less importance.

One thing that I have been longing for for a long time is a lower limit for kerning pair size. I personally don't need kerning pairs under 5 units (and I remove these from exports anyway). Kern On thinks that 2 units are important. Being able to define a lower limit would free up a lot of space for (in my eyes, and those of a lot of others I have this conversation with) more important pairs.

Thanks for any insights!

[Tim Ahrens]

I would also like to add my mustard to the discussion, since this is something that comes up regularly when I work on client projects. My main question is why .case variants are treated as less important than their normal counterparts. I would expect them to be treated with the same importance. Are OpenType features treated with differing importance? As in, are .ss variants treated with a higher importance in regards to the base glyphs than .case?

First, the facts:

• Unicode-based pairs have 2.6 times boosted importance compared to those derived from OT features, as we can expect them to occur much more often.
• case and *num have 2 times boosted importance compared to other pairs derived from OT features.
• cvXX-based pairs also have 2.6 times boosted importance.

Ok, I admit this is a little bit of cheating, the real factors are 1, 0.75 and 0.375. (These are the numbers of the upcoming version, the previous ones were 1, 0.75 not including .case, and 0.25). The result would be identical, of course. But it sounds so much better if we say that a certain group of pairs are particularly important to us, doesn’t it? After all, nothing in the font is unimportant to me!

The problem is that users sometimes think Kern On considers certain pairs unimportant but that’s not the case. It fits in a given number of pairs, and it has to discard the rest of the queue. The question is, how to sort the queue? We cannot simply says, “but all pairs are important to me!”. This is not how it works.

When the user examines the final kerning of a particular group of glyphs, say, case-sensitive punctuation, then in that moment these pairs appear very important to them. Any missing pair causes a “Boo, that would have been important!”. Right now, I only care about the .case pairs! Let’s take a step back and consider the font as a whole.

When we think of the whole font, I firmly believe that the general factor of 0.375 is not too low. I’d contradict if you say that .case-based pairs should have the same importance as their regular counterparts. Always keep in mind that we are not taking about additionally keeping them. There is always a price to pay by omitting other pairs (and I suspect you’d call these discarded pairs “equally important” if we knew which ones they are).

At JAF, we have been making fonts here for a long time and it is very clear now that hardly anyone uses OT features anyway. It’s not worth discarding regular pairs so as to improve the kerning accuracy of feature-based pairs. Much less usage justifies much less importance, that’s the general principle.

We don’t want to sacrifice optimal kerning for the Unicode-based characters so as to include some more .case-based pairs (which is essentially your request).

One thing that I have been longing for for a long time is a lower limit for kerning pair size. I personally don't need kerning pairs under 5 units (and I remove these from exports anyway). Kern On thinks that 2 units are important.

No, it doesn’t consider 2 units (at which UPM?) important. Importance is always a combination of value error (if omitted) and frequency.

Being able to define a lower limit would free up a lot of space for (in my eyes, and those of a lot of others I have this conversation with) more important pairs.

No, removing small class kerning pairs would not free up any space whatsoever. Of course, you already know all this as we have been through this many times before.

[SCarewe]

I really do understand where you're coming from, especially about (supposed) space saving by omitting small class kerning pairs. This might be my own imagination, but can I ask what Kern On does if it finds that a class kerning pair in all masters is very small? Does it omit it? If so, what is the threshold logic? My described 5-unit lower limit is for 1000 UPM.

My (maybe too naïve) logic is the following: if I have a kerning pair of -60 units for, let's say, /questiondown.case/W, I would prefer it stay in the final font rather than a kerning pair of +3 even for a combination such as /n/o. Does a weighting of kerning pair size (which I would consider a measurement for importance) make sense?

Concerning the rest of what you wrote: I really am the first to defend your approach and principles of "consider the final font, not what looks pretty in Glyphs". There are just some recurring things (that I get from clients) that do really seem non-negligible to me, and (omitted) kerning of OT variants are a very often-cited issue. Not to be mean, but in some cases this is why clients preferred Igino's algorithm in the end. Don't kill the messenger ;) Thanks in any .case for your explanations!

[Tim Ahrens]

Oh, I see, this means I am creating Kern On, and make decisions, effectively not only for my users but also for my users’ clients. Which makes communicating these things a little more difficult.

but can I ask what Kern On does if it finds that a class kerning pair in all masters is very small?

I’ll share a bit of my secret code here:

Code: Select all

	// returns the error if the value was reference_value
	// instead of the ideal value as is now.
	// return value is always positive or zero
	double
	deviation_from( double reference_value ) const {
		double deviation;
		if ( reference_value < value ) {
			// reference_value too low
			deviation = value - reference_value;
			if ( reference_value >= 0.0 ) deviation *= FACTOR_FOR_POS_TOWARDS_ZERO;
			if ( reference_value < value_min ) {
				// outside span
				deviation += ( value_min - reference_value ) * PENALTY_FOR_OUTSIDE_SPAN;
				auto negative_outside_span = std::min( VALUE_ZERO, value_min ) - reference_value;
				if ( negative_outside_span > FRONT_TOLERANCE ) {
					deviation += negative_outside_span * ADDITIONAL_PENALTY_FOR_NEGATIVE_OUTSIDE_SPAN;
				}
			}
		}
		else {
			// reference_value too high (or perfect)
			deviation = reference_value - value;
			if ( reference_value <= 0.0 ) deviation *= FACTOR_FOR_NEG_TOWARDS_ZERO;
			if ( reference_value > value_max ) {
				// outside span
				deviation += ( reference_value - value_max ) * PENALTY_FOR_OUTSIDE_SPAN;
			}
		}
		return deviation;
	}

	inline value_t
	rounded_value( value_t threshold = NO_VALUE_POS ) const {
		if ( value == 0.0 ) return 0.0;
		// ^ performance only
		auto value_up = ceil( value );
		auto value_dn = floor( value );
		if ( threshold != NO_VALUE_POS ) {
			push_dn( threshold, std::max( value_t(0.625), value_max - value_min ) );
			// ^ this means when the value is well-defined (e.g. shapes identical to a model)
			//   then we may have a small rounded value like -1
			if ( has_manually_set_value() ) return round( value );
			// ^ this could go all the way up but it is not necessary
			if ( value < 0.0 ) {
				push_dn( value_dn, floor( - threshold ) );
				if ( value_up > - threshold ) value_up = 0.0;
			}
			else {
				push_up( value_up, ceil( threshold ) );
				if ( value_dn < threshold ) value_dn = 0.0;
			}
		}
		if ( deviation_from( value_up ) < deviation_from( value_dn ) ) {
			return value_up;
		}
		else {
			return value_dn;
		}
	}

Just to give you a glimpse that many things in the tool are really much more complex than what it may seem at first. I am really trying hard to get the best possible result by applying all kinds of considerations. The above code is purely for the task of rounding the pair’s value while applying a threshold. Not exactly a one-liner, is it? FWIW, the current default threshold is 2.0 but as you can see, it’s not that simple.

[Tim Ahrens]

My (maybe too naïve) logic is the following: if I have a kerning pair of -60 units for, let's say, /questiondown.case/W, I would prefer it stay in the final font rather than a kerning pair of +3 even for a combination such as /n/o.

Sorry, I disagree. I’d rather keep a 3-unit value for /n/o then a -60-unit value for /questiondown.case/W.

Keep in mind that characters that have special spacing are more tolerant to missing negative kerning: Without seeing something like a /questiondown.case/H next to it, who is going to tell that an unkerned /questiondown.case/W is too loose, considering that the right side of the /questiondown.case is intentionally spaced more generously anyway? Kerning is all about consistency, and an unkerned /questiondown.case/W will not necessarily appear as inconsistent if the context is missing or far away.

The upcoming Kern On version will apply this reasoning even a little more than previously.

Does a weighting of kerning pair size (which I would consider a measurement for importance) make sense?

Of course, the importance is weighted. This is what I meant when I said that importance is always a combination of value error (if omitted) and frequency. To be precise, it’s the product, and the frequency even gets another added constant so as to further boost the importance of nominally rare pairs, to increase the influence of the value over the frequency. The “value error (if omitted)” is not simply using the value of the pair, although effectively very similar. The code above gives you an idea of how it is calculated in detail.

[SCarewe]

(I still don't understand how to properly quote in this forum)

> Sorry, I disagree. I’d rather keep a 3-unit value for /n/o then a -60-unit value for /questiondown.case/W.

Then this is probably the crux of the matter, as it is a matter of opinion. I can see good arguments for both opinions, as voiced in this and many other threads. It's probably so fundamental and polarising that it's not possible to incorporate both into Kern On. Not that this is a valid argument, but I would wager that a majority would prefer a more extensive kerning of OT variants and large kerning pairs over very small kerning pairs (that are usually a form of noise anyway). I understand you have your very well founded reasoning, and that's fine.

Just to be clear: my argument for removing small kerning pairs is twofold. In addition to saving space (in specific cases, I know), it is a question of minimising noise, even at the cost of (mathematical) inconsistency. Clients will often complain about having tiny kerning pairs in useless places (pairs that usually don't need kerning, but receive minute kerning pairs). For such fundamental pairs, and generally as a whole, I would like to suppress small kerning pairs.

Maybe you can ask some users at Fontstand in your workshop. In any case, I look forward to hearing some more insights from you then.

[Tim Ahrens]

Can you explain what exactly “noise” means in this context, and what the disadvantage is, from a rational point of view?

[Tim Ahrens]

Btw, I just published a Kern On update: https://kern-on.com/update/

• Special-spaced pairs are more likely to be zero. Less noise!
• BIG news: autospacing is now persistent! This makes it easier to avoid unnecessary or accidental small kerning pairs against the “neutral sides” such as the flats in sans-serifs. Less noise!
• Increased factors for feature-based pairs (as mentioned above). This makes it more likely to include pairs for rarely used features. Instead, Kern On will usually omit small kerning pairs for real, Unicode-based pairs. Less noise!

[SCarewe]

Gosh, that was extremely rapid. Thanks for the update! I really didn't mean to pressure you into straying from your principles, you have your good reasons.

What I mean by noise: tiny kerning pairs that are generated by Kern On for pairs that usually shouldn't require kerning, and thus perturb anybody using the font that looks at the kerning values. However good the spacing is, there are always quite a few, even when using the autospace feature of Kern On a lot to appease the algorithm. I appreciate your reactivity in this discussion and look forward to testing the new version.

[Tim Ahrens]

To be honest, not all of these were direct reactions to this thread. Persistent autokerning is something I wanted to implement for a long time.

I was going to write, the main crux seems to be irrational users who like things pretty under the hood... but, things a a little more complex, once again.

So, I am dealing with rational or irrational users, who may have rational or irrational clients (foundries), who make fonts for rational or irrational users. If “anybody using the font that looks at the kerning values” includes Indesign users (or similar) then that changes things. It may be reasonable for a foundry to issue fonts with prettified kerning, so as to please irrational font users. You are getting me close to the point of saying, dammit, I’ll make Kern On write prettier kerning.

BUT... it’s a a little more complex, once again:

1. For Desktop fonts, there is a risk of annoying font users with “noisy” kerning. For Webfonts, there is currently no common scenario that users inspect the kerning, AFAIK. So, we do not need the same strategy there.

2. For static fonts, interpolation will destroy most of our prettification. Even if all masters are quanitzed, nice and pretty, and with a generous threshold, this would still typically lead to messy interpolated kerning, including small values, unless the prettification operates cross-master. Getting prettification that survives interpolation is not so easy, I suppose.

Maybe what we need is prettification on export, for each instance, and taking into account desktop vs web, and static vs variable.

I’ll start developing an export filter to take care of that, maybe KO-branded, this seems the only sensible approach. Maybe we can get irrational KO users (or your clients) to accept untidy kerning in Glyphs if they know it will be prettified on export?

[SCarewe]

I entirely admit that none of these arguments brought forward are rational from a practical point of view. As you pointed out, you're catering to opinions instead of entirely rational end users. That is, I'm afraid, something we can't really change.

Concerning your point about interpolated small pairs: absolutely, and this why I have an export filter built into my workflow that removes all kerning pairs below 5 units (at 1000 UPM) for each instance, instead of just in the masters.

You can find it here: www.github.com/eweracs/remove-small-kerning-pairs

Users can simply add it as a custom parameter to exporting instances.

This of course makes the static files not entirely congruent with the variable font exports, but I don't see that as a real-world problem.