https://docs.microsoft.com/en-us/typography/opentype/spec/mvarI 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?)
Comments
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).
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.
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
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.
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.
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.
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.
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.
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
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.
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?
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.
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.
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.