Prioritise kerning by kern value

Post Reply
User avatar
SCarewe
Posts: 71
Joined: 23 Apr 2021

Prioritise kerning by kern value

Post by SCarewe »

Good afternoon,

In addition to limit kerning by file size and prioritising pairs by frequency, I find it would make a lot of sense to be able to set a lower threshold of kerning values bewlo which KO shouldn't kern. Our current production workflow is based around the way KO limits kerning by file size and simply stops kerning once this is reached – meaning we remove small kerning pairs after KO has finished in order to reduce file size.

This means that, theoretically, a lot of kerning pairs are "wasted" in the sense that they are not considered by KO due to the file size restriction. Using a combination of file size cap and lower threshold of kerning values would make the final kerning a lot more efficient.

Does this make sense and would it be feasible to implement? Many thanks!
User avatar
Tim Ahrens
Site Admin
Posts: 264
Joined: 11 Jul 2019

Re: Prioritise kerning by kern value

Post by Tim Ahrens »

SCarewe wrote: 22 Nov 2021 In addition to limit kerning by file size and prioritising pairs by frequency, I find it would make a lot of sense to be able to set a lower threshold of kerning values bewlo which KO shouldn't kern. Our current production workflow is based around the way KO limits kerning by file size and simply stops kerning once this is reached – meaning we remove small kerning pairs after KO has finished in order to reduce file size.
Are we talking about webfonts or desktop fonts? For desktop fonts, I don’t see any reason whatsoever for trying to reduce the file size beyond the 64 kB limit.

Which limit did you set? For webfonts, I’d choose something like 8 kB, which compresses to about 2–3 kB. And it hardly creates any small values.
SCarewe wrote: 22 Nov 2021 we remove small kerning pairs after KO has finished in order to reduce file size.
Why didn’t you simply specify a smaller data size in the beginning? Did you compare both approaches? What’s the difference and in which way is your result better (if the file size is the same)?
SCarewe wrote: 22 Nov 2021 Using a combination of file size cap and lower threshold of kerning values would make
When Kern On generates the class kerning, and chooses what to omit to stay under the given data size, it considers the value and the frequency. In fact, the threshold it determines internally is about abs(value)*sqrt(frequency). So, the value is already the dominant metric (plain vs sqrt), the frequency is secondary.
SCarewe wrote: 22 Nov 2021 efficient.
I don’t think efficiency – without any further given constraint – is a practicable concept in this case. In the beginning, the class generation algorithm was centred purely around the concept of increasing efficiency but it didn’t work out, so I moved to a given data size limit as the starting point. Of course, the algorithm as it is now does optimize the efficiency (to be precise, that’s all it does) but it does so on the basis of a given data size.

Again, are we talking about webfonts or desktop fonts? There’s a completely different reasoning in each case.
User avatar
SCarewe
Posts: 71
Joined: 23 Apr 2021

Re: Prioritise kerning by kern value

Post by SCarewe »

Hello, sorry for not getting back to you on this. I have been trying to find the right balance for Kern On to kern a font with a sensible balance of kerning pairs and pair size. Today, for instance, I set the file size to 6kB, but found that Kern On was still kerning pairs at ±2 units, which I don't see as a sensible value in smaller file sizes. Over the 5 masters, only 1,500 kerning pairs were generated.

I completely understand your arguments. Quite simply, where I work at it is the rule to omit kerning below 6 units, but while still having a comfortable amount of kerning pairs. Is it not feasible to add a lower threshold entry below which a pair is simply skipped? Many thanks as always!
mumchristmas
Posts: 3
Joined: 14 Dec 2021

Re: Prioritise kerning by kern value

Post by mumchristmas »

A simple script to clean the tiny pairs will work.
User avatar
SCarewe
Posts: 71
Joined: 23 Apr 2021

Re: Prioritise kerning by kern value

Post by SCarewe »

Yes, I know. But the original point was to tell Kern On that we don't want small kerning pairs in the first place, so KO can skip these pairs and generate more pairs instead. That's why a simple manual entry would be very useful.
User avatar
Tim Ahrens
Site Admin
Posts: 264
Joined: 11 Jul 2019

Re: Prioritise kerning by kern value

Post by Tim Ahrens »

Sorry, still don’t understand you reasoning. May I ask again: Are we talking about webfonts or desktop fonts?
User avatar
Tim Ahrens
Site Admin
Posts: 264
Joined: 11 Jul 2019

Re: Prioritise kerning by kern value

Post by Tim Ahrens »

SCarewe wrote: 15 Dec 2021 Kern On was still kerning pairs at ±2 units
Were they class kerning pairs or exceptions? In case they were not exceptions then giving them a value of zero (instead of +2 or –2) would not decrease the file size at all.
User avatar
Tim Ahrens
Site Admin
Posts: 264
Joined: 11 Jul 2019

Re: Prioritise kerning by kern value

Post by Tim Ahrens »

Maybe I should explain this in more detail:
  • Glyph-to-glyph pairs take 4 bytes per pair, plus overhead. Therefore deleting a glyph-to-glyph pair saves 4 bytes, and possibly a little more in case it was the only one kerned to the first glyph.
  • With class-to-class kerning, we have to “pay” for the whole subtable, 2 bytes per cell, whether it is “used” (i.e. non-zero) or not. Plus some overhead for the class definitions. This is potentially more efficient than glyph-to-glyph pairs, as it’s only 2 bytes vs 4 bytes, and we can cover many more pairs if the classes contain several glyphs. However, deleting a class-to-class pair doesn’t have any impact whatsoever on the size of the kerning data, as it does not matter whether there is a zero written into the 2-byte cell, or a non-zero value. (The only exception would be deleting the only pair in a row or column, of course.) This means deleting small class kerning values is irrational, I am afraid. This also means skipping small-value (class-to-class) pairs will not allow to generate additional other pairs instead.
So, the bottom line is: Unless you perfectly understand how the kerning data is written into the font file, don’t try to optimize things. Kern On does a good job at getting the most out of your specified kerning data size.
User avatar
Tim Ahrens
Site Admin
Posts: 264
Joined: 11 Jul 2019

Re: Prioritise kerning by kern value

Post by Tim Ahrens »

Btw, the above post refers to desktop fonts, not webfonts. As I mentioned several times before, there is a completely different reasoning for the two scenarios.

If we are looking at webfonts in detail, we’d have to optimize the data size after compression. Practically all webfonts are served as woff or woff2, so the raw, uncompressed TTF size is irrelevant (although some people in the font world try to fool us by comparing raw TTF sizes when talking about webfonts). Optimizing the compressed data size of the kerning is a real can of worms, though. It’s not only about the raw data size itself, but also about the compressibility, and if we think like this then, yes, deleting class kerning pairs will indeed reduce the compressed data size (as rows of zeroes can be compressed away). I hope I will soon work on webfont kerning optimisation but it will be a lot of work and require a lot of testing, as it is far from trivial. Will keep you updated!
User avatar
SCarewe
Posts: 71
Joined: 23 Apr 2021

Re: Prioritise kerning by kern value

Post by SCarewe »

Hi Tim, thank you very much for your extremely detailed explanation. My neanderthal instinct just told me less kerning pairs = better. Quite obviously it is not like that and Kern On has all your knowledge baked in accordingly. Thanks!
Post Reply