[OTVar] Defining instances in the font vs. defining instances in CSS

Paul van der Laan

Georg Seifert said:
But that is a problem with your tools and not inherent to interpolation. 

But rounding errors for point coordinates are inherent to interpolation.

(Unless there is a hinting mechanism applied directly after interpolation. But I don't think OTvar offers that.)

Georg Seifert

But who is using a font in 1000 pt to see a 0.5 unit difference? At 50 ppm, the possible rounding errors would result in a difference of 1/40 of a pixel. and for printing, the grain of the paper gives much bigger 'errors'. 

Is there a chance that we meet somewhere. I would love to discuss the problem in person. Maybe you can show me some examples that result in bigger errors?

Jens Kutilek

The rounding error is actually twice that, because what we see is a stem, i.e. the black distance between two lines. Each point on either side of the stem has up to 0.5 units rounding error, so the stem can be up to 1 unit off. (left point rounds down and right point rounds up = +1 unit, left point rounds up and right point rounds down = -1 unit)

Still it's hard if not impossible to see, and by increasing the upm in TT conversion it gets even more negligible.

But I understand that designers want to be in control, I myself checked all the ink trap lenghts in my interpolated instances

Ben Blom

If you want, you can use an avar table to tweak the coordinate space so that a request for wght=500 lands on 550 in your design space, thus making sure you get what you want in all circumstances.

I hope that font tools that support creating variable fonts, will offer a user-friendly interface for such tweaking.

Georg Seifert

But there are tools to circumvent most of the problems, now. 

And all the rounding problems do not apply for variation fonts. Because the do not round.

James Puckett

Glyphs users can use the interpolation preview and a hi-DPI display to identify visible rounding errors without even generating a font.

John Hudson

@Gustavo Ferreira

Default font styles are always a compromise, because a font cannot know about the document in advance. Being able to easily edit and fine-tune default font styles per document (and per context, via media-queries) is a very useful feature, I think. That’s what responsive typography is all about, no?

Yes, which is why I acknowledged that providing this sort of CFF recipe to users might be a useful thing that will aid easy editing of instances for the Web. What I don't see as a benefit is doing this instead of including named instances in the font, since the latter have applications beyond the Web.

John Hudson

@ybaggar

What @Rob McKaughan wrote is correct insofar as if a font is built in a way that there is any interpolation space at all between instances, there is no way to prevent a user from accessing that space, presuming an appropriate environment. What I described was a hypothetical font in which the font variations tables have been built to restrict that interpolation space, such that there are sudden jumps between predefined instances, rather than an accessible transition. So, for example, above a certain point on the weight axis, the design jumps to a predefined bold instance, and that design remains unchanged along the axis until another point at which it jumps to a black instance. I believe the data format would allow this.

Nick Shinn

As a variable font contains interpolatable masters, what is there technically to stop an application hacking the font—working directly from those masters to create nice intermediary instances, bypassing any discrete-step named instances?

PabloImpallari

The whole point of the thing is to enable that, why would you want to disable it? In that case just use standalone fonts.

Yªssin Bªggªr

@John Hudson I'm confused now. If I want 5 accessible weights from my typeface, but not the intermediate spaces, is it doable with 3 masters, or are now 5 masters (delta if I understanding correctly) necessary to do what you describe? 

Didn't realise we were off-topic here, discussing the same issue than in the main OTvar thread. Sorry about that.

John Hudson

@ybaggar The concept of 'masters' really doesn't apply well to OT variable fonts. A variable font consists one 1 set of outlines plus n delta sets defining a variations design space. What I am talking about is basically how that design space gets divided up, functionally for users of the font, which is a separate question from how many delta sets there are. So what I call a restricted variable font could be made with as few as one delta set in addition to the outline set, i.e. With the outline set representing one extreme of an axis and the delta set representing the other extreme. The variable font technology is designed to enable interpolation along that axis, but also allows the font maker to control the interpolation in a number of ways. These control mechanisms could, I believe, be used to restrict access to discrete instances along the axis. Think of it this way: accessing any point along the axis between e.g. 40% and 65% would return exactly the same discrete instance, and >65% would jump to a different discrete instance, without giving access to any interpolated instance between those discrete instances.

As I say, I believe this should be possible, based on my understanding of the spec. I don't think it is a particularly good use of the technology, but I can understand the circumstances in which someone might choose to make a font in this way.

John Hudson

@Nick Shinn

As a variable font contains interpolatable masters, what is there technically to stop an application hacking the font—working directly from those masters to create nice intermediary instances, bypassing any discrete-step named instances?

Note that the discrete step concept isn't tied to that of named instances. One could make a font with discrete steps in the axis behaviour that didn't correspond to named instances. Think about it this way, in the same way that one can make a variable font that includes a sudden change in form of a glyph at a particular point along an axis, one might also make a font that consists only of sudden changes, and for all glyphs instead of one.

Yes, the 1+n outline and delta set that define the design space are present in the font, regardless, so in theory an app could hack the font to provide non-restricted access to the design space. But this means overriding quite a lot of data in the font.

Thomas Phinney

ybaggar said:

@John Hudson I'm confused now. If I want 5 accessible weights from my typeface, but not the intermediate spaces, is it doable with 3 masters, or are now 5 masters (delta if I understanding correctly) necessary to do what you describe? 

No. It is doable with three masters. Heck, it's doable with two masters if you make one of those two masters the default instance.

(John gave a much longer and completely correct answer, but that's the short answer.)

Thomas Phinney

I also agree with Pablo, btw: enabling interpolation is usually part of the “point” of variable fonts. I suppose there might be cases where you are desperate for a little more compression, want to limit functionality, and are willing to risk confusing users while doing so. But that seems a bit perverse.

I'm also reminded of an example somebody mentioned to me in email, where as part of brand identity or the like, somebody wants to limit a variable font which has a bunch of standard instances to a *very* few available instances. My basic thought is, well, just give them a few separate fonts instead. Or build a new variable font for the customer that only has the particular desired instances predefined.

Ray Larabie

Or build a new variable font for the customer that only has the particular desired instances predefined.

I was thinking along those lines. Don't get me wrong: I would never want to create a variable font with limited instances. Just toying with the idea. It might be possible to create a tool in the editor where you could choose instances along various axes. You've use those instances to generate deltas, make 2 copies (sort of) and put them next to one another on the axes at the closest possible distance. It's a bit like that Q tail popping trick we'd been discussing. That way the user could move the slider and only see discrete steps rather than a continuous range. Ridiculous and inefficient but technically possible, I think.

Georg Seifert

Building a variable font with limitiert instances like described above will blow up the file size a LOT. So if you really don't like customers to be able to interpolat, ship a .ttc. 

It is interesting that most discussions here are about finding the breaking points of the format, instead of discussing proper/new use cases. 

Ben Blom

The whole point of the thing is to enable that, why would you want to disable it? In that case just use standalone fonts.

It seems that Pablo missed ybaggar’s contribution here, and my contribution here.

Building a variable font with limitiert instances like described above will blow up the file size a LOT.

Why would this happen, if an avar table would be used to tweak the coordinate space? Perhaps Rob McKaughan can say something about this.

It is interesting that most discussions here are about finding the breaking points of the format, instead of discussing proper/new use cases. 

Discussing ways to restrict the functionality of a variable font, is discussing proper/new use cases of the format. (These may not be interesting use cases for people who primarily focus on the new technical possibilities of the format, and who do not care much about the marketing of fonts.)

Try to imagine a future world, in which most customers expect to buy font families packaged in variable font files. If you don’t want to create a restricted or discrete variable font—would you then, because of that, force yourself to only sell variable font families with the maximum possible functionality?

From a marketing perspective—the option to restrict variable fonts (and tools which support that), may be vital for the success of variable fonts.

Ray Larabie

It is interesting that most discussions here are about finding the breaking points of the format, instead of discussing proper/new use cases. 

The actually intended use isn't interesting to me. When they make these new font formats, they always seem to have to most boring text applications in mind. New ways to do the same old things. I want to figure out the breaking point of this thing so I re-purpose it. I think what's more even interesting that the interpolation aspect is the ability to substitute glyphs based on axes. You could make a geometric dingbat font where you could select a shape on a slider (star, asterisk, polygon, tree), use another slider to change the number of sides, another to affect the thickness of the strokes. Maybe an axis that changes CPAL presets too.

Peter Constable

Re restricting selectable instance values (this will get technical):

As an example for sake of discussion, consider a font with a weight axis, with min, default and max 'wght' values of 100, 400 and 900. In internal processing, those weight values will get normalized to -1, 0 and +1 respectively. Any intermediate 'wght' values get interpolated between those; e.g., 250 would get normalized by default to -0.5, and 650 would get normalized by default to +0.5. (Those are details of how all OT variable fonts work).

But the 'avar' table can alter the normalization mapping. E.g., you could specify that 250 should normalize to -0.6 instead of -0.5. The way that would be done would be to have an 'avar' entry that maps the default normalized value of -0.5 to the desired normalized value of -0.6.

Now, suppose that you wanted to prevent 250 or any other values between 100 and 400 from being selectable. I.e., suppose you want the only selectable values to be 100, 400 and 900. A way you could do that would be to have 'avar' entries that map (say) anything in the range (100, 250] to a normalized value of -1.0, anything in the range (250, 400) to 0.0, anything in the range (400, 650] to 0.0, and anything in the range (650, 900) to +1.0. I've described that in terms of "user" values from 100 to 900, but the 'avar' entries are actually expressed in terms of the normalized scale from -1 to +1. The normalized values are represented in F2DOT14 format, which means a fractional granularity of 1/16,384. So, to divide up the (-1.0, 0) range, you could have 'avar' entries that map -8,191/16,384 to 0, and -8,192/16,384 to -1. That would result in any 'wght' value in the range (100, 250] (default normalized values -1 to -8,192/16,384) normalizing to -1, and any 'wght' value between (250, 400) (default normalized values -8,191/16,394 to -1/16,384) to normalize to 0.

(Note: an 'avar' table must have entries that map -1 to -1, 0 to 0, and +1 to +1. That's why I've described ranges up to but not including the min, default, and max values.)

Thomas Phinney

Georg Seifert said:

It is interesting that most discussions here are about finding the breaking points of the format, instead of discussing proper/new use cases. 

I agree, but understanding what a tool cannot do—what it’s limits are—is very helpful in developing a full appreciation of the scope of the tool.

Nick Shinn

I’ve just published a typeface with <calt> driven “bounce”. I provided two degrees of bounce, as separate fonts. I named one Regular, and the more lively Forte. A variable font would be ideal for this concept, as typographers could use a slider to eyeball how much bounce they want (quite a size-specific quality), without having to deal with a lot of fonts with a custom naming system.

Happy now, George? :-)

Georg Seifert

I'm very happy to poke holes in very thing new that comes along, don't get me wrong about that. I was just missing some discussion going the other way to use the possiblities of the format in a way other than the obvious cases. 

Georg Seifert

And question about the 'limited' variation fonts. What would be the difference for the user if he had a ttc file or a limited variation ttf (other than the file name and a 'useless' slider in apps that would show them).

Thomas Phinney

File size may be smaller.

David Lemon

I have to agree with Georg. If you don't want users to have access to the design space, don't give them variable fonts. A ttc with the specific fonts you want them to access would have nearly as good a compression without confusing people.

I think Ben's overthinking this. There's no reason to expect variable fonts will drive out all legacy fonts in the next decade. And there's every reason to expect many fonts (including new ones) to continue shipping in the formats available today.

"Marketing" a variable font that can't actually vary doesn't seem like something that would appeal to any customer I can imagine.

Ben Blom

Perhaps I am overthinking things. I can understand the hesitation to say that a variable font in which the variation consists of discrete steps, does vary—although I do not agree with it. Perhaps using a label for discrete variable fonts without “variable”, might make sense. Perhaps a TTC will prove to be a better way to pack traditional font families. Perhaps my guesswork about what has market potential, will prove to be wrong. The future may be far away. No one knows which scenario will unfold. Let’s wait and see.

Thomas Phinney

While it is technically true that “no one knows which scenario will unfold,” it is also true that some scenarios are much more likely than others, and that people need to attempt to plan for the future. (Indeed, to some extent people reading this thread and making decisions in this area are creating the future.)

My ability to predict these things is not perfect, but I'm reasonably happy with my ~ 80% average on those matters I have a strong take on (such as this).