MVAR fonts?

Dave Crossland

https://docs.microsoft.com/en-us/typography/opentype/spec/mvar

I wonder if anyone has made any fonts that make use of this table, yet?

If so, I'd be grateful for a more detailed explanation of what delta-set indices are. 

(Also, I see that page says it was updated on 2017-12-20 but I assume that is an artifact of the new Content Management System that Microsoft is using for docs.microsoft.com, and does not indicate an actual update to the spec?)

John Hudson

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

Variation data is comprised of delta adjustment values that apply to particular target items and that have effect for instances within particular regions of the font’s variation space. Some mechanism is needed to associate delta values with target items. In the tuple variation store formats (described earlier in this chapter), data containing a set of deltas also includes a set of point number indices to identify the target items to which the deltas apply. In the item variation store, however, a block of delta values has implicit delta-set indices, and separate data outside the item variation store is provided that indicates the delta-set index associated with a particular target item. For example, the 'MVAR' table header includes an array of records that identify target font data items and the delta-set index for each item.

_____

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).

Dave Crossland

Am I right then that the MVAR table is a way to return to an OpenType rendering system the value of what was formerly found in the OS/2, post, etc, tables; in a VF, those values in those tables are set appropriately for the default instance (in the glyf table) but if a rendering system wants to know what they should be for some other location in the design space, it can use the mvar table to look that up?

John Hudson

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.

Dave Crossland

Amstelvar has been demonstrating such ascender & descender axes for a while now, and they were proposed a while ago now. 

Regarding your idea, I agree, that seems useful to me. Has anyone actually made a demo? This seems to have been in the spectrum since 1.8.0 launch time, so I'm curious if there isn't a single demo of this yet, why not

John Hudson

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.

Dave Crossland

It seems to me that the initial value proposition of "more fonts for less data" can not be realised without meta/virtual axes.

However, I don't see what the problem is with what Amstelvar is doing other than filesize; David is drawing only 9 masters (default and 4 axes' poles) and then wacking the "promote to master" button when an instance that mixes/blends those 4 axes is where an instance needs to be on a registered axis. It works fine. 

John Hudson

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.

John Hudson

Going back to the original question, and how it relates to Amstelvar's ascender and descender axes, it's an interesting design question as to whether linespacing metrics should be variable relative to those axes. Is the intent of the axes to make the ascender and descender shorter or longer relative to the linespacing, or to make both the extenders and the linespacing smaller or larger together? I can imagine fonts being made in either way. Will users expect consistent behaviours from fonts with the same variable axes sets?

Georg Seifert

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. 

John Hudson

Yes, one way of looking at this is that any lower-level, parametric axis can be arbitrary and non-standardised — or a private standard employed by a foundry or group of foundries by common agreement —, not needing to be registered in the OTVar specification so long as higher-level meta/virtual axes addressing those parametric axes are properly standardised and registered.

However, this way of looking at it presumes that parametric axes are always addressed via higher-level axes, and I don't think that is necessarily the case. While the intent of parametric axes might be that they are never exposed to the user in a UI, that doesn't mean they can't be addressed directly in software, e.g. in responsive typography situations where the scale used for the parametric axes might give finer control than the scales in higher-level axes.

In considering the Amstelvar model, I don't think it is only 'an example and a rather complex test case', but in the back of my mind I am always pondering just what David and Petr might be planning to do with that model in PageBot. I have the sense that what they're building is actually a way to dive directly from typographic controls at the app level to per-mille based parametric axes. I might be wrong and, of course, such a system could also constitute a private standard that doesn't need to be registered (or registered upfront). But I'm curious.

Dave Crossland

Georg you are simply wrong about the purpose of axis registration. It is an orthogonal issue to user visibility. It is about INTEROPERABILITY. 

Dave Crossland

Pagebot, browsers and Adobe should not offer any differences in what can be done. They just go about it differently.

John Hudson

It is about INTEROPERABILITY. 

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

The high level axes are a convenience, like named instances are a "bookmarks" for instance locations, they are "bookmarks" for axes paths through the design space. So it's a completely unreasonable assumption. It's like saying a vf is a compression scheme for accessing named instances only. 

I suspect this kind of thinking is because of an atmospheric backwards-compatibility ideology... that I wonder is zero sum with a progressive ideology that puts compression aside to provide benefit in finer typography. 

Dave Crossland

"There's just too much dependent on that for it make much sense pushing forward with registering new axes"

Versus

"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"

Versus

"such a system could also constitute a private standard that doesn't need to be registered"

You seem to say "wait," "yes," and "no" in quick succession. 

I think that the system is already a private standard, but it does need to be registered ASAP because that will help focus engineering folks to understand what it is that they are optimizing for.

Also:

"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."

Indeed we know it wouldn't take long because this has already happened  

John Hudson

"There's just too much dependent on that for it make much sense pushing forward with registering new axes"

I still think that's broadly true, but something like the low level parametric axes that Type Network has proposed are an exception because they're clearly one-half of a high/low level architecture.

"such a system could also constitute a private standard that doesn't need to be registered"

Emphasis on the 'could'. I was talking about ways in which things could technically be done, not how they necessarily should be done.

Dave Crossland

Thanks for clarifying

Dave Crossland

I just saw that David B posted this question on the comments section of https://docs.microsoft.com/en-us/typography/opentype/spec/mvar and the note that says such comments will get deleted soon

A question about optical size, which is not a registered tag in the MVAR. 

The OS/2 table had minimum and maximum optical size tags. Variable fonts have the option of an optical size axis (opsz). Since every instance in the space of a such variable font is one optical size — is that size value being stored somewhere other than the MVAR, so it can be included in instances of the variable font?

Peter Constable

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.

Peter Constable

Here's a longer reply I posted on docs.microsoft.com:

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

In a variable font the value for any axis is an input. In general, the font doesn't need to have that value stored anywhere except that the 'fvar' table will declare min, default and max values, and the default will apply to the default instance.

Now, in the case of certain axes, there may a separate value in the font. For example, in the case of the 'wght' (weight) axis, there is OS/2.usWeightClass. This should match the default value for 'wght' in the 'fvar' table. But OS/2.usWeightClass doesn't need to be supported in the MVAR table since the instance value for 'wght' would be the interpolated value for usWeightClass — i.e., it would be redundant.

The size fields in the OS/2 table don't need to be accommodated in the MVAR table for two reasons: First, the instance 'opsz' value is an input (as for 'wght') and supporting that in MVAR would be redundant. But more to the point, the size fields were intended to indicate min/max values for a range; in a variable font, the only thing that might make sense would be to set them to the same values as the 'opsz' min/max values in the 'fvar' table.

John Hudson

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

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.

Dave Crossland

I posted https://github.com/Microsoft/OpenTypeDesignVariationAxisTags/issues/22#issuecomment-401493070 which seems related to this discussion.