Locking existing Kern-On data

Post Reply
aaronbell
Posts: 5
Joined: 19 Nov 2021

Locking existing Kern-On data

Post by aaronbell »

Given that Kern-On re-generates all kern data whenever it runs, I wonder about what will happen if I am updating an existing font project with additional glyphs. In particular, I'm concerned that the kern data could change if the program interprets something differently, leading to a break in backwards compatibility.

While that might not be a major issue for some projects, some clients require metrics to remain identical across versions.

It would be useful to be able to "lock" or "preserve" existing kern data in the font to protect it while still running Kern-On on any un-kerned glyphs.
User avatar
Tim Ahrens
Site Admin
Posts: 284
Joined: 11 Jul 2019

Re: Locking existing Kern-On data

Post by Tim Ahrens »

Hello Aaron, yes, extending existing, kerned fonts is something Kern On does not handle well yet. It’s definitely something I want to take care of as it’s a reasonable scenario to assume. So, expect some support for that in the future.

One feature I want to implement in any case are “bubbles”, i.e. allowing to split the font into separate glyph sets, each of which is in an independent bubble in terms of kerning, and there would be support for manual bubbles, like current “independent” pairs but for a whole set of glyphs, including the kerning and classes. I suppose that would not be perfect for extensions, though? You would probably want to kern the newly added glyphs against the old ones.

This practically means Kern On would have to retain the existing classes (kerning groups, as Glyphs calls them). As you know, KO simply erases all pre-existing groups as it starts up, and strictly works with glyph-glyph pairs while it is running. Could Kern On support user-set kerning groups? After all, Kern On has to look at shapes, and it can only use the shapes of specific glyphs (we can’t rely on the shapes being identical for all glyphs in the group). I have thought about this since I started working on KO and always I considered it impossible but funnily, as I thought about how to best explain this here, I realize it may indeed be possible somehow. With user-set groups, Kern On would still think in terms of glyph-glyph pairs internally, and the user could still only specify glyph-glyph model pairs – but they might indeed be class kerning pairs, which means all the other glyph-glyph pairs covered by that pair would become non-editable, implicit independent pairs. Sorry, just thinking out loud.

So, TL;DR: It’s not a piece of cake if you think it through completely, but I am motivated, and think it will be possible, to add proper support for extending existing fonts at some point.
aaronbell
Posts: 5
Joined: 19 Nov 2021

Re: Locking existing Kern-On data

Post by aaronbell »

Thanks for the reply Tim!

The bubbles approach does sound like it would be useful when dealing with scripts that have markedly different characteristics (or situations where one should have no kerning and another does).

> (we can’t rely on the shapes being identical for all glyphs in the group)
This is an interesting point, though I actually sort of wonder if it matters. If a designer, for whatever reason, decides that two glyphs should be in the same kern group, even if the shapes aren't identical, then Kern-On can just use one of the glyphs in the set and ignore the rest.

In the mean time, I suppose I can probably just keep a copy of the old kern data and copy it overtop of the new kern data? That should work, I think.

Speaking of class kerning, a separate question I've been thinking about—I've observed that sometimes Kern-On doesn't produce fully-optimized kern classes. For example, in a current font, 'e' and 'eacute' are being kerned separately despite having an identical left side. In wondering how to reduce the number of kern pairs that Kern-On produces, I've thought about having some sort of mechanism for users to 'preview' the classes that Kern-On produces and modify them based on the users' perception of the design. One could certainly do this sort of modification after Kern-On runs (and that's probably what I'll do on this current project) but building it into the tool would allow for more control over the output.
User avatar
Tim Ahrens
Site Admin
Posts: 284
Joined: 11 Jul 2019

Re: Locking existing Kern-On data

Post by Tim Ahrens »

aaronbell wrote: 16 Nov 2022 for whatever reason, decides that two glyphs should be in the same kern group, even if the shapes aren't identical, then Kern-On can just use one of the glyphs in the set and ignore the rest.
Yes, one would try to keep the UI as simple as possible, and to support the designer’s thinking that the pair in question is simply a class-class pair. On the other hand, somewhere in the code, this single glyph-glyph pair would have to be picked internally, we can’t tell the computer to “just use one”. Also, in case of a red-dot model contradiction message, it may be easier for the user to understand if the exact glyph-glyph pair is mentioned.
aaronbell wrote: 16 Nov 2022 In the mean time, I suppose I can probably just keep a copy of the old kern data and copy it overtop of the new kern data? That should work, I think.
The problem is that the copy-paste only works if the kerning groups (i.e. kerning group names) match, even if their members are the same. If your old kerning includes a pair @v-@o, but KO decides to name the class @e instead of @o (either makes sense, of course) then you will have invalid pairs.
aaronbell wrote: 16 Nov 2022 in a current font, 'e' and 'eacute' are being kerned separately despite having an identical left side.
First, I should mention that with yesterday’s release (version 1.18), the class kerning should be much closer to what designers would do manually, i.e. hopefully what they expect.

It’s not necessarily better to put e and é into the same class, though. They don’t have an identical left side, after all. A good number of pairs, such as Te vs Té, may be different. Now the question is whether to pay for an extra vector (vector = “row or column”) in the subtable(s), which costs 2 bytes per cell (plus overhead), or to merge the two vectors and have some additional exceptions (glyph-glyph pairs), which costs 4 bytes per pair (plus overhead). Generally speaking, if the two vectors are rather dense and/or have significant differences, merging is less efficient. If they are sparse, i.e. we have many unused cells, and/or they are rather compatible, merging them is better. Of course, Kern On calculates this for every possible merger, and then decides how to optimize things.
Post Reply