Behdad Esfahbod
Behdad Esfahbod
So I'm okay merging this for now, on the condition that we can remove it and reconcile the ideas into the main model soon. I've since solved the modeling theoretical...
I'll take a look in the next ten days to see if I can adjust the default algorithm to generate more simple regions.
Hi @justvanrossum. Based on your code here, I modified the generic solver. It's in https://github.com/fonttools/fonttools/pull/2717
What it should do instead is to break down classes, perhaps using `misc.classifyTools`. The reason we have not hit this bug is that UFO workflow has classes that are always...
Imagine one kern pair is ([a], [b]), another is ([a á] [c]). Current code will put the second pair in a new subtable. But both pairs have the glyph 'a'...
> ok thanks. By breaking down classes, you mean that your example ([a á] [c]) would be split into two kern pairs ([a] [c]) and ([á] [c]), correct? Correct.
> Do I understand correctly that this is an edge case consideration for `ClassPairPosSubtableBuilder`, because both in UFO and glyphsLib workflows, glyph group membership is exclusive per side and the...
> Weirder and weirder. In `PairPosBuilder`, we create a separate builder for each value format: Correct. That's a bug. I see if I can fix it.
That's not the only bug near that code. `ClassPairPosSubtableBuilder` also adds new subtables if the classes are not "mergeable". That logic is also b0rked.
> @behdad can you elaborate _why_ it's a bug to create separate subtables for each value format? I understand that it would fix the cases highlighted by @simoncozens (where a...