PPEM axis: programmatic interaction & UI about opentypedesignvariationaxistags HOT 6 OPEN

@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.)

from opentypedesignvariationaxistags.

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.

from opentypedesignvariationaxistags.

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".

from opentypedesignvariationaxistags.

@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.

from opentypedesignvariationaxistags.

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.

from opentypedesignvariationaxistags.

@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.

from opentypedesignvariationaxistags.