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.htmFonts 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
Comments
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?
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.
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.
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.
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.
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.