different ClassDef values between python 2 and 3
See original GitHub issueIt turns out that fonts built with python 2 and 3 may end up having different GPOS tables, because of the non-deterministic way ClassDef
class definition tables are encoded in feaLib/otlLib.
The following patch: https://github.com/fonttools/fonttools/compare/issue-766?expand=1
… produces different test outputs, in a seemingly random fashion: https://travis-ci.org/fonttools/fonttools/jobs/183647027
I think the problem lies in this line, where a list of sets of (glyph names) strings is sorted by the length of the sets: https://github.com/fonttools/fonttools/blob/f81e1411b3fb1ca402065fbd9a3c53907d205b58/Lib/fontTools/otlLib/builder.py#L622
If two sets have the same length the order of the set list is not guaranteed to be the same all the time, as they might be hashed differently by different implementations, sometimes even by the same one at different times.
We need to find a better way to sort the ClassDef.
/cc @brawer
Issue Analytics
- State:
- Created 7 years ago
- Reactions:1
- Comments:8 (6 by maintainers)
Top GitHub Comments
I spoke too fast in https://github.com/fonttools/fonttools/commit/7d1ddb237ec2f4c6d4982ff076fd15c1d47771f2#commitcomment-20329688
The test for ClassDef sets with same length is still failing in a random fashion: https://travis-ci.org/fonttools/fonttools/jobs/187721425 https://ci.appveyor.com/project/fonttools/fonttools/build/1.0.329/job/u2vg1dn24w2jwvt7
Shall I mark it as
xfail
until we find a better fix?otlLib.ClassDefBuilder
only receives sets in its own unit tests (otlLib.builder_test
), whereas it gets tuples when used from feaLib. I wouldn’t like to modify the tests (by replacing sets with tuples) just to make them green…I wonder whether I should do this instead: ie. allow both (unordered) sets and ordered sequences as input to ClassDefBuilder: