PPEM axis: programmatic interaction & UI

[PeterCon]

In the proposal summary for the PPEM axis, the fields in the Proposed Axis Details section for programmatic interaction and UI seem to suggest that in some situations the value for this axis might be selected directly by a user, or indirectly by some UI that doesn't obviously directly affect ppem used in text display.

For programmatic interactions, wouldn't it be appropriate to say this should always be set at a point in layout or rendering when PPEM is known, possibly in the rasterizer itself?

"This axis should be hidden from direct user-selection in UI if it is used for implementation of other user-selectable settings such as tracking. If the axis becomes adopted for use in implementation of tracking features in applications, then use of the HIDDEN_AXIS flag in the 'fvar' table should be considered for this axis."

It's not clear how this is related to tracking. If that is what is intended, then that needs some clarification (perhaps in the add'l info field).

Wouldn't it make sense for the HIDDEN_AXIS flag to always be set?

If it's suggested that some software implementations would set a value for this axis in the rasterizer, or some point after layout, shouldn't there be a strong recommendation that this never affect glyph metrics? (That could be added to the add'l info field.)

[be5invis]

@PeterCon
For some cases (like designing a web page in Illustrator), designers may manually select a PPEM to preview how their icon font looks like under the particular size.
(The UI section is basically a copy from the Spcaing axis... I'll fix it asap.)

[be5invis]

Changes of the Suggested programmatic interactions and UI recommendations section:

---

Suggested programmatic interactions: A proper rasterizer should pass zero, representing “Ignore pixel alignment”, or a positive integer, strictly equal to the current PPEM value when rasterizing the glyphs in the font.

When a positive ppem value is passed to the font, the hinting mechanism (TrueType instructions or CFF hints) must be enabled. For TrueType fonts, the value should be exactly equal to the result MPPEM[] instruction, and whether passing positive ppem value should be controlled by the gasp table.

The logic of rasterizers could be described as the code below:

if do hinting then
    pass the PPEM used for hinting as the value of `ppem` axis
else
    pass 0

UI recommendations: This axis should be hidden from direct user-selection in UI, and the HIDDEN_AXIS flag in fvar should always be set.

In some special cases, like a user interface designing software, applications could provide some control to let user to select the PPEM value, but the value should be restricted to integers, and the application must properly interpret the TrueType or CFF hints when the value user selected being non-zero. The PPEM used in interpreting hints should be equal to the value the user selected.

[PeterCon]

For suggested PI, do you want to expand a bit to add the following (without the added emphasis)?

"It is recommended that this value be set by the rasterizer to the current PPEM value, and that text selection and layout processes leave this set to zero."

Also, a minor point on wording: I find the wording "pass a value to the axis" a bit confusing: it makes it sound like the axis is an active agent that will take some action on the value passed to it. But in this case, it's the rasterizer that will be taking action. So, I'd be inclined to use wording like "set the axis value".

[be5invis]

@PeterCon
I've rewritten the PI section to make it more clear and precise.
The term "pass" is the same as "pass an argument into a function". I'll change the wording.

UPDATED VERSION:

---

Suggested programmatic interactions: A proper rasterizer should set ppem axis value to zero, representing “Ignore pixel alignment”, or a positive integer equal to the current PPEM value when rasterizing the glyphs in the font.

When a positive ppem value is set, the hinting mechanism (TrueType instructions or CFF hints) must be enabled. For TrueType fonts, the value should be exactly equal to the result MPPEM[] instruction, and whether passing positive ppem value should be controlled by the gasp table.

The logic of rasterizers could be described as the code below:

if do hinting then
    pass the PPEM used for hinting as the value of `ppem` axis
else
    pass 0

UI recommendations: This axis should be hidden from direct user-selection in UI, and the HIDDEN_AXIS flag in fvar should always be set.

In some special cases, like a user interface designing software, applications could provide some control to let user to select the PPEM value, but the value should be restricted to integers, and the application must properly interpret the TrueType or CFF hints when the value user selected being non-zero. The PPEM used in interpreting hints should be equal to the value the user selected.

[twardoch]

I think the PPEM axis may be of limited interest for people who develop otherwise "static" fonts, as they may be interested in employing traditional hinting techniques for reasons of backwards compatibility. But I think the PPEM axis can be very interesting for various fonts that also have other axes — hinting variable fonts is not yet a "solved" problem, and it's somewhat unclear how one would hint in complex situations. But with the PPEM axis, a designer could easily intervene on a per-glyph basis when some important adjustments are needed in a particular region of the design space.

[be5invis]

@twardoch
For IDH, as discussed with Greg Hitchcock before, it would calculate the IDH data for various selected instances (like wght = 100, 200, ..., 1000), then for one stroke, the data would become a Variation -> PPEM -> (Position, MaxWidth, MinWidth) table. For an "arbitrary" variation (like wght = 125), the instruction would choose the closest calculated instance (in this case, wght = 100), and use the data calculated for that.