Dropped kerning exceptions
Closed this issue · 3 comments
I am working on generating new instances of Source Serif, which have a few modifications, but the same kerning data (my development repo is here: https://github.com/adobe-fonts/source-serif-pro/tree/dev)
I noticed that the kerning differs in comparison to the previous time generated, so I tried to roll back involved modules. It turns out – when I roll back MutatorMath to release 2.0.3, there are no more kerning differences.
The master setup is simple – a light _0 master, an intermediate _1, and a heavy master _2.
The light and heavy masters coincide with ExtraLight and Black, Regular is just slightly heavier than the _1 master.
I am comparing the SourceSerif_2 master (1000) to the Black instance (1000).
New pair: V igrave -40, not present in previous Black instance:
V | igrave
SourceSerif_0.ufo -10
SourceSerif_1.ufo None
SourceSerif_2.ufo None
ExtraLight -10
Light -18
Regular -30
Semibold -34
Bold -37
Black -40
-------------------------
V | public.kern2.@MMK_R_LAT_i
SourceSerif_0.ufo -20
SourceSerif_1.ufo -30
SourceSerif_2.ufo -40
ExtraLight -20
Light -24
Regular -30
Semibold -34
Bold -37
Black -40
Here it seems a mistake was corrected. Dropping the pair (as happened in the previous iteration) was not the right thing to do. Great!
Now a more mystifying example:
public.kern1.@MMK_L_LAT_U | icircumflex exception given in Black master, but missing in Black instance:
public.kern1.@MMK_L_LAT_U | icircumflex
SourceSerif_0.ufo None
SourceSerif_1.ufo None
SourceSerif_2.ufo -10
ExtraLight None
Light None
Regular None
Semibold None
Bold None
Black None
-------------------------
public.kern1.@MMK_L_LAT_U | public.kern2.@MMK_R_LAT_icircumflex
SourceSerif_0.ufo -10
SourceSerif_1.ufo 10
SourceSerif_2.ufo 20
ExtraLight -10
Light -2
Regular 10
Semibold 14
Bold 17
Black 20
Here it seems the exception was just completely dropped, and I don’t have any idea why.
I have an @MMK_R_LAT_icircumflex group, which contains [icircumflex idieresis imacron icaron itilde] (all i’s with something wide on top). This group avoids many exceptions, but nevertheless sometimes needs one, as this example.
There are a few more modified pairs, most of them correct (added zero-value pairs, for instance), but there is another mysterious one, following the pattern above:
public.kern1.@MMK_L_LAT_f | icircumflex
SourceSerif_0.ufo None
SourceSerif_1.ufo None
SourceSerif_2.ufo 20
ExtraLight None
Light None
Regular None
Semibold None
Bold None
Black None
-------------------------
public.kern1.@MMK_L_LAT_f | public.kern2.@MMK_R_LAT_icircumflex
SourceSerif_0.ufo 20
SourceSerif_1.ufo 60
SourceSerif_2.ufo -5
ExtraLight 20
Light 36
Regular 57
Semibold 36
Bold 13
Black -5
I realize the way MutatorMath handles kerning changed at 2.0.4, since the release notes read:
Pass UFO groups to the MathKerning object so that the latter is able to identify the exceptions
Since I’m not sure where the issue is, I’ll open the problem here – hopefully @typesupply can explain this. I assume he has thought about this problem more than I have.
That 2.04 change might be this one:
items.append((sourceLocation, MathKerning(source.kerning, source.groups)))
This is the line in mathKerning that might be relevant to removing exception kerns with zero.
side1Type, side2Type = self.guessPairType((side1, side2))
Could there be a reason self.guessPairType might not see the pair as an exception?
I also came back to that line in mathKerning – in our original conversation, I assumed it had to do with zero exceptions, but the mystifying examples above are not zero.
I’m working on a more general test case.
This robotools/fontMath#110 was indeed the source of the problem, and the fix makes my kerning generate correctly! Thank you very much Erik!