Yeah, just following up after more testing: I can't quite pinpoint what causes the filesize discrepancy to occur, but if you kern while the autosaved version is smaller, it will hang and not recover (spinning beachball)

I have noticed in one particular project with a ton of kerning (multiscript, lots of models), sometimes Kern On will hang. I have noticed that this is related to the state that Glyphs is in — depending on when I have last saved. There are cases where Glyphs will create an Autosaved version that is s...

Based on Georg's replies on the Glyphs forum is it fair to assume this is a long way off? It sounded like it would be complex for Georg to get this in the compositor font

Can either the compositor font or Kern On support OT features from within the "Replace Feature" custom parameter on static instances? That is how I make sure these features from rlig make it into OTFs. This wouldn't solve the problem for people who have variable-only fonts but I would gues...

Syntax like this is supported in Glyphs for swapping Glyphs without using bracket layers in variable fonts. This way if you have a ton of them you can see the different glyphs in the font view, rather than tucked away in layers. To do it, you can put things like this in the rlig feature: #ifdef VARI...

great - I will send you an email in the next few days!

Would it be helpful to have specific examples of this as OpenType feature code (and/or Glyphs specific format for VF), so that a suitable UI could be worked out from there?

Thank you!

Tim Ahrens wrote: > No, this is a separate feature. It is called “Sync kerning types from”, > also in the (•••) menu. “Kerning type” means special spacing, standard > kerning or no kerning. A-ha! I hadn't needed the function before, and so I was unaware. This completely solved the issue. Thank you T...

Hi Tim, When I try to add models and independents from an older version of a font I'm working on, it fails. The metrics themselves have not changed. One thing I noticed is that it does not import special spacing groups. I wonder if that is the cause, or something else? When the transfer operation co...

Just as an update in case anyone else runs into this eventually, > It is meant to be used only if you want glyphs to visually look looser or tighter than the standard. This ended up being the case for me. What is standard (at least to some type designers) for Cyrillic in certain pairs that take on m...

Hi Tim, thank you for the detailed explanation, I understand the suggestions much better now

I seem to remember than Kern On makes suggestions based on frequency of pairs, as they occur in large amounts of analyzed text. I was wondering if the Kern On algorithm also considers the optimal pairs needed to result in Kern On having no more suggestions? In other words, is it possible that taking...

> It is meant to be used only if you want glyphs to visually look looser or tighter than the standard.

This may be the answer too, though :)

Thanks for the response, Tim! What you're saying makes sense, in the sense that Kern-On is agnostic to script and convention, and instead relies on shapes/notan - but I believe that may be what's causing the issue. Certain Cyrillic pairs can be uniquely tight, in a way that would make a shape/notan ...

hi all, I was wondering if others frequently run into issues with Л and л (El-cy and el-cy) as well as the sides of letters with spikes. imagine in a sans serif and some combinations like АЛ and АД or дл. I will kern these pretty tightly, maybe close to AA. but kern-on seems unhappy about it, and th...

Ah that makes sense - the frequency of certain components would end up being very high in some cases. Thanks for making the change. It does sound ideal to set them to "No kerning"

I don't think I want autokerning between components that are not exporting. I can provide an example: let's say I have a non-exporting glyph named "_part.ka-angle" which is just the right side of /K without the left stem. And I use it to construct my /K and /Ж etc. In my opinion, the glyph...

Hi Tim, I wonder if Kern On should exclude pairs with non-exporting glyphs from its suggestions? It would make sense to me, but maybe there's something I'm not considering