[OTVar] Introducing OpenType variable fonts

TimAhrens

Thanks for the comparisons, @Jens Kutilek and the detailed explanation, @Rob McKaughan.

This is roughly what I had in mind when I raised the question. Theoretically, a really good general-purpose compression algorithm might detect all the redundancy and potential for compression described by Rob, even if not expressed as differences via variable fonts. It seems that in practice, multi-font compression is somewhat – but not drastically – behind. So, regarding the file size, variable fonts probably bring some clear improvement, but not as miraculous as some of the initial presentations suggested. Maybe even more tests would be needed. All this may look like a nit-picking business but I guess that is just what any attemt at file size reduction is about.

Jens Kutilek

Rob McKaughan said:

I suspect this is what's behind the difference @Jens Kutilek found above. The difference would be greater if the variable font were hinted in VTT.

Does VTT support CVT variations yet? What would happen when the font (main master) is hinted in VTT, but no cvar table is present? Would the values from the CVT table be used for all interpolated instances?

Rob McKaughan

@Jens Kutilek : We're working on it (see the video of the presentation for a little of the UI in progress).

If the font doesn't have a cvar table, then it will use the same CVTs for all instances in the family. If you use CVTs for stems, this likely won't work so well as your different widths and weights likely have different stem widths.

However, it may make sense in some scenarios. For example, I hinted Selawik with the autohinter and the light hinting technique that @Mike Duggan has advocated in his blog posts. This technique only uses CVTs for the vertical metrics of baseline, descender, ascender, x-height, cap height (all with/without overshoots). Selawik's design, which follows Segoe UI, doesn't change vertical metrics across the weight axis. So, I could have completely hinted Selawik without a cvar table.

[That didn't make for a very interesting test case, though, so I went back and added CVTs to stem hints in the lowercase just so we had something to vary. This is the font that was in the VTT demo at AtypI]

Georg Seifert

As @Jens Kutilek the file size for two masters is close. And the variation fonts exported from Glyphs don't include all needed tables, yet. So the files will be a bit bigger in the end. So storing two masters just takes a certain amount of space. 

So, if you need to deliver two masters, a variation font will have have no advantage over 'normal' compression (as woff2 seems to be much more effective with plain ttc).

So variation fonts don't save space if we use them as a drop in replacement for current designs but the new format might shine differently.
For now, web designers are forced to keep the number of faces down to a bare minimum, e.g., you would not use a different weight/style for smaller text. But give much more possibilities. You have one font that can adapt to type size (body vs caption), device, screen size, rendering... (using a slightly heavier wight on Mac Retina?)

Georg Seifert

When I was implementing the OTVar export the first examples looked quiet w bit strange because the base font would have some hints and those would keep stems form getting thicker – because I didn’t provide a cvar table. So the the instructions are ''stronger" than the deltas

Nick Shinn

From a practical, editorial page design point-of-view, it would make a lot of file-reduction sense to produce one font that comprises Regular, Italic and Bold. (Microsoft was on to something with its RIBBI blinkers!)

Kind of like the way Linotype combined disparate styles into the same matrix(?).

For serif body, a serif italic and bold sans subhead would be more use than extreme and marginally different weights.

Ovar seems more targeted at multi-weight sans, but realistically speaking, how many weights of sans are (good) designers going to be putting on a page? 

Optical scaling would be the most promising use, so far, but I’m sure there will be other possibilities, just as <calt>, ostensibly for connected scripts, led to pseudo-randomization.

Belleve Invis

Georg Seifert said:

When I was implementing the OTVar export the first examples looked quiet w bit strange because the base font would have some hints and those would keep stems form getting thicker – because I didn’t provide a cvar table. So the the instructions are ''stronger" than the deltas

Instructions are applied AFTER deltas, so, it is a by-design behavior.

Chris Lozos

"how many weights of sans are (good) designers going to be putting on a page? "

It is not a question of "how many" but more which of the many are best for that instance. The idea of a large family with many weights is not to use them all on one page at once but to have them on hand for the times you need them.  Think of them as a set of tools like drill bits, you won't need to drill every size hole in your tool kit for every job but when you need a 7/16", a 1/4" won't do.

SiDaniels

Once the variable font is downloaded and cached it can be used on multiple pages, or even across different sites (depending on permissions). But there are also bad designers and ransom note writers who will use infinite styles on the same page.

Georg Seifert

Nick Shinn said:
...

For serif body, a serif italic and bold sans subhead would be more use than extreme and marginally different weights.

And that is exactly what you can’t do with variation font but with a collection font (.ttc or .otc). And those are widely supported already.

Belleve Invis

Can I “blend” a subroutine ID, or its arguments, in CFF2? like `1 2 3 4 5 1 blend callgsubr`.

kupfers

I’m surprised almost everyone is talking about different weights. To me the possibility of different width, especially in responsive design, is much more exciting. I would want to use a 4 master vfont on the web. 

Chris Lozos

I suppose you could tune the width for proper grid fit.

Atilla Korap

@Indra Kupferschmid That's true. The number of use cases for different width is much higher. Just think of all the devices that just start to connect to and pull content from the web. Many of those are still quite low res, too.

Belleve Invis

@Rob McKaughan

I have some questions about using blend in CFF2.

1. Can I "blend" a subroutine index?
2. Can a blended result be an argument of another blend operator? If so, then CFF2's blend CAN support non-linear interpolations.

And about APIs on Windows

1. Can I install an unmodified variable font into Windows system using the built-in control panel, or I have to load them manually from the program I wrote?
2. Can I display them using GDI? If so, can variation being supported?
3. Can I display them using DirectWrite in win32? If so, can variation being supported?
4. Can I display them using DirectWrite in UWP? If so, can variation being supported?
5. Are there any API, or API proposals for extracting outlines under certain style?

Rob McKaughan

@Belleve Invis

I'm not well versed in CFF2. I think blend is essentially a mathematical operator. @Read Roberts is the expert and will be able to answer this better.

For Windows: @Peter Constable can give the official word (he'll be back online next week). The Win10 Anniversary Update has a little bit of support, with more coming in 2017. In the Anniversary Update, you can install a variable font just like normal (though in the Font control panel, you'll only see the default instance at the moment). DWrite clients (UWP, win32) will enumerate all of the named instances listed in the fvar font. I test things by installing the font, then writing an HTML doc that references the named instance in the font-family property.   

Nick Shinn

I agree with Tim Ahrens that the “faster download” rationale has issues.

The reason is simple: users will often mix typefaces.

A typical site will have a plain Regular Roman and Regular Italic for body text, plus a different style for headlines. That’s three fonts now, and three OTVar fonts—which are bigger.

Now consider Wiki.org, for example, which uses Helvetica Regular Roman, Regular Italic and Bold Roman, and Times Regular Roman. Four fonts now, three OTVar fonts—which I’m assuming would weigh in larger. Now here’s the kicker: optimally, this site would use two noVar fonts and one OTVar. 

Now, it could be argued that web designers are not presently using *lots* of fonts in their designs, due to download time issues—however, cluttering up layouts with lots of different fonts has rarely been a best practice.

So it looks like, for new typeface designs, we will be producing both formats.

Johannes Neumeier

Super exciting news. One thing that I instantly wonder is how to tackle the already very confusing communication of what is included in a typeface. Even now quality and extensiveness of opentype features are not exactly easy to transparently communicate to the user. Imagine typefaces that can vary from a single small display glyph set to superfamilies with multi-axis design spaces, and to the user they are all just one file they purchase, the one costing $10 and the other $500.

Belleve Invis

@Rob McKaughan
And the last question is: If I install both a non-variable font and a variable one, what is their application priority? I have a series of non-variable fonts with size-dependent gridfits (to merge strokes under certain physical size), and an unhinted variable one, and I want browsers to use the hinted ones for major styles, while unhinted under other styles.

Georg Seifert

I don't think that is a valid use case. You don't expect to have a .otf and .ttf installed and have the pick the right font for your particular use case.

you can define intermediate designs to deal with the stems and such. 

Richard Fink

John Hudson said:

@Richard Fink

In particular - is there any control over the resulting font-weights the type designer must forsake to give the customer the benefits of runtime interpolation? 

Not 100% sure I understand the question as posed but, with regard to control, any location within the variations design space can contain a delta set for one or more glyphs. So there's no reason for the type designer to 'forsake' control. As an example, a font with a weight axis might contain not only delta sets at the extremes of that weight axis — say, thin and black — but also any number of intermediate delta sets to control regions of the axis between the extremes — say, regular and bold. Again, these intermediate delta sets could cover the whole glyph set, or any subset, or a single glyph. The intermediate masters do not need to sit directly on an axis: in a multi-axis font, a delta set can sit anywhere in the design space between the axes.

Ok. Here it is, simply put.
I'm Nick Shinn and I have a font named Figgins. It comes in a bunch of weights. The difference between the lc 'b' in the Medium weight and the Black weight looks like this in Fontographer. (Why Fontographer? It was handy for some reason. Nick was in the mood to share Figgins.)

Now, what if, for some reason - with the current interpolation settings, Nick wants to tweak the lc 'b' in the Black weight to this:

You can see the alteration in the lower right part of the bowl.

Now, when the interpolation is on the designer's end, with different weights in different files, it's no problem. Nick just makes the adjustment by eye or whatever reason he's got. 
But what's involved in getting the same result on the client end with client-side interpolation?  What instructions if any do you have to include to get the same result?
Can you get the same result? Or do you have to live with the same math across the board?

If I had an in depth knowledge of Apple's GX spec or Multiple Masters, this might be a dumb question. It might be a dumb question anyway.  
But what's the answer?    Thanks.

Nick Shinn

I don’t approach interpolation in a systematic manner, I would have to change my method for variable fonts, and make the masters more consistent, and fewer of them.

For instance, in Figgins Standard, I changed the shape of the counter construction between Medium and Bold and between Bold and Extra Bold. Therefore, any layout application interpolation between those weights would be problematic—because of the different number of points, and the design premise that the joint has to be either smooth (“tangent”) or angular.

Glyphs shown: Figgins Standard: Regular, Medium, Bold and Extra Bold.

**

A classic example of disjunctive construction between weights is the tail on /a in Helvetica, which disappears between Medium and Bold. With a variable font, the type designer would have to specify exactly where between 65 and 75 the tail is cropped, and that would be the position of the masters (one for interpolating with lesser weights, one for interpolating with greater), even if it did not correspond to a “named” weight on the numerical scale.  

However, if a typographer is adding or subtracting weight to 65 or 75, say for the purposes of optically adjusting for the difference between positive and negative type, it would probably be best to put the masters bang in the middle, between the traditionally named weights.

Richard Fink

Nick Shinn said:

I don’t approach interpolation in a systematic manner, I would have to change my method for variable fonts, and make the masters more consistent, and fewer.

For instance, in Figgins Standard, I changed the shape of the counter construction between Medium and Bold and between Bold and Extra Bold. Therefore, any layout application interpolation between those weights would be problematic—because of the different number of points, and the design premise that the joint has to be either smooth (“tangent”) or angular.

Figgins Standard: Regular, Medium, Bold and Extra Bold.

OK. So you are saying - and I'm glad I used Figgins 'cause now I got you into the discussion with a real-world use case - that what you've done is, how shall I put it? -  mathematically inconsistent with what an automatic interpolator would do?  Is there actually any master involved here?  I assume you've eyeballed all this to your satisfaction, so is there any aesthetic compromises you would have to accept in "making the masters more consistent, and fewer"? 

Nick Shinn

The original masters were the Regular and Extra Bold. Then perhaps I made another master, based on the Bold, for interpolating with the Regular, to create the Medium. But I don’t really remember, as I use a lot of methods (e.g. “Expand Path”, “Make Bold”, cut and paste, etc., making it up as I go along).

I don’t think a variable font is a compromise, just working to a different set of criteria.

Chris Lozos

This is a common issue when approaching the bolder weights.  I don't know what the new technology does to accommodate this but I doubt if this can be done properly without human intervention [an additional master as Nick demonstrates, or much tuning of instances].  To me, the old Adobe Multiple Master fonts never got it right.  They did OK in the middle weights but the heaviest weights on the fly were unusable to me then as now. It was a case where the technology promised more than it delivered. If you look at the original Gill Sans, you can see obvious changes in approach to the different weights, not that I thought Gill did such a great job of it but he certainly was not afraid to make adjustments to his thinking.

Mark Simonson

The multiple masters set up in FontLab is pretty limited. If you are trying to get your head around what's possible in variable fonts, it's not going to be much help.

As I understand it, it's more like the kinds of things that are possible in Superpolator and Glyphs, where you can insert masters anywhere in the design space, even for a single glyph, or substitute certain glyph masters at a certain weight value when you want the design to change (à la Gill Sans).

Ray Larabie

I've only been using masters (2 per axis) for about 3 years. I find that it's limited my designs. It certainly speeds up the process but it's constraining. Before I used masters, I used FontLab's blend tool. After some blend tests, I'd start with the heaviest weight. All the typical compensations required for heavier weights were made with disregard for how the medium would be affected. I could make the e crossbar are thin as I wanted to. I could give the heavy bowls a squarish, superelliptical shape. The blend tool doesn't require the same number of points for interpolation so I threw caution to the wind. Structural differences were barely a consideration.

If you've never used the FontLab blend tool: the interpolations are a crap-shoot and require lots of cleanup. When the I generated the medium weight, I had a chance to deal with my overzealous weight tricks and structural changes. The interpolation was just a guideline. As I was subdividing the rest of the weights, the structural change could be further dealt with.

With masters, I can make adjustments to the middle weight but I'm always compromising the ultra-light and heavy to get the best results. The biggest constraint is the design of the heaviest weight's counters. In the past, I'd often use a modular, simplified counter in the heaviest weight...something that looks cool in an ultra-black but not necessarily desirable in lighter weights.

With masters, to get the proportions I want for the medium, I have to adjust the ultra-light or use a less extreme heavy weight. The practical solution is to make the heaviest weight less heavy. Masters are useful but facilitate boring designs.

Getting the same effect with OTvar is possible and perhaps even easy if the software can take away the burden of dealing with having an alternate set of masters for structural changes. If I'm working on a b with a structure like Nick's, I should be able to adjust the middle weight, make the structural changes I want, wherever I want them. When the font is exported, all the required alternates and substitution code will be automatically generated.

Having deltas along the axis will certainly help but I hope type design applications can deal with structural changes in a way that's not a burden for the designer.

Georg Seifert

If you only ever used Fontlab to do interpolation, you should stop worry about variation fonts. As Mark said, there are so many more options. You can get very close to the instances of the Figgins 'b' with one intermediate master. 
And if you need stronger changes, you switch the whole glyph at a certain point. So you have one Helvetica 'a' with a strait leg and one with a extended. 

But most important: nobody is forcing you to do variation fonts. If your fonts have manually drawn instances, just stick with them. 

Rob McKaughan

Belleve Invis said:

@Rob McKaughan
And the last question is: If I install both a non-variable font and a variable one, what is their application priority? I have a series of non-variable fonts with size-dependent gridfits (to merge strokes under certain physical size), and an unhinted variable one, and I want browsers to use the hinted ones for major styles, while unhinted under other styles.

I'm not sure if there is a deterministic, cross-platform result for this situation.

For stroke reduction, you could use feature variations (which employs a GSUB to switch glyphs at different points of an axis. Essentially, you create a font with an optical size axis. At small sizes, you have a simplified glyph. At large sizes, it switches to the more complex glyph. Depending on the design, the large-size glyph could use the small-size glyph as a component, then add strokes.

I'm really curious if designers of CJK fonts can use this as an alternative method to stroke reduction, than using TT instructions to hide strokes behind others.

Belleve Invis

@Rob McKaughan
Stroke reduction is similar to, but not exactly same as optical sizes. It is linked to pixel sizes, and currently is achieved using TT instrs, manully adjusted or calculated using AI (like my program, https://github.com/caryll/ideohint ) . Given that some characters may be extremely complex (like 釁), you may need many masters to achieve this, and a typical CJK font may have over 10,000 glyphs. That's terrible.

“Optical sizes of ideographs” may be more like this:

The one in the left is a normal “魔”，and the other one is for the small sizes, and you can notice that some strokes are weaken.

My proposal is that, you can install both a non-variable, hinted font, and a variable one. The non-variable one contains heavy size-dependent gridfits, for most screen display usages, especially in legacy applications and low-resolution monitors which require aligning all outlines to pixel grid, and the variable one is used for other scenarios.