[OTVar] Changing tracking/HVAR

Dave Crossland

4. Variable components

This seems perhaps the most important to me, because of the compression implication - to be able to set different unicode characters in the CMAP out of a single set of outlines, varying in the design space - eg o O 0 and the 0s in % are just in ascii, but should all be just one set of outlines varied in most typefaces - and this is what I understand https://variationsguide.typenetwork.com/#vuid to mean. 

2. Feature axes

Similarly, this seems like what David has proposed in https://variationsguide.typenetwork.com/#votf

Deleted Account

Dave, Adam, 

“1” in Adam's post is demonstrated clearly with Both of the Goggle fonts we made. Amstelvar’s Registered axes Are Defined by carefully adjusting the Parametric Axes to the desired instances of opsz, max & min, wght, max & min and wdth opsz, max & min, instances which were then instantiated as TTFs and added to the ttv as the regisered axes.  

The typography intended from Decovar is un-expressible without a format, or application UI addition, to define thousands of axes via something other than instances in the space.

I explained that about both of these fonts in Berlin, but even before that, others pointed out how wasteful it is to store all those instances, (as is the case in Amstelvar), or leave the user in a stylistic wilderness of sliders, (as is the case in Decovar), if one could store the coordinates, reduce the number of sliders and replace a lot of futzing with programmable variable space.

Our proposal was niether funded, nor inclined under the circumstances, to ask for changes, any changes, to the font format. It was funded to propose how to define the axes for the global typographic requirements of 2018. 

That’s going along just fine, thanks. 

Adam, 

Dave is right, “2”, “3” and “4” are in our proposal. It is just a proposal for how it would be great to work. I don’t see another way to achieve what must be achieved in the spec, though implementing what we propose in our tools is a no-brainer. You?

On the other hand, what you’ve written, an axis for each feature? is not only going to make people freak right out, but it’s not explained, tooled or demonstrated. Perhaps you should do this excercise completely, Adam — you see the proposals, perhaps Make, Show and Tell us all how the Uppercase axis works!?, for certainly: 

if axes are needing to be feature-specific, then there would have to be an Uppercase axis, 

Or is there something about the Uppercase that says it does not need a registered axis in your plan, thanks. 

Adam Twardoch

David, 

there are registered tags for OpenType features that can be realized within the "GSUB" or "GPOS" tables. In most cases, these features are controlled by a binary switch (conceptually, a "checkbox").

Some are controlled by a "set of radio buttons", i.e. they're "one out many", using GSUB LookupType 3. These lookups are commonly used in the "salt" and "cvXX" features. 

I think there would be a benefit in a third choice paradigm — where the controller would be, conceptually, a slider. 

With static fonts, the change in the design parameter "weight" was discrete, but with variable fonts, it can be gradual.

Many OpenType Layout features are for changing some design parameter — for example swashiness. Currently, the OpenType Layout feature "swsh" allows a discrete, "harsh", binary change, as it's typically realized via a GSUB substitution. So the user can "disallow all swash" (swsh 0) or "allow all swash" (swsh 1). 

But from the user's perspective, often some middle ground would be preferred. I made a test font Zinzin VF which allows for gradual change of swashiness across the uppercase.  The font does not use gvar at all — only fvar and GSUB. As you slide along the "SWSH" axis, more and more of the capital letters get swashy, see: 

https://github.com/twardoch/varfonts-ofl/blob/master/ZinzinVF-OFL/README.md

So in my implementation, the user can express her desire by saying "disallow all swash" (SWSH 0) or allow all swash (SWSH 1) or "allow SOME swash" (SWSH 0.45 or whatever). 

I used a custom axis "SWSH" although if I only wanted to do a binary switch, I would have used the registered OpenType Layout tag "swsh" and realized it only in the GSUB. 

There are many typographic effects that the user may want to express desire for, where it shouldn't matter to the user how they've been realized technically. 

A type designer could realize ligation via gvar or GSUB or GPOS, or a combination of these techniques. So I think there should be a "liga" axis and a "dlig" axis for those who wish to implement ligatures through gvar, or even just through fvar+GSUB (analogous to my Zinzin proof of concept). 

We already have an "ital" axis and an "ital" feature, and their use can be conplementary.

I see no problem with "wght" being done via GSUB LookupType 3, where it's discretionary changes between multiple glyph sets (one out of many), if the designs aren't interpolable. Or maybe some glyphs may be interpolable and some not.

It shouldn't matter whether "wght" or "liga" or "ital" or "sups" or "swsh" is done via gvar or GSUB or GPOS or something else, or a combination. That's technical implementation which should be best picked by the font developer, based on the nature of the design. 

The end-user wants to be able to say "I want more swash" or "I want more weight", and the font should respond to those requests as good as it can — no? 

Adam Twardoch

BTW, I don’t think we’re really in disagreement. Perhaps we’re focusing on somewhat different aspects. To me, there is a very clear distinction between the “user-facing axes” and the “technical variation axes”. The user-facing axes don’t have to be based on interpolation, even today.

My Zinzin example shows that you can have a “single-master” font that doesn’t use any glyph interpolation, yet it makes practical (and “useful”) use of user-facing axes (SWSH in this example). The implementation is done via gradual GSUB substitution, and it already works within the OpenType 1.8 framework. The only caveat currently is that, since applying a different setting on the SWSH axis to some glyphs within the text “breaks glyph runs” (which is by design currently), subsequent processing such as kerning cannot be applied between these runs. 

But for the end-users, it wouldn’t matter which technique the font developer used to deliver them the desired typographic effect. Which is why I think many (perhaps not all) tags that are currently registered as OpenType Layout tags should also be permissible as axis tags. The functional meaning of the scale would typically be the “strength” of the selected effect. For example: 

• for a “swsh” axis (Swash), it would be either the glyph coverage or the intensity of the swashiness (e.g. the length of the swashes)
• for a “dlig” axis (Discretionary Ligatures), it would most likely be the overall “number” of ligatures, or (for example in case of traditional Arabic scripts) their “intensity” (how much the constituents are intertwined)
• for a “hist” axis (Historical Forms), it could be the perceived “age” of the text (increasing the amount of archaic forms or making them more archaic)
• for a “sups”/“subs” axis (Superscript/Subscript), it could be the size and position of the superscripts and subscripts (somewhat akin to optical size)
• for a “cpsp” axis (Capital Spacing), it could be the amount of letterspacing applied to capital letters
• for a “mark” axis (Mark attachment), it could be the optical size and distance of the diacritic marks (their “prominence”) — though perhaps it’d be better to have it in a different axis rather than trying to unify

etc. 

I’m not saying that all currently registered OpenType Layout features should get their registered axis equivalents.

Most of the “linguistic” features that are automatically applied by complex-script shapers wouldn’t perhaps get this treatment — or if they would, the recommendation would be that they are only scaled from 0 to 1 in the user space, and the shaper applies them with the setting 1 whenever it needs to apply it.

All that would of course only make sense if changing the instance wouldn’t constitute a run break. So quite possibly, this shouldn’t be at all considered for the “fvar” axes, but a different table (say, “rvar”, “run variations”) would need to be considered. I don’t have a concrete technical proposal at hand. 

John Hudson

Dave, re. '4. Variable components':

This seems perhaps the most important to me, because of the compression implication - to be able to set different unicode characters in the CMAP out of a single set of outlines, varying in the design space - eg o O 0 and the 0s in % are just in ascii, but should all be just one set of outlines varied in most typefaces - and this is what I understand https://variationsguide.typenetwork.com/#vuid to mean. 

I think you need some different term than 'variable components' for what you're describing here. Component glyphs with their own variable design space, as I talked about during my TYPO Labs presentation in Berlin, is something that is quite likely to happen. It implies an extension of the glyf table, building on the existing components mechanism to allow those components to be variable in their own design spaces while also subject to fvar variation at the font level.

What I understand you to be talking about would seem to require a new format of cmap table that is able to reference positions in the design space of a variable glyph rather than glyph IDs. Or, rather, is able to map from a codepoint to a GID and then to a location in the design space of that glyph.

A few years ago, I proposed a new cmap format that would map from single Unicode codepoints to multiple glyph IDs. This would allow us to make fonts that don't need to include precomposed diacritic letters, because one could map from, e.g. U+00E8 to the glyphs /e/ and /gravecomb/, and allow GPOS mark positioning to look after the display. [It would also enable something like Tom Milo's deconstruction of characters into discrete stroke elements.] At the time, I was told that no one was interested in implementing a new cmap format (I believe the format 14 table for Unicode variation selector sequences was the last new cmap format; it basically does the opposite of my proposal, mapping from multiple Unicode codepoints to single GIDs).

Maybe things have changed now. OT font variations have opened up almost all aspects of the spec to change, so perhaps a new cmap format is something that the software makers would consider? I'm not very hopeful about that, but if it is the case I would be still be pushing for my one-to-many cmap format.

With regard to David's 'unicode variation axis', though, I'm struggling to come up with a use case beyond something like the moon phase example, i.e. in which two or more characters can be parsed as different states of a single entity. It seems to me there are very few such cases in Unicode — the clock face is another that comes immediately to mind —, so the implication of needing a new cmap table to be able to point from codepoints to locations in the design space for an individual glyph seems a big ask. It would be a heck of a lot easier to propose to Unicode to add VARIABLE MOON FACE and VARIABLE CLOCK FACE characters and register an axis or axes to address these special cases.

I am not at all convinced that 'o O 0 and the 0s in % ... should all be just one set of outlines varied in most typefaces', and even so it's not something that scales to a significant number of characters. It is, of course, something that the model of variable components I presented in Berlin could easily handle, because the o O 0 etc. could all be composites of a single component glyph. The compression implications of going direct from a Unicode character to a location in design space vs. going from a Unicode character to a composite glyph using a variable component would be minimal.

Deleted Account

John,  “I'm struggling to come up with a use case beyond something like the moon phase example, i.e. in which two or more characters can be parsed as different states of a single entity.” 

Oh. /|\. Should I go on?

John Hudson

I wouldn't categorise those as characters that can be parsed as different states of a single entity. They're distinct entities (unlike e.g. a clock face, which by category is something that has different states). Sure, it's possible to conceive of them as being generated from a single, variable outline; hence, like Dave's o O 0 etc. case, they're candidates for variable component treatment in a font such as I proposed in Berlin, and if one wanted to make the slash slant variable for some reason one could have a slant variation axis to do that.

So is there a need for being able to map from codepoints to variable instance location in glyphs? I understand that it is a possible model, and conceptually a clever model. As someone who has argued for one-to-many character-to-glyph mapping, I appreciate the idea of not having to include unnecessary glyphs in a font just to have one default glyph per supported Unicode character. I'm just not sure its worth the extra overhead, given the options, and I expect the response you'll get from software makers is the same as I received. It would need either a new cmap format or require a layout engine to track the character input during variation shaping, which isn't a requirement for any other aspect of variable fonts. Again referring back to our experience with OpenType Layout: features that require shaping engines to do special things that no other feature requires tend to end up not being supported.

Dave Crossland

"They're distinct entities"

Yes and no. 

Yes, they appear as distinct because they have different locations in the design space. 

No, because they have the same underlying topology: You can count the points, and their order, and they are very likely the same, or trivially normalizable to be so. So, same design space. What differs is the position of the points, so, the location within the design space.

"Is there a need for being able to map from codepoints to variable instance location in glyphs?"

Yes. A strong need. 

Even in ascii there are many sets of codepoints that map wholly to single glyph topologies. 

I already gave you oO0, David gave you /|\, and hnu are obvious and m can sit there too if you want to have fun. Surely you of all people can see a lot of Indic characters are like this. 

This has obvious - to me - compression benefits. Should I explain those in detail?

Deleted Account

No thanks, Dave. But when you want to understand the combinatorial explosion of oO0 and /|\ in detail, and as it applies to a Kanji with wght and opsz axes let us know;)

John Hudson

Dave, I should have been more specific: Is there a need to map directly from codepoints to variable instance location in glyphs? That's what I understand the 'vuid' axis proposal to imply (without actually detailing how that mapping would be implemented). The variable component model that I suggested in Berlin provides an indirect mapping from codepoints to variable instance location via an extension of the existing composite glyph model that has been part of TrueType since the beginning. Now David is talking about Kanji, which is a giant set of entities that do not have shared topologies, but are rather made up of elements (strokes) that do. That is exactly the use case for variable components and not addressable with 'vuid' as spec'd, because you can't treat thousands of Kanji as variable instances of an individual glyph, but you can build thousands of glyphs from a small number of variable components.

Deleted Account

John’s points touch on an interesting set of issues related to but not of VUID and VOTF. Variable components are one issue. We’ve provided an example of that in Decovar. There are two sets of masters because of the disconnect we think there is between nested variable components and variable glyphs. I’m not sure John’s proposal to change the font format will solve that, but because it is common enough, and John isn’t, I just assume so. By common enough, I think a lot of people recognize the need to build glyphs from variable components, and by uncommon enough, Johns experience in this is great.

It’s importent to write though, that our Google Font projects were not focused back on these issues yet. Nor was our proposal scoped to allow any request for change to the font format. Just the fundamental axes we thought obviously need to be added. These were specified, in some cases, to make the need for format change, or at least further discussion, more obvious. The Overhanging obviousness we are heading to, is that there needs to be little, or better, no difference, between the font format and the design format. As that is something that could take years, we do what we can, now.

So, we agree that the assembly of glyphs from variation space is one issue. Having discovered for ourselves in Decovar, the variable component side of things, and more, we also stand by all of the proposal and I expect that later change to the format will make some of it much more clear. Ahead of that clarity, we think, demonstrate and progress on our need to go into variation space for parts, and for whole glyphs. So, I’m not sure why one thing there would be Important Enough to change the font format while the other thing there is Not Important Enough to register as an axis.

John Hudson

David,

I’m not sure why one thing there would be Important Enough to change the font format while the other thing there is Not Important Enough to register as an axis.

I think it's about looking at a need, understanding the need, and figuring out what the best way to address that need would be within the overall framework of text encoding, glyph processing and, now, variable design space. I think you've looked at and understood a lot of the needs more than the rest of us, but I don't think 'register an axis' is always going to be the best way to address a specific need, and it certainly isn't a kind of panacea for all needs. And as I suggested above re. 'vuid', registered axes may imply changes elsewhere in the font format, or to line layout processes, or to CSS, or to some other aspect of the web of interdependencies that text encoding standards, font specifications, software, and fonts have woven over the past twenty years. So registering an axis shouldn't be viewed as either an obvious or trivial step.

Deleted Account

Who are you responding to? Not me... 

"'register an axis' is always going to be the best way to address a specific need"

I didn't write that.

"a kind of panacea for all needs"

Not that either.

"registering an axis shouldn't be viewed as either an obvious or trivial step"

You telling us how we should view things too? wow. 

John Hudson

You said you weren't sure why one thing was one way and another thing another way: expressed in terms that suggested, to me, that registering an axis, contra changing the font format, was at least relatively trivial. I explained why I think those things may be considered differently, and why, in fact, registering an axis may imply changes in the font format, or elsewhere in the overall tex processing and display model.

Deleted Account

John, "why, in fact, registering an axis may imply changes in the font format, or elsewhere in the overall tex processing and display model"

I'm not convinced, per just this one vuid axis, why, "in fact", the implications, and just that, implications of changes to the font format from the registration of an axis, is not better than not registering an axis at all.

At the current rate, we have enough axis to last through 440,000 years of such non-registration as we've got. No one has a gun to the head of format change. But, most importantly, if there is anything wrong with overall text processing and display model, registering an axis that allows developers to circumvent, or improve that model if they wish, hardly seems more threatening than a sleepy kitten. 

Dave Crossland

Just seeing https://github.com/Microsoft/OpenTypeDesignVariationAxisTags/tree/master/Proposals/PPEM_Axis - I was reminded of this thread