Manual Mode?

[alex]

Hi Tim!

I keep finding myself aligned with what Stephen said here: viewtopic.php?t=827 : Kern On’s ability to guess the kern values is very impressive, but the fact that every launch is a new day means you have to proof *everything* after each correction, having no clue where to expect changes. At some point it starts feeling like an autopilot that only drives you home by the route it chooses whether you like it or not :)

I wonder if you’d consider adding a manual mode? Something like this:
• Don’t remove any kerning on launch
• Don’t kern on the fly
• Kern only the selected pairs with a button click
• Keep groups (kern the selected glyphs and apply it to their groups or check if any of them are exceptions)
• Kern whatever the user selects, even if it has no unicode, useless, etc.
• Maybe it could suggest inconsistencies: “TA TO now differ →”, clicking which would open them in a tab where you can repeat this process.

That would allow a more clear and controllable process, either from scratch or for correcting and proofing specific pairs after the magic do-everything button.

[Tim Ahrens]

the fact that every launch is a new day means you have to proof *everything* after each correction, having no clue where to expect changes.

This is exactly what the “Compare to” functionality is for. Just save the old version as a separate snapshot file, then start Kern On, make the changes, open the snapshot file and choose “Compare to”. This will show you an overview of the most significant changes made since the snapshot. I think it gives you a very good idea of where to expect changes. Btw, I am planning to automatically store a snapshot internally as Kern On starts up, which you can then refer to in the “Compare to” menu.

Note that the changes you will see are really the most significant changes. You may get the impression that the kerning has changed a lot even though it has stayed 99% the same, just because you are being shown the changes. You will also find that the main changes are in the pairs that are really debatable. Just because a pair has changed that does not mean it has changed from correct to incorrect. They are typically cases when either option makes sense. Try not to think that any change must be a flaw.

• Don’t remove any kerning on launch
• Don’t kern on the fly
• Kern only the selected pairs with a button click

I don’t think this would work in practice. How do you set good models if you don’t have an instant preview? Also, this may easily lead to inconsistent kerning. I firmly believe that consistency is the most important quality of a font’s kerning – in fact, consistency is what kerning is all about. If everything is kerned from the same set of models then consistency is guaranteed.

Another question is, how would you prepare the text that is to be autokerned in this batch? I’d think it would typically be hundreds or thousands of pairs. Would it be a list of pairs that is generated via script? It seems that this kind of workflow would quickly become rather messy.

• Keep groups (kern the selected glyphs and apply it to their groups or check if any of them are exceptions)

If you un-check “Re-generate kerning groups” in the finalization dialogue you should get exactly this behaviour, unless I am misunderstanding you.

• Kern whatever the user selects, even if it has no unicode, useless, etc.

You mean, based on the text selection in the edit view? I think this would be too volatile. Imagine you want to re-fresh this kerning and then you don’t remember what was selected the last time.

Instead, we have user-set autopairs. Kern On will remember them, I believe this is better than text selection.

Btw, I am always curious to understand my users’ workflows. Why would you want to kern useless pairs? Which are the pairs that you want to have kerned but they aren’t kerned by default? I am willing to add more pairs to the autokerning if it is a convincing use case.

• Maybe it could suggest inconsistencies: “TA TO now differ →”, clicking which would open them in a tab where you can repeat this process.

Not sure what exactly you have in mind but it seems to lead to a rather complicated workflow. Isn’t it more convenient, more reliable and clearer to autokern everything from the same set of models and enjoy the guaranteed consistency?