[OTVar] Changing tracking/HVAR

Jens KutilekJens Kutilek Posts: 105
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: 111
    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: 38
    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: 111
    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.
  • Jens KutilekJens Kutilek Posts: 105
    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: 702
    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,145
    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: 702
    edited April 26

    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: 371
    edited April 26
    ...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!
  • 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.
  • D. Epar tedD. Epar ted Posts: 702
    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 HudsonJohn Hudson Posts: 1,145
    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 HudsonJohn Hudson Posts: 1,145
    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.

  • D. Epar tedD. Epar ted Posts: 702
    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.
Sign In or Register to comment.