MVAR fonts?

See the 'Item variation store' section of the OT Font Variations Common Table Formats:

_____

Re. the publishing date, yes that reflects when it was ported to the new CMS. I've mentioned this to MS Typography and asked if at least some of the site content could have dates of original publication added. This is less critical for table specs, but some of the site content is pretty ancient now, and some of it should be interpreted in that respect (e.g. the Windows Glyph Processing article that I wrote in 2000).

Exactly. MVAR is intended to allow for variation in metrics across the design space. I think for a lot of variable fonts, this won't be necessary or desirable, in that fonts with weight and width axes only are unlikely to want to vary common vertical metrics for linespacing: as with static fonts, one wouldn't want linespacing in a paragraph changing when a bolder instance is used in one line.

Where I can imagine MVAR being used to vary linespacing metrics is in some fonts with ascender height and descender depth axes, which would be sort of the opposite of making the variable font response to the layout, and instead making the layout responsive to the font variation.

Another idea that crossed my mind recently is a variable font that interpolates between a free height document design and a restricted height UI design or, indeed, targeting multiple different UI environment heights. In that case one would want to use MVAR to change the linespacing metrics to match the environment height axis.

Personally, I think a lot of OTVar stuff is effectively on hold until the architecture to enable some form of meta or virtual axes is decided. There's just too much dependent on that for it make much sense pushing forward with registering new axes or making demos except as design proof-of-concept models.

Adding a bunch of masters is always going to 'work fine' as a way to get a variable font to do what you want. But I'd say the filesize value proposition is pretty central to variable font technology being adopted. Coincidentally, the WOFF2 specification became a W3C formal recommendation today. Webfont optimisation is driving most of what is happening in font technology today.

That said, I'm in favour of getting the low level Type Network axes registered, and think having them registered will help drive definition of the meta/virtual axis mechanism. I just think that mechanism needs to at least be conceptually fleshed out to determine, during the registration process, that things will work when they're thrown together. I'm cautious: I've seen too many things in font tech that were either stillborn or needed to be revised or replaced with other mechanisms because they weren't properly thought through.

I would suggest that we figure out a way to define meta axes without the need of registering all those axes. Keep them around as an example and a rather complex test case. David’s Axes are one solution, not the solution. So we might end up with dozens of axes that belong to competing scheme. But we don’t want to show them ever to the user so the don’t need to be standardized — the virtual axes on top need to be. 

Yes, although interoperability itself could be implemented as Georg suggests if the apps or layout services needing interoperability were themselves always and only accessing low-level parametric features via high-level optical features. I'm just not sure that's a reasonable assumption or that an architectural decision would be likely to limit implementation in that way. My instinct is that even if we were able to define things that way, it wouldn't take long before someone proposed new registered axes that would do the same things as the optical level as other axes were doing at the parametric level.

Dave Crossland said:

I just saw that David B posted this question on the comments section of https://docs.microsoft.com/en-us/typography/opentype/spec/mvar ...

This is probably a better forum to discuss such things.

The OS/2 table has two fields to indicate an intended range for a static font. As of OT 1.8, a STAT table is recommended over those fields.

As for "is that size value being stored somewhere?" I'm not sure I understand the question. If a font has a wght axis, the weight of the default instance is stored, but the weight of other instances isn't stored; it's an _input_ to the text-drawing APIs. Same here: the fvar table defines a font as supporting opsz with min/default/max values, but the size for an instance is an input.

Some background on this might be helpful. When the OS/2 fields for usLowerOpticalPointSize and usUpperOpticalPointSize were defined during the development of the Microsoft Sitka font family, no provision was made for larger, more complex families with a range of weights and styles beyond Regular, Italic, Bold and Bold Italic. The name table specification lacks an OT name field that identifies style variants of a family that differ only in optical size, which meant that there was no way to describe a large family in a way that reliably captured all the relationships between the fonts. One way to address this would have been to add yet another OT name field to the name table, in addition to the OT family names and the WWS family names. But no one really wanted to do this, or saw endless additions to the name table as a viable long term solution for increasingly complex families. This prompted a number of ideas ideas around defining family relationships via attributes rather than names, which eventually resulted in the STAT table.

Because the STAT table is defined to be useable with variable fonts, it contains AxisValue records, which means that min and max optical size attributes can be stored directly in the STAT table, and as Rob McKaughan illustrated recently, the same attributes can be used in static fonts with a STAT table. So at the same time as the STAT table solved the problem raised by the OS/2 size values, it also made those values obsolete.