Prioritise kerning by kern value

Post Reply
User avatar
SCarewe
Posts: 45
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: 183
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.
Post Reply