Is Anisotropic interpolation a good thing to have?

[davelab6]

In the original design doc, "OpenType GX" by @behdad, there is a "Further discussion" section which says,

Anisotropic interpolation

TODO:

• Description of anisotropic interpolation.
• Find out if this was possible in GXVar.
• Make a case why it would be a good thing to have.

For (1), https://help.fontlab.com/fontlab-vi/Variations-panel/#anisotropic-interpolation (I believe by @twardoch) says it well:

Anisotropic interpolation can use different interpolation values for X and Y directions, unlike standard interpolation which uses the same values for both directions. This allows you to have an axis have more (up to double) or less (up to zero) effect in either the X or Y direction.

For (2), I wonder if @be5invis knows.

For (3), I wonder if a counter-case (that it would be a bad thing to have) was made, and that's why it never made it into OT1.8.

[behdad]

A better document will be Tim Ahrens MSc thesis / "Size-specific adjustments to type designs" book, which both explains powerful things that can e done with anisotropic interpolation as well as its problems / limitations.

[be5invis]

@davelab6

Yes you can. If you look into the delta-rect level you can see any variable "quantities" can be expressed into this form:

where are the variation rects of a given VQ.

So extending the rect set is pretty simple and safe: simply assign zero deltas to the new rects and it is solved.

VQs form a module so you can safely define addition or scale of VQs. Though I'd like to extend it a little so it can form a ring (allows you to define multiplication of VQs).

[davelab6]

@dberlow @Lorp do you know if this was possible in GX?

[twardoch]

I believe there are two separate questions: 1. Whether the gvar and CFF2 machineries have some smart ways to re-use deltas across multiple axes, but only partially ( so it's a compression issue). I'm too stupid to answer that. 2. Whether a next-gen avar (xvar / avar2 table) would let us do it. I believe a simple answer would be: yes. There could be one hidden axis that only has deltas in the x direction, another hidden axis that only has deltas in y direction. And then some virtual axes could freely mix instance selections from those hidden axes, picking some values from the x-only axis and some other values from the y-only axis. Because, really, anisotropic interpolation at its core is simply treating one axis as two axes. That's it. A feasible addition to a potential next-gen avar would then be scaling (in x and y) — i.e. after you've interpolated, you scale the result geometrically in x and y separately. And then, ideally, also shift. Maybe not the full transform matrix, but why not. Whether this could be done with next-gen avar, I'm not sure. But it obviously has benefits beyond anisotropic. This would let us have a virtual superscript, subscript or small caps axis for example: If the font has opsz, or wght+wdth, or wgHt (which is my codename for x-only wght) and wghT (which is my codename for y-only wght), or even just plain wght, a virtual smcp axis could request a lower opsz and scale the glyphs down, or could request a higher wght and a higher wdth and scale the glyphs down, or request different values from wgHt & wghT and scale differently in x and y (Ahrens-style), or even just request a higher wght and scale down. All those approaches world give you some "small caps". Superscripts & subscripts world work the same but also require shift. And there would be need for some tracking. In fact, this small caps approach could be generalized into a general "size" axis, that — unlike opsz, which only changes the outlines but keeps the em size unchanged — would do the same as opsz (or pseudo-opsz, done via the mechanisms described above), but would also perform the actual scaling. Kind of what fake superscripts/subscripts and fake small caps do. So in the same point size, you'd get lower opsz instances that are also scaled down appropriately. And then at some point we'd need variable components of we want to be able to do this for the Unicode superscript/subscript and other characters that are in fact size-reduced versions of other glyphs'in the font. But of course all this could also be done with today's mechanism: we could register the axes and define how they'd be built from design axes, and some software would just derive the values and put this derived data into the font. It would blow up the font, and not all could be easily compressed, but people could start doing it already today, and then appropriate mechanisms could be added to the format later to, effectively, facilitate the compression. A.

…

On Wed, 26 Jun 2019 at 08:17, Dave Crossland ***@***.***> wrote: @dberlow <https://github.com/dberlow> @Lorp <https://github.com/Lorp> do you know if this was possible in GX? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2?email_source=notifications&email_token=AAD6XRFGNFIYX5HLXWQNY4TP4MCZFA5CNFSM4G3OENR2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYSOT7I#issuecomment-505735677>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAD6XRBZD7KAGBYIUIAYRK3P4MCZFANCNFSM4G3OENRQ> .

[Lorp]

It’s easy to separate the x and y effects of all the delta sets, i.e. split them into two axes. This is fine in original GX. If you wanted to split wght, you’d create two new axes, wghX and wghY, and crunch the delta sets with fontTools or by editing TTX output. This would be 100% safe, I think. Moving the two new axes in sync would be identical to moving the old axis.

I wondered about this technique when writing a gvar parser. I liked the idea of making variations more like TrueType hinting, where x and y are always completely separate (except when you make non-orthogonal freedom & projection vectors).

It’s possible that on real data it would give better compression in itself, and also better IUP compression.