Opening Kern On *immediately* deletes all group data from all glyphs, unless it is re-run.

Post Reply
stephennixon
Posts: 13
Joined: 18 Jun 2021

Opening Kern On *immediately* deletes all group data from all glyphs, unless it is re-run.

Post by stephennixon »

First off: I love the plugin, and I'm excited to be trying it in a bigger project! I'm glad I can help surface issues that will hopefully make future versions even better. So:

I've just noticed that opening Kern On immediately deletes all group data for all glyphs in a font, *as soon as Kern On is opened,* unless kerning is re-run.

Would it make sense to change so that groups are only deleted/overwritten once Kern On is actually "run"? This would seem to be a more intuitive, less destructive pattern for the plugin.

Or, is there a reason Kern On must delete all groups as soon as it opens up?

Context: a collaborator on a project just made a few glyph adjustments (spacing and outlines), then opened up Kern On (presumably to inspect whether something was a model, or make something independent, etc), and then closed Kern On, thinking that nothing would change, as they didn't deliberately make any changes. However, when they then went to commit the intended outline changes, they realized that all kerning groups had been removed. So, we now have to recover or redo their intended changes from a very messy commit.

(In general, a wish I have for KO is that it allowed a more incremental workflow... it is kind of stressful that every time we make an adjustment and rerun it, then kerning in the font is completely different. This means that it invalidates a workflow of proofing, then fixing specific kerning issues... because the next proof has entirely new kerning, and may have entirely new issues. Or is there a non-obvious way to work more incrementally? Is there a way to get some kind of summary of how kerning was changed from one run to the next? Thanks for any insights!)

- Kern On version 1.16
- Glyphs Version 3.1 (3133), using a .glyphspackage file format.
User avatar
SCarewe
Posts: 73
Joined: 23 Apr 2021

Re: Opening Kern On *immediately* deletes all group data from all glyphs, unless it is re-run.

Post by SCarewe »

While I cannot give you a professional reasoning as to why or whether KO needs to remove all groups, I would say the main reason is simply the logic behind KO, that the only important thing for the kerning are the models, and the kerning is calculated "live" (also in edit view, all the time) while KO is active. Kerning behaviour can change from update to update, so it makes little sense to keep the old kerning data when KO is open.

I would recommend not to use KO for actually inspecting a file, for exactly the reasons you described. I wrote some scripts in order to facilitate proofing KO setups:
https://github.com/eweracs/glyphs-scrip ... ter/KernOn
They are not terribly extensive, but for checking models, models including the current glyph, it should be sufficient. I'm happy to add more scripts if you are missing some (the "add independent" is a great idea!).
User avatar
Tim Ahrens
Site Admin
Posts: 284
Joined: 11 Jul 2019

Re: Opening Kern On *immediately* deletes all group data from all glyphs, unless it is re-run.

Post by Tim Ahrens »

Thanks for your kind words!

Sebastian’s explanations are very good (thanks for the script btw!) but I’ll try to dig in a little deeper.

Regarding your issues, I understand the problems you are facing but it’s not easy to improve things from my side:

As Kern On starts, it deletes kerning groups as well as all autokerning. So, in order to make it safe to start and close Kern On it would have to preserve the classes and the kerning. What if the autokerning is outdated (because the user has changed spacing or glyph shapes while KO was sleeping)? As a user, I’d assume that whatever I see while KO is running is up-to-date. It could be frustrating and confusing to find out that some autokerning changes just because I have set an independent pair.

Also, retaining classes as Kern On starts would practically mean user-defined classes (it does not matter whether the classes are the old ones by Kern On, or manually set). I thought about supporting user-defined classes but it’s practically impossible. If you set a class-class pair as a model, which of the implicit glyph-glyph pairs is to be considered the model? Also, if you display the kerning for a class-class autopair on-the-fly you’d have to generate all the implicit glyph-glyph pairs, then determine the class value and exceptions, oh wait, for which kB size, and we haven’t kerned the complete font yet.

So, while Kern On is running there can only be glyph-glyph pairs, I am afraid.

stephennixon wrote: 23 Aug 2022 [...] it is kind of stressful that every time we make an adjustment and rerun it, then kerning in the font is completely different.
[...]
Is there a way to get some kind of summary of how kerning was changed from one run to the next?
This is exactly what the “Compare to” button is for. Just open the old version alongside the current one and use this function. It will show you an overview of the changes. It tries to avoid showing very similar pairs, and it favours the greater changes and more frequent pairs.
stephennixon wrote: 23 Aug 2022 This means that it invalidates a workflow of proofing, then fixing specific kerning issues... because the next proof has entirely new kerning, and may have entirely new issues.
Which issues are you referring to?

I believe proofing the complete kerning of a font (family) in a water-tight way is nearly not feasible as it would take too much time. Working with Kern On simply requires some level of trust (not because I tell you “trust me” but because after working with it, you get the impression it is reliable).
stephennixon
Posts: 13
Joined: 18 Jun 2021

Re: Opening Kern On *immediately* deletes all group data from all glyphs, unless it is re-run.

Post by stephennixon »

> Thanks for your kind words!

Well deserved! I do want to point out that I am being nit-picky as a designer and as a fan of this product. I realize that building something like this requires a lot more complexity than I am currently capable of, and I don’t understand all the constraints that you are dealing with. Major kudos!

> it’s not easy to improve things from my side

Thanks for the explanation ... I get that the logic behind the tool would make it difficult to do anything else, and I don’t really know what limitations you might have, working as a Glyphs plugin.

But, just as an example, I think a more-ideal user flow would be, if I hit the "X" to close Kern On without running a full Kern On kerning, I understand that it might throw out some computational work that Kern on was doing while it was open. So, a normal app might say, "Are you sure you wish to close without saving your changes?" The KO equivalent might be something like, "Close without generating new kerning? This will lose any changes you may have just made." ...or similar.

This may not be the only solution! I am basically reacting to the surprising nature of it removing classes without a clear indicator of this, and relaying the info that it was confusing myself and a collaborator for a couple of weeks. We thought it might be a Git problem, or a Glyphs problem, or a Glyphs + Git problem... but it turned out, it was just that we thought we could pop open KO sometimes, and only run it occasionally, such as when we wanted to run a full build. So, potentially the simplest short-term solution would just be to somehow highlight to the user that data has been deleted, and a full run is the only way to move on without losing a bunch of classes. Perhaps a little top banner that says something like, "Kerning classes removed – please run Kern On to generate updated kerning."

> This is exactly what the “Compare to” button is for.

Ah, cool! Makes sense. I suppose that would require me archiving a copy of my Glyphs file before opening up KO, which is a bit inconvenient, but if that is the current workflow requirement, that is still a helpful ability to have!

In the future, a wish-list feature would be a more automated summary of what has changed with a new run of Kern On. Because, like... I can’t open KO to compare current kerning against previous kerning, without deleting current kerning and re-running KO to make new kerning. Or am I missing something in the comparison workflow?

> Which issues are you referring to?

I just end up running into surprises as I am in the kerning and proofing process. Like, sometimes a pair like a serif "It" will be over-kerned, and need a model. Or sometimes, punctuation ends up crashing into other stuff. It’s not necessarily an "issue" in the sense of a "bug," but more that adding models in one place inevitably adds kerning in other places, and it might not be the kerning I want. So, part of the desire to work incrementally and to have clear readouts of what has changed is just to be able to trust that the font is improving as a whole, and to know if there are changes worth looking at. I trust that KO is obviously made with good intentions, but I don’t necessarily trust that it can read my mind and do only what I want, without adding in things I may not want.
stephennixon
Posts: 13
Joined: 18 Jun 2021

Re: Opening Kern On *immediately* deletes all group data from all glyphs, unless it is re-run.

Post by stephennixon »

Oh, also, @SCarewe – thanks for sharing your scripts! These look really handy and informative. I’ll try to dig in a little deeper!
Post Reply