fonttools: HashPointPen fails with ufoLib2

I’m using the HashPointPen to check glyphs from a UFO (opened with ufoLib2) against glyphs from a TTF.

Both produce different hashes for identical glyphs when the glyph is a composite.

TTF: w2671[...|(+1+0+0+1+0+0)][l1008+3162l459+3736l942+3736l1335+3162|(+1+0+0+1+180+0)]
UFO: w2671[...|(+1.0+0.0+0.0+1.0+0+0)][l1008+3162l459+3736l942+3736l1335+3162|(+1.0+0.0+0.0+1.0+180+0)]

As you can see, the difference is that the transformation (scale) is stored as an int when the pen is fed by the TTF, but as a float when it is fed by the UFO.

https://github.com/fonttools/fonttools/blob/679a5c0c252fd5b983de0266b0a250fc7cbb49fc/Lib/fontTools/pens/hashPointPen.py#L68-L69

I guess the HashPointPen should be changed to even out this difference, but what would be preferred? The scales in the transformation are stored as F2Dot14 values in a TTF, so for maximum precision, we should probably always write out the full F2Dot14?

About this issue

  • Original URL
  • State: open
  • Created 5 months ago
  • Comments: 19 (6 by maintainers)

Most upvoted comments

but that is exactly what is desired in this case

Ah, I didn’t realize that. But yeah, then a more mallable solution may be warranted, as HashPointPen doesn’t advertize itself as “hash glyphs equal when they are are equal in TTF form”.