Wish: Designspace Completer

[twardoch]

Wish: Designspace completer

There are several tasks for which a new tool is needed, a DesignSpace and/or font "completer". It could solve https://github.com/googlefonts/fontmake/issues/607 but also the following:

You know that the Designspace for VF needs all masters to be addressable from the neutral by a single move along one axis, and also how .designspace does not allow you to define regions for intermediates.

So right now, what one needs to do is to turn a dev designspace into a production designspace by:

Completing master alignment

For example when I have 2 axes with 4 corner masters and I'd like to use the center as my neutral — 5 more masters are then needed to go from 4 to 9. These masters CAN be interpolated from the 4, and THEN varLib could build the VF. That could be a step done by the completer.

Restricting intermediates by adding countermasters

If you have 2 axes with 4 corner masters and you add 1 intermediate at one of the edges, due to the way VF works, it's unrestricted so it pushes all its deltas to the opposite edge, ruining the interpolation. So a countermaster is needed at the opposite end, which is purely interpolated without taking that intermediate into account. Than you have 6 masters, not 5, and then you get the result you want. Again, this can also be done in software, so it's a task for the completer.

Desparsing

And the other completer task could be "desparsing" sparse masters to address the problem of https://github.com/googlefonts/fontmake/issues/607

I personally think that work would need to be done on GPOS varmerging in varLib so it's not "stupid". I think right now it just goes by lookup indices and GIDs. But it probably should go by single rules, adding deltas to actual rules defined in lookups assigned to specific features.

Alternatively, there could be a step that takes a neutral master, and your static sparse, and then builds a fake master that is based on the neutral, but with the sparse glyphs patched in, and with a GPOS where all the adjustments are set to 0 except those defined in the sparse GPOS.

And then varLib would use that fake master instead of your real sparse.

Conclusion

It's not a hard problem. Figuring out the locations for the locations of the extra masters needs to be done carefully. But overall, it's solvable but code needs to be written.

It's also a "universal" solution — by large, I think there's only one good way to solve this. So that qualifies for an opensource tool, unfortunately one that is beyond my abilities.

[madig]

Completing master alignment

This is doable, but is it desireable? The only effects this achieves AFAIK is that legacy apps see the center outlines by default and the file size gets blown up.

The other use-cases sound desireable to me.

[twardoch]

If you combine completing master alignment with desparsing, you basically get a "normalized" designspace + masters. This should be the intermediate step, and then software would "compress". It’s a task for compression to figure out, ultimately, which master should be "main" and which ones should get deltas. Lots of compression could be done if you throw away the notion of "main", "full" and "sparse" design masters, normalize everything, and then compress.

This is the same with class kerning. Designers should be free to class-kern as they want. Software should "expand" all the kerning, and then "simply" find the most optimal "variable GPOS" representation that uses, classes, multiple lookups, whatever you want, so that ultimately, the thing is smallest but functionally the same.

[twardoch]

One could still ignore this completion/"normalization" and prepare DS+UFO/TTF/whatever in an "engineering" way, if you want more control. But then you also potentially hit a lot of obstacles.

Turning flat kerning into static or variable GPOS, turning a large set of complete masters into a VF.ttf or a VF.otf — that’s all, really, compression. In an ideal world, it should be done by "compression people". This has very little to do with "design".

[twardoch]

Another task for the tool could be normalizing the designspaces in cases such as https://github.com/daltonmaag/statmake/issues/19 i.e. performing all sorts of projections from freely distorted design designspaces to orthogonalized production designspaces.

In current VF, this projection process would need to be done via a clever combination of simple mesh corner movements, avar and addition of intermediate masters. In future, the same tool might produce a suitable avar v2 data.

[weiweihuanghuang]

From what I understand what @twardoch is saying it seems like any axis that affects weight, when coupled with contrast and proportion, will very likely not have orthogonal instances... and adding masters to skew the space a bit extreme.

[madig]

I suppose you can add all instances as masters and then generate fresh new corner masters and maybe a center master. That will give you a clean rectangular Designspace. This will result in lots of off-by-ones, but maybe it doesn't matter for some projects?