[ppem] Axis ranges and special axis values like 0, ∞

[jenskutilek]

I’ve tried to add a ppem axis to a test font (only one letter). It feels somewhat unnatural to have the default outline at axis value 0, as the pixel adjustments must have the largest effect at small sizes, and then gradually diminish towards the default outline, which should naturally be positioned at +∞, or a value before that which the designer figures not needing adjustments anymore.

Shown here: 0, (4, 8), 11, (12, 13, 14, 15), 16, 20 ppem (interpolated instances are in parentheses)

Between 1 ppem and the ppem where the x-height reaches 5 pixels, it's virtually impossible to use the ppem axis for meaningful results. Above that, there are large adjustments, which get smaller the larger the ppem value gets. So you would have a range between 0 and ~10 ppem which is effectively not useable.

[tiroj]

Agreed. I'm not sure there needs to be a recommendation or requirement for 'Regular' value for the PPEM axis: the nominal regular instance can correspond to whatever ppem the font maker considers the general case for the design, which might target a particular point size at a particular device resolution, or some value that is average to a range of devices. This allows a design master for the regular to sit in an appropriate location on the PPEM axis, with deltas to either side, or as Jens suggests at the upper end of the PPEM axis extreme, i.e. assuming that high resolution is the norm.

Am I missing something? Is there a need for a standard regular value for this axis?

[PeterCon]

From Guidance for Axis Details (emphasis added):

"It is conventional practice that a font family has a “Regular” font member. Depending on the nature of an axis, there may be a certain numeric value that is required or recommended for a “Regular” font."

[davelab6]

Seems the default should be +∞, or the value before that :)

…

On Dec 6, 2017 3:30 PM, "Peter Constable" ***@***.***> wrote: From Guidance for Axis Details <https://github.com/Microsoft/OpenTypeDesignVariationAxisTags/blob/master/Proposals/GuidanceForAxisDetails.md> (emphasis added): "It is conventional practice that a font family has a “Regular” font member. *Depending on the nature of an axis, there may be* a certain numeric value that is required or recommended for a “Regular” font." — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#19 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAP9y-MJyuykD6TgWdUzYZbtmI9WEs7Jks5s9vlKgaJpZM4Q0_Kd> .

[dberlow]

In our ppm axis architecture, the default instance is the upm of the vf.

So, if the upm is 1000, then there is an axis based on that default value and ranging (-) to the smallest ppm desired of the ppem axis.

And interpolation is perhaps part of the solution, but we are counting on grid-fitting each ppm.

[jenskutilek]

In our ppm axis architecture, the default instance is the upm of the vf.

Doh, of course. How did I not see that?

[dberlow]

I was a serial Doh thinker on this for while. This architecture allows all your other axes to apply, and you can have a ppem/wght combo, e.g., to drive you mad enough to try a ppem/opsz-zzzz.

The upm as the default, ranging (-) to the smaller ppm instances, also opens the gate of resolution hell if ranging (+), to deltas for resolution higher than the upm, which is unexplored and probably melts wax, but be my guest.

I had to start a new line of ppem Dohs after Mr. Future at one of the OT alliance told me the next version of ________, will be subpixel positioned in X and Y, and all hints are off. So, back among my first line of Dohs , is that instances have to be aligned to "the grid" by exactly the same formula as whatever the system (free type, quartz or directwrite), is doing to formulate the grid, base on instructions about a device. . .

If systems don't all do it the same, and tell the truth, then careful variations are needed to provide aliased grid-fit ppem instances. These in themselves probably have a long life, but the possibility of several different ppem-like axes, allowing for different kinds of positioning, and the position-specific interaction with the other variable axes, is also worth considering.

[davelab6]

Maybe a naif question, but, why are the Mr Futures trying turn variation through TrueType Hinting Delta Instructions off, and do hinting (badly) with OpenType Variation Delta Instructions? :)

[robmck-ms]

Regarding subpixels and antialiasing (e.g. @dberlow's comment above): The PPEM axis can work with antialiasing if you build your font carefully.

On Windows, when you have horizontal or vertical antialiasing turned on (per the gasp table), and use Res() commands in VTT to hint, outlines get rounded to oversampled subpixels - e.g. 1/6 of a pixel in x and 1/5 of a pixel in y if you're in color ClearType with vertical antialiasing. You can build your outlines to land exactly at those positions for each given PPEM.

Here's the catch, though: as you're building the outlines, they have to exactly mirror what the gasp table is doing. E.g. if your gasp table enables vertical antialiasing at 20ppem, then your outlines must be built to round to full pixels vertically at all ppems < 20, and round to subpixels at all ppem >= 20.

Here's a caveat (or a catch depending on your point of view): This works great if the font designer knows exactly how many oversampled subpixels the OS will use (e.g. 6x5 in my Cleartype+vertical example above). But, you don't know exactly. E.g. in Windows, color ClearType uses 6 oversampled subpixels horizontally, but grey ClearType (introduced in Win 8) uses 4. There's no way for the font or font designer to know which will be used, so the font designer has to make an assumption, pick one, and built it accordingly. So, there's no way to get perfectly precisely the same as hints in all cases. That said, if you design the font for 6 oversampled subpixels, and it's running on 4, you'll only be very, very slightly off and it shouldn't make too much of a difference (it might not be the ultimate rendered glyph, but it won't be bad, either).

Of course, all that is within Windows. I have no idea what Apple and FreeType do with antialiasing and whether or not they use oversampling.

[robmck-ms]

Actually, thinking a bit about this alongside @lemzwerg's comment #15 (comment): perhaps a solution would be to have different x and y axes (say xspm and yspm), and they'd be based on oversampled PPEM. Thus, for 6x5 ClearType at 20ppem, the axis coordinates for (xspm, yspm) would be (120, 100).

Then, you could be dead-on accurate to what hints do, regardless of the rendering mode.