More granularity in OTVar

Jérémie Hornus

Font-level axis in variable fonts are great. However it seems limiting the possibilities font-designers want to see in fonts now that they know what design-space can do in variable fonts. Indeed, so far axis affect the whole font’s design space and choosing a point in the font design-space affects the whole glyphs-set.

I would like to open a discussion about new possibilities and ideas that were fostered by TypoLabs2018. I am thinking of talks by speakers of the conference and also discussions I had the chance to have there.

Im particularly thinking it would be a step forward to have a mechanism enabling actual ‘smart-components’ and ‘kashida-glyphs’ (local glyph variations) or even non-linear interpolations in OpenType fonts.

I am now thinking of a few things that could enable the new possibilities that were talked about:

- Super Axis (or super-sliders) that would affect relative positions of defined defined axis, and Master Axis (or master-sliders) that would affect absolute positions of defined defined axis >>> enabling non-linear interpolations along curves (cf. <a href="https://www.youtube.com/watch?v=YVMukTiElUQ" title="Link: https://www.youtube.com/watch?v=YVMukTiElUQ">https://www.youtube.com/watch?v=YVMukTiElUQ</a> )

- Selection of postions in the font's design space that would affect only some defined glyphs >>> enabling efficient use of kashida-glyphs, or GEXT axis (cf. <a href="https://www.youtube.com/watch?v=MYLtwQWjTW4" title="Link: https://www.youtube.com/watch?v=MYLtwQWjTW4">https://www.youtube.com/watch?v=MYLtwQWjTW4</a> )

- Local design-spaces at the glyph level with axis that could be shared amongst one or a few glyphs only, but not the whole font >>> enabling actual smart-components at font level. Say for example you have a Chinese radical component with width and weight axis making it usable and customizable in many glyphs depending on its context (smart component) and that component would also possibly be interpolated along the weight axis of the font itself. Meaning the local design space of that glyph would also have positions in the weight axis of the font.

The mechanisms of these ideas must be elaborated and defined more precisely. And this thread could to gather inputs on how they could take shape and how could they possibly be integrated into OpenType specifications in the future.

John Hudson

cf. my TYPO Labs presentation from 2017, which focused on glyph level variation. https://youtu.be/MuuAmG_qer8

Jérémie Hornus

Thank you John, that is exactly the point you made back then.
How do we get from there to actual OT specifications ? Did we have any progress on that side ? Is there technical proposal for these glyph-level design-spaces ?

John Hudson

There isn't a technical proposal yet. @Peter Constable had some ideas about how to express glyph-level interpolation within the design space, but the focus over the past year has been on getting the current OTvar spec supported in as many places as possible, rather than extending the spec.

Jérémie Hornus

With the current specifications today the only solution would be to create one (or more) axis dedicated to a single glyph.

But the thing that is also missing is stored selector(s) for the default position of this (these) axis when used as a Component, and more data for how this default position is affected by traditional font-level axis.

Dave Crossland

The problem we all face with this kind of thing, Jeremie, is that the OT spec itself is not developed in collaboration with the type community, but privately by Microsoft and Adobe (since they were "ending the font wars" at the "jamboree" meeting) and perhap Apple (because of the even earlier TrueType base, I guess) and mainly Microsoft is the owner of the spec. 

Because the spec development happens "in secret" then it can feel very frustrating to some people  to propose things for the spec... and not get any feedback or real peer review, instead it seems that the specification masters just thank such attempts for the idea and then deliberate on it and do it their own way. 

However I can point to graphite as an example of a project which forked the TrueType base and did their own shaping. 

I can also point to the copyleft.next project, which explores a "gpl v4" license text without direct association to the GNU project. 

Dave Crossland

For example, David Berlow publicly proposed 'votf' and 'vuid' at https://variationsguide.typenetwork.com in July last year, and had privately shown that page around to various industry insiders (including myself) earlier than that. These include straight forward and practical visual examples.

But, since these imply or require specification changes rather than being "simple" axis definitions that work unambiguously with in the existing specification, my understanding is that he didn't get any feedback on this, and Type Network was asked to stick to the simple axis definitions that you can see in https://github.com/Microsoft/OpenTypeDesignVariationAxisTags/tree/master/Proposals/TypeNetwork_ParametricAxes

Jérémie Hornus

Registered OTVar tags may be useful for defining a specific rasterizer/shaper behavior (like Optical Size axis) but cannot really bring new possibilities at the font level as they are limited to the current specifications.

As @Peter Constable says in its talk https://www.youtube.com/watch?v=eVWWAvhzrq8 "Anything that's great did not begin that way, it wasn't built on a single day"

Likewise I believe it is time to invest into upgrading the OTVar specifications to support what was described by @John Hudson in TypoLabs2017 and what I am referring to now as glyph-level design-spaces, design-space selectors for components.

There are probably many ways of implementing that in the actual specifications with no ambiguity, that is why technical discussion on this would need to happen with the industry leaders to define things, and so that every font could benefit from these new functionalities.