[OTVar] Changing tracking/HVAR

Jens Kutilek

I’m not sure if I understand all of the involved parts/tables correctly yet, thus my question.

Is it possible to build an axis that adjusts the tracking of a font by just using the HVAR table?

I have built a variable font from two differently tracked base TTFs using varLib, tracked 0 and 60 font units, and it seems that a delta corresponding to the half tracking value (30) is stored for every point of every glyph in the gvar table (except the phantom points, which are adjusted with different values (0 respectively 60, the tracking change) as they should be), which seems awfully inefficient. Is there a way around this?

There's also the much simpler ‘trak’ table by Apple, but it’s not a part of the OTVar spec

Peter Constable

I'm not sure about CFF2-flavoured fonts, but for variable fonts with TrueType outlines, that would not be a reliable thing to do. The reason is that the HVAR table is used to modify hmtx values, which you can think of as cached values. Ultimately, the "original" values come from the glyph entries in the glyf table, as modified by the gvar data. There may be layout implementations that always use the glyf / gvar data without referring to hmtx / HVAR.

By the way, check out Frank Blokland's thread in which he proposes a registered "spacing" axis.

Laurence Penney

Without special handling for tracking, the most efficient way to adjust a font’s tracking is to edit the LSB and advance width of each glyph in the hmtx table. These two points (taken from hmtx, not glyf as Peter suggests) are exposed to gvar, as points[numPoints] and points[numPoints+1] respectively, and can be moved like any other point.

There is another method that also avoids moving every point. The "IUP" in the variations engine means you only need to move a single point on each contour.

So I think the problem (where every point is moved) is a tool issue, not a format issue.

Peter Constable

From the 'hmtx' chapter of the OpenType spec:

"The horizontal metrics table provides horizontal metrics for each glyph — advance widths and left side bearings... In a font with TrueType outline data, these values can be computed from the 'glyf' table."

Laurence Penney

That is incorrect and the hmtx specification should be changed — this table is always required, and metrics cannot be derived from the glyf table.

Perhaps the confusion arises from the fact that the origin point and the advance width point can be instructed by TT hints (that are stored in the glyf table). However, the data structure that is constructed by the rasterizer and exposed to TT instructions is built from both glyf and hmtx.

Peter Constable

I'll need to investigate this. I think this may be relevant -- from the head table:

"Note that, in a variable font with TrueType outlines, the left side bearing for each glyph must equal xMin, and bit 1 in the flags field must be set."

For that reason, at least lsb from hmtx is redundant in a variable font.

In any case, my point about only using HVAR is valid since the variation of phantom points can be derived from glyph/gvar, and so HVAR is optional (but recommended) in TrueType-flavoured variable fonts (but not in CFF2 variable fonts), and might be ignored in some implementations.

Jens Kutilek

Thanks, Peter and Laurence.

I did some more tests and it seems that indeed it is enough to store one point delta per contour plus the RSB phantom point delta for each glyph. The rest of the points follows along.

I’ll see if this could be an automatic optimisation in varLib, though it is probably a rare case. If the proposed spacing axis is widely used, it could be built into a font without preparing separate TTFs that would have to be optimized again. It would be easier to make a separate script that could apply this kind of spacing modification to any font.

Laurence Penney

It might be more efficient to make composites of every glyph, then move the composite glyphs in gvar with a single delta, not the original ones with a delta for every contour

Deleted Account

Laurence: "IUP" in the variations engine means you only need to move a single point on each contour."

Yes, there are three instructions

svtca, sets the movement to x or y,
your glyph variation delta(s) here,
iup, cleans up the untouched points in x or y.

Full Throbbing Variations are perhaps thought of as glyph interpolation inside of axis interpolation beside inter axis extrapolation. Indirect interpolation of untouched points, the first part above, is I think, quite important to moving the actual style instantiation down to the client, instead of storing every point's delta in the font. 

The most interesting issue, to me though, about variations for tracking and spacing, is that it is not anywhere in the scope of what our clients want, i.e. something else to futz around with, about that just one thing, external white space. In a world with justification, existing application-level tracking, and now an opsz axis, users having to futz spacing is the last thing I plan on serving.

Font developers who just want to make widths and weight axes, regardless of what size the resulting styles may be useful for, i.e. the status quo for a lot of font families, and then "fix it" for the user with a spacing or tracking axis, are, i think, missing a pointer or two.;)

John Hudson

I don't think it's an issue of users having to futz with spacing, but rather a question of what happens when users do futz with spacing. Layout software has tracking; CSS has letter-spacing. People use these things, and at the moment tracking gets applied independently of the shapes and default spacing to which it is applied. So the question around variable fonts — and it is a question, not an answer —, is whether variations could or should be used to integrate those higher level tracking functions in software and CSS with the glyph shapes and spacing in the font, and what's involved in doing that?

So far, we've got ideas around making tracking proportional so that it reflects glyph shape rather than being a fixed amount added to every advance width, and ideas about adjusting glyphs shapes to spacing (Frank's cadencer model).

Deleted Account

Hmmm... I guess if you're saying the user has to futz with the proportional spacing in your fonts, call it "proportional spacing" futz nob. 

There are also dozens of axes at the level where this one comes from. 

Peter Constable

But do some (lots of?) people futz with spacing anyway?

Or are tracking / character spacing features in apps simply an artefact that designs tailored to optical size went away in the phototypesetting era and didn't immediately return in the DTP era, and that if we can only restore use of optical-size design variants the need for tracking will go away?

Even if use of optical-size design variants does get restored, will people futz with spacing anyway just because their apps support that?

George Thomas

...will people futz with spacing anyway just because their apps support that?

Not for that reason alone. I have used negative tracking on a daily basis although in a minimal way (in InDesign) when it would enable me to achieve a better looking block of type. I'm sure most others who know how to set type do the same. I doubt the desirability of tracking will ever go away even when using a correct op size. It is just too useful.

Laurence Penney

D Epar Ted: "svtca". Of course there’s no SVTCA in gvar — gvar’s "IUP" is implicit and works on both x and y, unlike TT’s explicit IUP[x] and IUP[y]. You could simulate IUP[x] in gvar by just modifying x in a tuple, if you felt like it!

Thomas Phinney

Peter Constable said:

But do some (lots of?) people futz with spacing anyway?

Or are tracking / character spacing features in apps simply an artefact that designs tailored to optical size went away in the phototypesetting era and didn't immediately return in the DTP era, and that if we can only restore use of optical-size design variants the need for tracking will go away?

Even if use of optical-size design variants does get restored, will people futz with spacing anyway just because their apps support that?

Among the kinds of people who will be messing with Variable Fonts, yes, many futz with spacing. Having an optical size axis removes the single most common reason for tracking, but certainly does not eliminate the need.

Deleted Account

Laurence, "gvar’s "IUP" is implicit and works on both x and y"
...thanks I forgot. I added that because a blog on A-P seemed to indicate it was one instruction, delta. Glad we've got that clear as type now. 

Peter, "designs tailored to optical size went away in the phototypesetting era and didn't immediately return in the DTP era,"

Yes, and opszs are just appearing now as a range for users, with variations. We look at the use of "tracking" before postscript, and people did a little, and they did a lot. I.e. they added thin spaces regularly, or ordered sizes on different widths, to make small changes over longer ranges of text. Negative tracking could only be ordered special or made by hand. They also positive tracked a lot, adding en quads, and em quads to space out shorter ranges of display type in uppercase.

If we look at the post-postscript corporate design manuals of the variation alliance today, (and this goes far beyond the var alliance), we see large display size uses with larger negative tracking values, than smaller display uses. And as the modern corrective use of tracking goes down in size, it turns positive, and get larger as it gets smaller.  No, 30 years of futzing obviously can't be a erased overnight, but that tracking can.

Even reinforcements, for the tracking-reducing aspects of the opsz axis, like the width axis, which is also going to impact the amount of futz tracking people do, may not be enough for some. But my customers are not asking for a spacing axis. Not to say that people won't do it, but they don't want to have to do it as they do now. This is, perhaps where John and I part opinions. We are not telling them to, or making them do it, they do their track futzing because they have to, and they have to because they have no optical size axis, and a 5-fingered handfull of widths... if they're lucky.

None of this is reason to ignore the needs of proportional tracking, as that axis, x transparent proportional spacing, is needed — top-level Ui stuff, by a certain class of Latin designs, and several scripts like Arabic, which have not been track-able in the past for lack of variations. Complete solution to this in variations requires a close examination of scripts and styles that operate in proportional, monospace and connected modes, and appropriate axes be defined for all of them.

My lack of rush on "xtps" as I call it, is that no such value, negative or positive proportional tracking, exists in the current font format, unlike the monospace width, which is in the otf spec today, and as such, needs to be a registered axis pronto. So "xtab" is rolling towards registration request, because registering axis, as I suggested last fall, needs to start with existing otf values, like width, weight and size, as it was started in GX... and proceed through just about everything but units per em and copyright perhaps, to make it all variable as the otf spec stands, before stepped into a well thought-out future, hopefully in a standard, published and interoperable.

John Hudson

Or are tracking / character spacing features in apps simply an artefact that designs tailored to optical size went away in the phototypesetting era and didn't immediately return in the DTP era, and that if we can only restore use of optical-size design variants the need for tracking will go away?

Take a look on the Web at the situations in which authors use CSS letterspacing. There's plenty of use of this to space out all-caps and smallcaps (and lowercase, by sheep-stealers, of course), and the amount of letterspacing varies depending on taste and intent.

Adjustment of spacing to compensate for lack of optical size designs is only one use of tracking, and typically involves only small adjustments (e.g. +2/1000 units as I recall applying to the whole text of the Language Culture Type book). At such small size increments, the difference between fixed distance and proportional distance adjustments is insignificant. It is significant when someone is applying +60/1000 units to all-caps.

John Hudson

None of this is reason to ignore the needs of proportional tracking, as that axis, x transparent proportional spacing, is needed — top-level Ui stuff, by a certain class of Latin designs, and several scripts like Arabic, which have not been track-able in the past for lack of variations. Complete solution to this in variations requires a close examination of scripts and styles that operate in proportional, monospace and connected modes, and appropriate axes be defined for all of them.

Yes. But I don't think we should presume at this stage what 'appropriate axes' means.

In this, I guess I'm instinctively a lumper rather than a splitter. Which is not to say that I object to splitting functionality across multiiple axes, but that I want to see the case made for why that makes more sense than trying to combine functionality in a smaller number of axes.

As I said during my TYPO Labs presentation, I'm mindful of the experience of registering OpenType Layout features, in which we ended up with redundant features with duplicated functionality targeting different writing systems. So I'm on the lookout for generalisable descriptions of behaviours and functionality, to determine whether or not these actually require separate axes.

Take the Arabic case: there are letters that connect, there are letters that do not connect, there is space between connected letters, there is space between disconnected letters, and there is space between words. The DecoType/WimSoft Tasmeem user interface implementation treats word-internal spacing and inter-word spacing separately, which allows for a lot of flexibility in producing different kinds of Arabic typesetting, but does this imply that this spacing needs to be separately expressed at the font level? I'd say no, because it's the layout engine that has the knowledge of whether, in a given string of text, a sequence of characters includes a word space or only connected letter or only disconnected letters or some mixture. So it seems to me that a single 'spacing' axis could contain all the information needed for proportional increases/decreases of spacing of connected, disconnected, and word space, and the layout engine could apply more or less in each circumstance according to what the user or an algorithm has specified.

Looking at it another way, we can ask the question 'What should happen if an author applies e.g. .05 em CSS letterspacing to a string of Arabic text?'. That's the sort of question that the W3C internationalisation folks are asking, because they'd prefer all browsers to implement in the same way. Again, I'm not sure the answer implies anything about how relevant spacing information gets stored in a variable font — in one axis or in multiple axes —, because it's the layout engine that's going to be determining where to apply that  information in the string. Now, variable fonts make possible ways of spacing Arabic that have not really been available, notably with regard to spacing of connected letters as D notes. But this suggests to me CSS should have syntax options for different kinds of Arabic spacing, and not necessarily that variable fonts should have different axes for different kinds of Arabic spacing.

Deleted Account

That's saying a lot, John, most of which sounds agreeable.

This one part though, is to me, missing a point:
"At such small size increments, [say +/- 5?], the difference between fixed distance and proportional distance adjustments is insignificant"

this misses one of the points of proportional distances and the proportional spacing axis' capabilities though. fixed distance tracking changes everything, and proportional distance spacing might change somethings but not others, at all.

in several such scenarios small values like the white sliver distances between two serifs of adjoining glyphs in a very heavy Egyptian like Giza, or the delicate black connection of a script face, May Require nothing happening, 0% to some spaces while other spaces are adjusted minimally in the 1 to 5% range.

The difference between fixed and proportional spacing, to me at least, is much more significant, and potentially more visible, and in need of specification and registration as an Axis, at the small end of the spacing range, and less significant or visible at the large end of the range.

Dave Crossland

registering axis, as I suggested last fall, needs to start with existing otf values ... and proceed through just about everything but units per em and copyright perhaps, to make it all variable as the otf spec stands, before stepping into a well thought-out future, hopefully in a standard, published and interoperable.

Does anyone disagree with this?

Peter Constable

The statement seems to be saying that just about everything in the font format should be treated as variable. I can't agree with that as a generalization as I think the need for each item needs to be made on its own. Moreover, I can think of many things besides just upem and copyright that should not be variable.

Belleve Invis

-- DELETED --

Dave Crossland

Peter Constable said:

I can think of many things besides just upem and copyright that should not be variable.

Could you list them, please? Such a list would be helpful for axis proposal authors, to know what is already out of the question

Peter Constable

Clearly not things that we've already made it possible to be variable. It would be many of the things that at present aren't variable: cmap entries, name IDs, OS/2.fsType, unicodeRange and codepageRange bits... 

I don't think this impinges on axis proposal authors since it doesn't affect anything that they currently could make variable.

Dave Crossland

Alright! Thanks for clarifying  

Adam Twardoch

I personally lament that the UPM size isn't variable, as changing the UPM size is one of the most useful tiny operations that have tremendous useful effect if we ever had virtual axes.

If a font has an "opsz" axis (or a set of "wdth", "wght" and "trak" axes), then a "smcp" virtual axis could increase the width, increase the weight, increase the tracking and increase the UPM — and you get small caps, and if the baseline can vary as well, superscripts and subscripts. The type designer could bake in the appropriate combinations of the axis adjustments. 

As I’ve stated elsewhere, I believe virtually all OpenType Layout feature tags should also be permissible as variation axes — smcp, ss01, swsh, sups and many others.

In the UX, when a user applies a discretionary OpenType Layout feature with an auxiliary parameter (like for GSUB Type 3), the font engine should pass the corresponding feature tag, along with the numerical parameter, to the "fvar", "GSUB" and "GPOS" tables, and it shouldn't really matter whether a font implements swashes through variation, substitution, positioning or a combination of these techniques. 

I don't think tracking should touch there glyf table or the CFF2 table at all. We have the GPOS table that already can supply a feature such as "cpsp" that modifies the LSB and RSB of certain glyphs by a given amount. This can be made variable, just like kerning (not sure which GPOS feature should be used though). 

I've created GSUB-only variable fonts that don't have a gvar table at all. It should also be possible to create variable fonts that differ in GPOS only.

Other positioning features that could benefit from being variable are optical bounds — the "opbd" fvar axis would be a good candidate. It could utilize GPOS variation within the "lfbd" and "rtbd" features, and the axis value of "opbd" would determine the amount of bound protrusion (0 = all glyphs are "geometrically" aligned at the edge, 1 = all glyphs are "optically" aligned). In reality, designers may want to vary the strength of the optical bound alignment because it strongly depends on the typographic use). 

Deleted Account

Yes Adam, many wish the upm was variable, but that is not the issue. After asking that question, through a back door, of a member of the group in December, I got the answer, “no upm changes!”. Then I did my due diligence as a developer. The issue is whether the working group has been through the spec, or not, and the answers is pretty obviously NO.

There should not be a question, anymore, about whether or not we are “officially” headed for mildly improved multiple masters, or GX vars. The former was not something I was asked to endorse, so now there will be some extra work retracting that endorsement, most likely.

Welcome to the dumbing down of an Apple technology for general consumption, part three.;)

Adam Twardoch

David, 

I sort of understand why the working group, that I was part of, was careful about introducing too many variable aspects into OpenType 1.8. This effort was very concentrated and really aimed at a “minimal sensible set of things” that could be put into both the spec and an initial cross-platform implementation. 

I did mention that allowing for variable UPM size would be useful, but because that would probably require much more additional research by the potential implementers (checking whether this was an “easy” or “not so easy” change), the overall tenor was “let’s not think about it now”, and I agreed. 

In my 2013 proposal for resurrecting variations in either the OpenType MM model (which was part of OpenType originally) or the TrueType GX model, I specifically pointed out that it was a relatively low-hanging fruit because most of the work had already been done, and there were pre-existing implementations (Adobe did have some code for OpenType MM, and Apple + FreeType did have code for GX Variations). If we were to start working on something entirely new, it would take 10 years to arrive at a consensus, the spec could barely be completed and probably it would all go nowhere. 

In 2012, I proposed to put SVG into OpenType, and in 2013, to bring back variable fonts. In reality, all I did was to write a few long e-mails. I had no idea how this would be received, and when I learned that in both cases, serious people started to actually work on these things, wrote the specs and wrote tons of code to support this, I was not only impressed but also deeply moved. I have tremendous respect for the software developers who have enabled these technologies for all of us.

Because I work with software developers regularly, I know all-too-well that various compromises they enter are rarely because of their laziness or ill will. They have to carefully weigh the things that are likely to be used and the cost — in time which will take to initially develop it, but also time that will take to support it afterwards, to figure out how to make some old gears run on the new juice, and to steer away off the points where the complexity of change would outweigh the benefits by some orders of magnitude. 

When I talk to the software developers who will be tasked with implementing some “ideas” that I grow in my head, I generally trust their judgment. After all, they’re going to build the house that I only imagine, and perhaps sketch. If they’re generally willing to start building but firmly say “this and that thing are no-gos”, I trust that they have good reasons to say “no”. 

In case of variable UPM size, I trust that when they say “it’s not obvious whether we can easily make it work”. I then list the potential benefits of variable UPM, but I know there may be implications which make it hard to realize. I cannot tell if these implications are real or made up, but I trust that if the people who know their shit say they’re real, they mean it. 

Frankly, I still cannot believe that OpenType variable fonts already work in so many places. It’s almost too good to be true. If some improvements can be made, I’ll be even happier. But I’m already super happy!  

Adam Twardoch

Peter, 

I think we're all in agreement that Unicode codepoints shouldn't be variable  

Deleted Account

Adam,

I think, if you don’t want a mm de facto standard to start, then a minimum sensible set of things to put in, is different for a global standard than what is there now. What is there now does not even cover the existing parameters of an opentype font without variables. Perhaps you need to have responsibility for a broad font library that in the near future is requiring stat tables, in order to appreciate what I’m talking about?

I also was not asking about a variable upm because I wanted a registered axes, but rather for the establishment of the best value system to propose for the axes appropriate to em parts. That answer is why we use per mille for all the appropriate axes and not percent.

For upm variation, the glyph, delta and other quantitative data of a variable font, can be quantized via deltas to any upm while remaining on the default upm, which pretty much solves variable upm from Variations. I think people are talking about a “ppm” axis for that, where the value of an instance is the ppm to which the glyphs and data have been quantized.

But clearly, such sensibility in the face of widespread low quality font rendering is only needed in some distant future.

Adam Twardoch

David, 

I'm not proposing to shoot down the process of registering new axes! I think your proposals are sensible, and I myself think the currently standardized system of variable fonts would need to be extended by at least two mechanisms: 

1. Meta axes — originally in GX, axes were present only in fvar and were tied in a hard way to existing deltas.

Microsoft proposed non-variable axes in STAT that go beyond fvar, which shows that there is an understanding that we need an abstraction between user-facing functional axes and the internal technical axes.

STAT format 4 is already such simple abstraction layer as it provides a set of named points in the design space that correspond to different combinations of axes. So while STAT format 4 does not produce a new axis, it goes into the direction. I think we should have a similar mechanism that would actually produce a functional meta axis by traversing along combinations of technical axes — then a "wght" axis could be formed from combinations along low-level technical axes like those you propose. 

2. Feature axes — I think more axes should be registered that correspond to existing OT features, and that any feature (especially user-controlled features) should be possible to implement via variation, substitution and positioning, or combination of those techniques. Right now, we already have a system that allows to supplement variation with substitutions by FeatureVariation. And the intended use case is for glyphs like "$" to switch to a different form. But this can be used much more creatively — for example with "swsh", "smcp" and other features if they're registered as axes. 

3. Some way to break the notion that different variations are different fonts. Currently it is so, so you cannot have positioning happening between different instances, which seriously limits things like variable small caps or superscripts 

4. Variable components — a way to specify derived glyphs like small caps or superscripts in one instance to be composed out of glyphs from the same variable font but in different instances (with scaling).