"Blue Zone" kerning

[aaronbell]

I've been using Kern On on smaller projects to great success, but recently have applied it to a much larger project, including an extensive italic—Latin/Greek/Cyrillic with lots of alternates, variants, small caps, etc. and have been running into issues.

Where keeping KernOn to a 32kb or 64kb max kern size has worked generally pretty well, due to the significant number of glyphs in this Italic, I'm finding that a number of pairs are not making it to the final output, leading to potential undesirable spacing. Increasing the max file size up to 100kb+ helps solve this, but then the font has OT overflow when I try to build it.

As a result, I've been trying to figure out how to reduce the number of kerns so that the whole font can be generally kerned within a standard kern file size. Managing the kern groups myself has definitely helped, so that I have been able to provide at least some kern value to glyphs that might not have otherwise been evaluated by KernOn. And adding specific problematic pairs as "masters" also helps ensure they get covered.

However, I think that more could be done. An idea I had is being able to set a "blue zone" sort of thing where if the kern between letters is within XX range, KernOn will keep the kern aligned with the group kern. So like if the /adieresis and /amacron have a kern to another letter of, say, 50 and 60 units respectively, KO will just keep them both at 50. Being able to control it manually, too, would be helpful since these values will differ project to project, and UPM to UPM.

Understandably this reduces the accuracy of KO's output, but I think that in a more complex file, being able to have a lever to control the amount of kern output aside from just max file size would be helpful.

[Tim Ahrens]

What you describe is roughly how the class kerning algorithm works.

Sticking to your example, let’s assume a certain pair against /adieresis has an ideal value of 50, and /amacron has 60. If 50 is the class kerning value then, if the exception with /amacron is omitted, the deviation is 10. Multiply this deviation with the frequency of the pair (which is heavily tweaked so as not to de-emphasize rare pairs too much), and you get the “importance” of the exception. It is a bit more complex as deviation that is within the min/max span (as you can see it in the slider) is weighted less than the deviation outside the span.

All the exceptions queue up, sorted by importance.

Now, let’s assume you specified 64kB kerning size and the class kerning (at that point in the process) occupies 40kB – which is always independent of the number of cells that are actually “used”, i.e. non-zero. We’ll have 24kB of space for the exceptions, with 4 bytes per exception that’s 6000 pairs (actually somewhat fewer because of the overhead). The 6000 most important pairs will make it through to the final kerning.

This means that if the difference between the class kerning is small then the exception will be omitted unless the pair is very frequent or we have plenty of space. It is not necessary to specify such a cut-off value as the user: this happens automatically internally. In fact, this cut-off value is the means to achieve the specified kerning size.

You can send me the file if you want, then I can have a closer look and maybe we can figure out what is happening. The finalization algorithm is quite complex and I am sure there is still some potential for improvement.

[aaronbell]

Thanks for the explanation Tim! That makes a lot of sense.

Given how things work, what I had envisioned is to implement a user-specified filter into the step between where the deviations are calculated and when they are multiplied by the frequency of the pair.

That way users have an opportunity to have something of a manual "fuzziness" filter and in fonts with a significant number of pairs that need to be squeezed into the kern set, it would allow for additional space.

[aaronbell]

Any thoughts on this proposal? :)

[aaronbell]

I've been thinking about this more recently. Potentially I could implement it as a post-KO step going through the kerning one-by-one, but it would be much simpler (I think) to implement into KO directly as part of the step that evaluates the deviation between the ideal kern and the class kern, then either implement or ignore the exception.

I'd be happy to try and give a shot to implement it myself, but would need access to the source code.

[Tim Ahrens]

Sorry for not answering to your reply quicker.

a user-specified filter into the step between where the deviations are calculated and when they are multiplied by the frequency of the pair.

I don’t think being able to customize this value is necessary. It is not really a mater of taste and I believe a sensible behaviour can be found that is good for all use cases.

That way users have an opportunity to have something of a manual "fuzziness" filter

The whole class kerning compression algorithm is about “fuzziness” indeed. Keep mind, though, that the concept of “more fuzziness” or “less fuzziness” simply does not apply. The algorithm will choose the degree of fuzziness, i.e. the deviation threshold, so as to fill the given data size with pairs from the “queue” (sorted by importance), and discard the rest.

it would allow for additional space.

There is no such thing as “additional space.” The available space is given by the user. All the algorithm does it to determine the most “important” pairs to fit into this given space with as little as “lost importance” as possible.

-----

Keep in mind that with class kerning, the individual pairs are “free,” i.e. omitting a pair will not free up any space whatsoever because the table cell will simply be zero instead of the non-zero kerning value. This is why the algorithm will usually generate many unimportant class-class pairs because the “importance” question is not even applicable. The “queue”, sorted by importance, only consists of glyph-glyph pairs and we only need to decide which of the glyph-glyph pairs are to make it into the final kerning, or to be left out.

I'd be happy to try and give a shot to implement it myself, but would need access to the source code.

Sorry but the source code is a trade secret. Plus, it is fairly complex (although I believe the code is rather well-organised).