Synthetic axis dependencies with parametric axes

[robmck-ms]

As mentioned in the README, there may be a problem with the dependency between synthetic axes and parametric axis coordinates used to synthesize the axis.

In his presentation at TypeParis 2018, David Berlow pointed out a problem with synthetic axes. In his parametric system, XTRA, YTLC, XOPQ, and YOPQ axis coordinates are objective measures of stem or counter weights per mille of UPM*. They actually measure something tangible in the font. You could build a synthetic axis optical size (opsz) axis out of these. For your 12pt opsz, you'd have a specific set of values of the parametric axes for that size, and for 24pt, you'd have a different set of values. Here's the trouble: if you start with that 12pt, then change only the coordinate of opsz to 24pt, you'll get the right rendering, but the coordinates for the parametric axes will be the same (because we didn't change them). Thus, the value of those parametric axes will not be accurate to the outlines (because within the font in XVAR, they've been remapped), thus these objective measures are now relative measures without an explicit reference outside the font to what they are relative to.

[robmck-ms]

One could make the dependency explicit, such that moving the synthetic axis causes an explicit change in the other coordinates. However this isn't implementable in existing frameworks: The HTML/CSS document model assumes that document properties are completely independent from each other. Most text layout APIs in operating systems I know of would also need a completely different model to give feedback back to apps, and it would be a lot of extra work on the app's side (with no functionality gain for them), so very unlikely to get implemented even if the API supported it. (Consider how many apps have great support for stylistic sets and other long-existing OpenType features).

[be5invis]

If #1 is included then an easy solution could be made:

• Include both synthetic axes (like opsz) and parametric axes (like XTRA).
• Mark parametric axes as pure internal (therefore external apps would always keep them zero).
• In XVAR, write functions to compute parametric axes from optical axes. That is, you write function s to compute parameters from opticals.
• In other tables (like gvar, respond to parametric axes only).

[behdad]

• Include both synthetic axes (like opsz) and parametric axes (like XTRA).
• Mark parametric axes as pure internal (therefore external apps would always keep them zero).
• In XVAR, write functions to compute parametric axes from optical axes. That is, you write function s to compute parameters from opticals.
• In other tables (like gvar, respond to parametric axes only).

Exactly. The mapping, might decide to add the value of 'XTRA' to the computed 'XTRA', for tweaking it further by the user.

[robmck-ms]

Thinking about it a bit, I don't think the idea in #1 would make a good solution:

• It doesn't solve the problem that the value of the coordinate does not match the scale defined for the axis. A coordinate of 0 for XTRA means, by definition, the width of the counters is 0. If we did as in #1, then we're redefining 0 as a magic number that means "ignore". Also, if the font user sets values for the synthetic axes, and also non-zero values for the parametric axes, what do those values mean? E.g. if I set opsz=36, and YTRA=10, what does 10 mean? From the point of view of the axis scale definitions, that means YTRA exactly equals 10, which means 10 units per mille of UPM. But, under the hood, that won't be the case. It will be some scaling of the YTRA effect, but the 10 won't correspond to anything in the original scale. The effect will be unpredictable and vary from typeface to typeface. Ultimately, the non-zero axis coordinates will be applying a parametric shift on top of an existing shift (created by the synthetic axis), then the non-zero coordinate value really relates to a warped version of its original scale, and not its original scale itself. In the end, I don't think these would be usable except via manual trial and error.

• If some axes are purely internal, then why enumerate them outside the font? Seems like it would be better not to enumerate them, thus not put them in fvar (or that the flag also means don't expose these axes to applications).

Side note: i'm not sure I understand the idea of deriving the parametric axes from optical axes. One of the major points of parametric axes is to have a set of axes that are truly orthogonal (optical axes aren't), so that it is easier to create optical axes. (The other major point is having a more objective scale for controlling type design parameters, if one wanted to build automation to do that).

[be5invis]

@robmck-ms The idea of pure internal axes is that this axis would NEVER be set by user or application. It could only be set by XVAR. If you want the controllability of both opsz and YTRA, you can add another pure internal axis and assign it with XVAR, using a formula taking opsz and YTRA.

[robmck-ms]

If they're never to be used by user or application, we shouldn't enumerate them. A flag would be a quick way to do this, but there's a question of what past operating systems would do - would they correctly not enumerate them?

Another implementation would be to put the internal axes in another table than fvar, but I just realized that would require a major overhaul of the specs: all the *var tables have an axisCount that refers to, and must agree with, fvar. So, fvar is the only place we can declare axes.