Open frankrolf opened 11 months ago
I can confirm the behavior, but looking at the code I don't understand how it's happening.
The reason is here:
https://github.com/robotools/defcon/blob/32c956cabe3ca6aaeea69ddeaade5c6d0903ae91/Lib/defcon/objects/base.py#L524
If the new value is equal to the old value, defcon will not write the new value. Since 123.0 == 123
this checks out, and causes the behavior you observe.
Thank you Just! :-)
Would it be reasonable to check for the type
of the value there?
Or, perhaps kerning.round()
should just completely replace the whole kerning object instead of re-writing pairs one-by-one?
I have noticed (with @punchcutter) that
kerning.scale()
followed bykerning.round()
may write floats into the kerning data. These floats are all.0
, so there’s no data problem – still, wondering about the “why”.In the attached project, all kerning values are integers. After doing this, all values are converted to floats:
output is
When changing the scale factor to 2.2, only a few pairs (the ones ending up as .0) become floats, the remaining pairs are rounded to int:
I have double-checked https://github.com/robotools/fontParts/blob/master/Lib/fontParts/base/kerning.py#L93-L115, as well as https://github.com/robotools/fontParts/blob/master/Lib/fontParts/base/normalizers.py#L1094-L1108 – it’s impossible for these to return a float.
normalizers.normalizeKerningValue
should just pass the value through – I wonder if there’s some comparison happening while setting the values (which would return True for10.0 == 10
)?kerning_example.ufo.zip