[OTVar] Changing tracking/HVAR

Jens KutilekJens Kutilek Posts: 79
edited April 21 in Font Technology
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 :(
Tagged:

Comments

  • Peter ConstablePeter Constable Posts: 83
    edited April 21
    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 PenneyLaurence Penney Posts: 31
    edited April 22
    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.
  • 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."
  • 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 ConstablePeter Constable Posts: 83
    edited April 22
    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.
  • 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.
  • 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 :)
  • D. Epar tedD. Epar ted Posts: 676
    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 HudsonJohn Hudson Posts: 1,026
    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).
  • D. Epar tedD. Epar ted Posts: 676
    edited 11:55AM

    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. 


  • 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 ThomasGeorge Thomas Posts: 360
    edited 3:56PM
    ...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.


  • 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 PhinneyThomas Phinney Posts: 701
    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.
Sign In or Register to comment.