Proposal for a "PPEM" axis ('ppem') has been submitted. Please use this thread for general discussion.

[PeterCon]

The proposal is for a PPEM axis, to enable adjustment of contour points for grid alignment at particular PPEM sizes (similar to TrueType hinting, but maybe easier to implement for font developers not familiar with TrueType hinting). See the proposal details here:

https://github.com/Microsoft/OpenTypeDesignVariationAxisTags/tree/master/Proposals/PPEM_Axis

Process clarification: Please use this thread for general discussion, but feel free to create issues for specific details in the proposal that you think require attention.

[jenskutilek]

This:

Thus, interpreting TrueType instructions (or CFF hints) is required when activating ppem axis.

combined wit this:

Pixel alignment may be crucial in some cases, and the form of such mechanism (TrueType instructions) are very hard to understand, for designers. Therefore, a variation axis could be a easier way to encode pixel alignment data into fonts.

seems to be a contradiction, since hinting seems still required even when the adjustments are made by the ppem variations.

[jenskutilek]

What about ppem-related changes in the sidebearings? ‘The ppem axis is used to encode deltas that shift points to the place closer to the pixel grid’ seems to include the phantom points. But this may lead to significant differences in text length if e.g. the same text is rendered in a preview on screen and then printed with high resolution.

It is like the issues around the hdmx table and ClearType’s compatible/natural widths.

[lemzwerg]

[Taken from the OpenType mailing list]

Interesting! I'm not sure how this will behave size-wise, since adjustments to the grid are certainly not linear; this might lead to quite large gvar tables – essentially, there would be one 'master' per a single ppem value. I would like to see a prototype implemention of, say, a single, simple CJK glyph that demonstrates this proposal.

Another issue would be the behaviour for different scaling values along the x and y axis – perhaps also registering XPEM and YPEM?

[behdad]

I can imagine how this axis can be used with FeatureVariations to, eg, switch to simpler forms of CJK ideographs at small sizes. But I don't see how it can be used to perform hinting using glyph deltas, since we have to and do support fractional pixel sizes. So, deltas cannot be used to align stems to grid the way hinting does.

[robmck-ms]

@behdad: are you talking about fractional PPEM (after scaling), or fractional UPM, or something else?

[behdad]

Fractional PPEM

[dberlow]

*lemzwerg “...this might lead to quite large gvar tables”

I think this is minimal, if reduced by interpolation of untouched points, to only a few deltas per glyph. Besides the fact that people do make big fonts anyway, I think that quality, as a choice, is sometimes to be made over the quantity it may cause. In this case, something a standard could not be blamed for allowing.

I like Rob’s idea of separate x and y a lot, and it got me thinking about some kind of super-efficient additional way to shift all the grid-fit glyph positions at once, in x and y sub pixel space, to provide a sort of fine-tuning that could be offered at a number of possible levels, keeping in mind that this proposed axis would be operating in variable space potentially with other axes, beside via a variety of devices, sizing, scaling and rendering methods .