8000 Float yMin value: required argument is not an integer · Issue #1604 · fonttools/fonttools · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Float yMin value: required argument is not an integer #1604

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
PeterDekkers opened this issue May 9, 2019 · 9 comments · Fixed by #1605
Closed

Float yMin value: required argument is not an integer #1604

PeterDekkers opened this issue May 9, 2019 · 9 comments · Fixed by #1605

Comments

@PeterDekkers
Copy link
Contributor
PeterDekkers commented May 9, 2019 •
edited
Loading

If a font file has a float value in yMin—and I assume equally in xMin, xMax or yMax—it will fail to save with the error required argument is not an integer (fontTools/misc/sstruct.py in pack at line 75, fonttools v3.40.0).

Trace:

fontTools/misc/sstruct.py in pack at line 75
fontTools/ttLib/tables/_h_e_a_d.py in compile at line 69
fontTools/ttLib/ttFont.py in getTableData at line 651
fontTools/ttLib/ttFont.py in _writeTable at line 633
fontTools/ttLib/ttFont.py in _save at line 212
fontTools/ttLib/ttFont.py in save at line 173

Variables at point of error:

formatstring = ">llIIHHQQhhhhHHhhh"
elements = [
    65536, 
    65601, 
    1208942685, 
    1594834165, 
    3, 
    1000, 
    3551183604, 
    3640213847, 
    -132, 
    -170.009, 
    788, 
    835, 
    0, 
    3, 
    2, 
    0, 
    0
]

As you can see the value -170.009 would trigger the error. If integers are expected then rounding should probably be applied.
@justvanrossum
Copy link
Collaborator

The question is where rounding should be applied.

If I look at the code in fonttools itself that usually provides these values, I see that rounding is done by the caller.

In your case, which code was responsible for calculating the font bounding box?

@PeterDekkers
Copy link
Contributor Author
PeterDekkers commented May 9, 2019 •
edited
Loading

Good question! In our case the data is read from a font file I believe. It goes something like:

from fontTools.ttLib import TTFont

font = TTFont(path)

# Here some naming table data is adjusted, nothing to do with bounding box...

font.save(path)

This works on most of our files. Only a few have the yMin float issue. Does that mean our source font file is invalid, and we should round its yMin—and other related metrics—before attempting to save?

To answer your question:

In your case, which code was responsible for calculating the font bounding box?

I believe it's fonttools internals that read this value from the source font file?

@justvanrossum
Copy link
Collaborator

Hm, since the code that I looked at does do proper rounding, it's a bit of a mystery. Can you provide exact steps to reproduce?

@PeterDekkers
Copy link
Contributor Author

Yes, luckily I have a test version of the failing font (with a testing licence and limited character set) that reproduces the issue.

To reproduce with the above linked file:

font = TTFont("/path/to/test-font.otf")
font.save("/path/to/output.otf")

@justvanrossum
Copy link
Collaborator

Thanks, can reproduce.

The issue is that the CFF FontBBox contains float values:

<FontBBox value="-132 -170.009 788 835"/>

And those values are used to populate the head table upon compile. I don't think it is illegal for FontBBox to contain floats, so we indeed need to do some rounding. Probably here:

fonttools/Lib/fontTools/ttLib/tables/_h_e_a_d.py

Line 66 in ffc98ba

self.xMin, self.yMin, self.xMax, self.yMax = topDict.FontBBox

@PeterDekkers
Copy link
Contributor Author
PeterDekkers commented May 9, 2019 •
edited
Loading

Thanks for confirming. And yes, I was looking at that very line you linked—seems like an appropriate place.

@PeterDekkers
Copy link
Contributor Author

One question, which I don't have the knowledge to answer, is whether numbers should be rounded here; or otherwise further carried through as floats all the way downstream.

@anthrotype
Copy link
Member

We need to round because head table can only contain integers for the font bounding box values, unlike the CFF FontBBox.
I suggest using fontTools.misc.arrayTools.intRect function, which takes the floor/ceill thus guaranteeing the rounded rectangle is not smaller than the original.
Would you like to work on a pull request for that?

@PeterDekkers
Copy link
Contributor Author

Sure! On it.

@PeterDekkers PeterDekkers mentioned this issue May 9, 2019
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Fix: ttLib _h_e_a_d FontBBox rounding
3 participants
@PeterDekkers @justvanrossum @anthrotype
0