numeric scale for PPEM axis: can't restrict to integers

[PeterCon]

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.

[be5invis]

Yes, you can alter

Valid numeric range: Must be a non-negative integer.

into

Valid numeric range: Non-negative numbers.

And in section Additional Info, add this paragraph:

Since this axis is used to represent PPEM, the deltas for only integeral ppem values are properly defined. Applications should not pass a non-integral value to the font. It is recommended that applications round non-integral values and then pass it into the font.

[PeterCon]

Does it matter if implementations differ in how rounding is done, or should a specific rounding be recommended?

[be5invis]

@PeterCon
This value should be equal to the PPEM used for hinting, so the rounding function should be consistent with the one used for hinting.

[dberlow]

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.

[be5invis]

@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 ppem, if a rasterizer want to enable it it must:

• Enable grid-fitting (interpret TT instr / CFF hint + GASP does not turn gridfit off)
• Disable sub-pixel positioning