Skip to content
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.

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

STAT table false warn again? "nameID out of range" #210

Closed
justvanrossum opened this issue Jun 7, 2020 · 7 comments
Closed

STAT table false warn again? "nameID out of range" #210

justvanrossum opened this issue Jun 7, 2020 · 7 comments

Comments

@justvanrossum
Copy link

This seems similar to #180, but is about an AxisNameID, which in my font refers to nameID 2. I don't see how that's illegal.

@justvanrossum
Copy link
Author

The test for axis.axisNameID passes false for allowPredefined:

ots/src/stat.cc

Lines 87 to 89 in 516e40a

if (!ValidateNameId(axis.axisNameID, false)) {
return true;
}

@justvanrossum
Copy link
Author

(This is btw. a side effect of fonttools more aggressively reusing name IDs.)

@khaledhosny
Copy link
Owner

This is intentional, from the spec:

The axisNameID field provides a name ID that can be used to obtain strings from the 'name' table that can be used to refer to the axis in application user interfaces. The name ID must be greater than 255 and less than 32768.

We probably can relax the check if there is a strong case for it, but I feel a bit uneasy about allowing spec violation in a new table with not many existing implementations as who knows what crazy stuff implementations might assume based on what the spec is saying.

@justvanrossum
Copy link
Author

Ok, but then we have a serious problem in fonttools with name ID reusing. I'll open an issue there.

@justvanrossum
Copy link
Author

(Thanks for your quick answer, btw.!)

@behdad
Copy link
Collaborator

behdad commented Jun 8, 2020

We probably can relax the check if there is a strong case for it, but I feel a bit uneasy about allowing spec violation in a new table with not many existing implementations as who knows what crazy stuff implementations might assume based on what the spec is saying.

Unfortunately the spec continues to encode unnecessary and bogus restrictions. That is because of how changes to the spec are made and reflect personal opinion of the editor, not something a lot of stakeholders agree with.

@justvanrossum
Copy link
Author

The spec has been updated to relax this requirement:

The axisNameID field provides a name ID that can be used to obtain strings from the 'name' table that can be used to refer to the axis in application user interfaces. A defined name ID can be used if strings for that name ID have the appropriate string for an axis name. Otherwise, name IDs must be greater than 255 and less than 32768.

Does ots still warn about it?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants