[OTVar] Suggestion to record in the font whether an axis affects metrics or not

Laurence Penney

I’d like to make a suggestion that the OpenType Variations spec defines a way to record whether an axis changes the font’s metrics. Of course, in principle any axis may change font metrics. But there are significant cases where an axis would not change metrics. Some that come to mind are:

1. Fonts with grades, e.g. Font Bureau Poynter
2. Fonts intended for layering and animation along axes, e.g. DJR Lab [1]; or an imagined version of FF Blur [2] with a Blur axis that offers different blur settings.

The advantage is that text does not need to be reflowed if the axis record asserts that metrics do not change. Such an assertion could be useful for users as well as text rendering engines.

For implementation in the spec, there seems to be a simple place, if the idea is a good one, that is: one of the flags in the VariationAxisRecord for each axis, defined here:

https://www.microsoft.com/typography/otspec/fvar.htm

Fonts built before this spec change would work fine, even if they could have had the flag set. Thus the flag should have 1 as the setting that asserts static metrics for the axis.

Any thoughts?

[1] http://stuff.djr.com/variable-demo/
[2] https://www.fontfont.com/fonts/blur

Khaled Hosny

But text flow depends only on GPOS table i.e. even if the metrics do not change, glyph positioning like kerning might be.

Laurence Penney

Indeed, it’s a complex business. The purpose of the flag would be to help the renderer know that the metrics, including kerning, do not change in any way. The same flag should also assert that glyph substitution works identically along the entire axis; glyphs turning into ligatures trigger reflow, even if the width is unchanged.

John Hudson

I need to think through this carefully, but it seems to me that what we're basically asking for is that these axes — whether flagged as Laurence suggests or not — have no impact on GSUB or GPOS. I think they would need to be made that way, and if flags are involved then font tools should alert if GSUB or GPOS contain any dependencies on those axes (e.g. a GSUB lookup that applies only within a certain range on a grade axis). A font maker shouldn't be creating a font that has such dependencies, and thing setting a bit that says those dependencies are ignored; better not to include them in the first place.

Laurence Penney

It seems to me that the usefulness of this flag is comparable to that of the monospace flag(s) in fonts.

Laurence Penney

The flag would be zero for any axis that had an effect on advance widths, as well as GPOS or GSUB.

John Hudson

Agreed, but like that it has implications both for software and font makers. In the same way that a font with monospaced flags set really does need to have all glyphs share a common advance width, there are things that need to be spelled out regarding how axes with such flags as you propose are built and how they interact with other axes in the design space.

Laurence Penney

It has implications in the sense of an optimization on output, that occurs only under specific circumstances, and is not an error if left undone. A monospace font still works fine without the monospace flag (or PANOSE number) set. A tool might for convenience offer a monospace button, or a "static metrics" button, which, if it could not be set, would ideally report in what ways the font had to be adjusted in order that it be set.

James Puckett

Might this be important for things people do in display type?

Laurence Penney

Yes, James, I think so. I mentioned it being useful for people using variations fonts for layering and animation effects to have a guarantee of static metrics.

Peter Constable

Some questions:
What problem are we trying to solve?
What scenarios would this be used in?
Who / what would be expected to use this information, and how?

Laurence Penney

To answer your questions in order:
1. The problem where a user does not know whether adjusting an axis will affect text flow, layout, pagination, etc.
2. A UI offering adjustments of: i. font grade, or ii. fonts potentially suitable for animating along an axis, or iii. fonts suitable for layering by means of setting various instances on top of each other.
3. In the case when the flag is set, an app’s UI can indicate to the user that it is “safe” to adjust the axis: that there would be no reflow.

Ray Larabie

What scenarios would this be used in?

If you have a system where ascender/descender axes can be adjusted to avoid individual vertical collisions, steady metrics would prevent moving targets. If you have a tall accented letter on one line and a colliding descender on the line above, pulling the descender up shouldn't cause the accented letter to move.

Laurence Penney

In Ray’s example, of course nothing in the current spec stops an axis behaving in this way. Yet, if the examples of grades, animations, layers and ascender/descender become reasonably common, users of fontmaking tools will likely want to guarantee that the axis in question never changes metrics. A tool’s ability to confidently set a flag in the binary font seems to be a more reliable way of achieving this than, say, writing a script that checks various metrics under various axis settings, and advising font users of this useful fact via documentation. A fontmaking tool having a “static metrics” option on an axis would handily enforce this, and might well provide useful feedback to the fontmaker on how to fix the font to allow the flag to be set. Perhaps the spec should state, regarding implementations: if the bit is set, metrics MUST be taken from the default setting for that axis.

Peter Constable

Laurence Penney said:

To answer your questions in order:
1. The problem where a user does not know whether adjusting an axis will affect text flow, layout, pagination, etc.
2. A UI offering adjustments of: i. font grade, or ii. fonts potentially suitable for animating along an axis, or iii. fonts suitable for layering by means of setting various instances on top of each other.
3. In the case when the flag is set, an app’s UI can indicate to the user that it is “safe” to adjust the axis: that there would be no reflow.

Based on your answers, it seems like meta-information, such as a user guide for the font, might solve the problem you cite nearly as well (and without a spec change and the ensuing costs for software implementations), with the only particular advantage of a flag within the font being that it wouldn't be easily misplaced.

Hrant Հրանդ Փափազեան Papazian

Pretty much any axis will/should affect spacing... :-/  So I'm not sure how useful a flag would be. I think it's better for a typeface to instead afford a Uniwidth toggle on its own.

BTW the relevance of uniwidth is not at all limited to display. People often change their mind about some attribute of a long text setting after a point they want to avoid reflow.

John Hudson

@Laurence Penney

A fontmaking tool having a “static metrics” option on an axis would handily enforce this, and might well provide useful feedback to the fontmaker on how to fix the font to allow the flag to be set.

But if a font tool has such an option for an axis, both in terms of helping a font maker to work with static widths on that axis and generating a font that ensures widths on that axis are static,* then a flag within the format is only potentially useful to an application that wants to cache advance widths (which was the point of the monospaced flags). Given that, independent of the axis with static widths, the widths might be adjusted by even the smallest variation along another axis, I doubt that metrics caching is going to be a significant concern for layout engines supporting variable fonts.


*As I try to imagine the design process of a variable font in which one or more axes maintain static widths relative to non-static metrics in other axes, I'm convinced that tool-level assistance is going to be vital.

Simon Cozens

I'm not convinced that this is even that useful from a rendering software perspective. If the font changes, you have to update the display, and you will be doing some substantial work to erase the old text and lay out the new text. You may as well try laying out the whole paragraph anyway regardless of the value of the flag. If the text does reflow, it needed to reflow. If the text doesn't reflow, nobody notices because nothing has changed and you wasted a couple of milliseconds. Big deal.

Rewriting your rendering app to read flags from the font and check them when replacing text is a bigger deal than what you'd save by skipping a useless reflow.

Laurence Penney

Thanks all for the feedback on the suggestion. I think it’s clear we need more information — what kinds of fonts people will build, what UIs will emerge for interacting with variable fonts (e.g on the web and Illustrator), and how designers use variable fonts — before taking it any further.

Simon & John: I was thinking about this as primarily of benefit to font users, just as the monospace flag benefits coders who wish to see a list of fonts ready for code editing apps.

Peter Constable

If there were some automated algorithms in which layout engines were tweaking an axis value several times to arrive at some desired result, then there could be a performance benefit of being able to assume that the layout did not change -- i.e., same glyphs at the same offsets. (So, no metric changes, and no feature variation triggers that result in different GSUB or GPOS lookups being processed.) But it's not clear to me what kind of algorithm that would be. E.g., we can imagine algorithms that tweak width to achieve some line-fitting result, but that is clearly something that would change the layout.

John Hudson

@Laurence Penney

Simon & John: I was thinking about this as primarily of benefit to font users, just as the monospace flag benefits coders who wish to see a list of fonts ready for code editing apps.

So to have reliable metadata by which to indicate that a specific design axis won't affect layout? Yes, I can see value in this, but that's also true of a huge range of other information about font behaviour that is typically included only in external documentation and not readily machine parseable. EPAR table anyone?