-
Notifications
You must be signed in to change notification settings - Fork 15
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
numeric scale for PPEM axis: can't restrict to integers #17
Comments
Yes, you can alter
into
And in section Additional Info, add this paragraph:
|
Does it matter if implementations differ in how rounding is done, or should a specific rounding be recommended? |
@PeterCon |
Even is there is no way to prevent an app from requesting an instance using a non-integer value for the axis, (no matter how silly that may seem for an app to do, if it is offering the selection of the ppm axis;)), there is a way to make the variations along a ppm axis "include" a ppm instance's non-integer values so that no matter what the user might be tempted to ask for though a witless app, they will get a witty ppm. My major concern with this axis is that, despite it's obvious usefulness might have been over the past 25 years, today's OS font software are doing sub-pixel positioning, do not produce a single rendering of a font for each size, and sometimes produce multiple renderings. And, it's come to my attention that pixel alignment in y, is about to go the same way. So, maybe Peter has some input on the future of x and y pixel alignment that could inform us as to the best way to define the axis for the past as well as the future. |
@dberlow For me, if a proper rasterizer could not make sure that it can perfectly align the glyph onto pixel grid, then it should pass 0 to this axis. So for
|
In the Proposed Axis Details section of the PPEM proposal summary, it proposes the following:
Valid numeric range: Must be a non-negative integer.
Since this pertains to PPEM, I can understand the desire to limit values to integers. However, variation axes are inherently continuous, and there is no way to prevent an app from requesting an instance using a non-integer value for the axis. If the axis were not intended for variable fonts, then that might not be an issue. But the proposal specifically has variable fonts in mind.
The Valid numeric range field would need to be changed to say simply a non-negative value.
In the Additional Info field, you could indicate that only integer values should ever be selected. It might also be a good idea to recommend that applications round non-integer values so that only integer values are ever actually used in selecting an instance. Some related remarks might also be appropriate for the Suggested Programmatic Interactions and UI Recommendations fields.
The text was updated successfully, but these errors were encountered: