-
Notifications
You must be signed in to change notification settings - Fork 167
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
[makeinstancesufo] write openTypeOS2WeightClass in instance UFOs according to designspace axis map #1671
Comments
The spec suggests you should insert the rounded value of the wght axis, before any avar magic. Here is a note from OpenType 1.9: MVAR, explicitly handing over responsibility to the corresponding registered axes:
And here is a matching note in OpenType 1.9: OS/2, that explicitly allows non-multiples of 100:
|
@Lorp Is this related to Benedikt’s suggestion? |
I don’t know about Benedikt’s suggestion. Link? I was pleased to see it’s clear that usWeightClass is not limited to units of 100 in static fonts, so relayed the links. |
Perhaps my description above is not clear enough. |
I often forget about designspace-to-userspace mappings, so that may be my confusion. When you say "based on linear interpolation" which values are you talking about? What values would you expect to see? I don’t understand your third example. I’m surprised it is not rejected. |
Rejected by who? Did you look into the attached zip file?
The value I/Benedikt expect or hope to see are in “expected“ – corresponding to the mapping in the designspace file (which often is a manifestation of OS/2 values). |
I don’t think I’m helping here. I’ll shut up :) |
A suggestion from @arialcrime:
Based on some testing, it seems that
makeinstancesufo
sets the value foropenTypeOS2WeightClass
based on linear interpolation. The following example is set up to have a weight axis with three sources, and relatively random weight class values assigned to each source.As far as I know, the
openTypeOS2WeightClass
value is not read in themakeotf
workflow (usually, we assign this value in an override file). Nevertheless, I think it is not unreasonable to expect that value to be influenced by a designspace mapping.current:
designspace mapping:
expected:
os2weightClass via map.zip
The text was updated successfully, but these errors were encountered: