[OTVar] Introducing OpenType variable fonts
Comments
-
Richard Fink: what you’ve done is, how shall I put it? - mathematically inconsistent with what an automatic interpolator would do
For me, the design effort for a “weight-axis” family goes into creating three compatible master fonts (thinnest, “near middle”, heaviest)—not into creating or improving intermediate styles which result from interpolation from these masters. If I am fully satisfied with the design of the masters, I will be satisfied with any intermediate style—because the intermediates are a variation of the design in the masters.
I sometimes use a little trick to make two incompatible glyphs compatible, by adding extra (‘unnecessary’) nodes. This trick can be used to make the counter of the b’s from the Figgins example above, compatible—so interpolation between them will be possible. Examples of this trick are in the image below. (From left to right: the dot of the “i” from the Simplo Medium and Black masters; an enlargement of a part of the Simplo Black dot; the top of the “one” from the Aspira Thin and Medium masters.)
In my current workflow, after the interpolation has been completed, unnecessary nodes will be removed automatically by a clean-up script. In future variable fonts, the extra nodes will have to stay in the masters.
0 -
@Belleve Invis: What if you had a pixel-based size axis whose coordinates corresponded to the current pixels-per-em being rendered?
0 -
@Rob McKaughan
It is hard to control the rounding using OTV. For rounding, TT instr is more controllable.0 -
What would you do, in the future, if customers would start to ask for font families to be packaged in variable font files?
0 -
@Ben BlomWhat would you do, in the future, if customers would start to ask for font families to be packaged in variable font files?
The same thing I do now when customers ask me for things that I am not sure they really want or need: explain what they're asking for, and help them figure out if that's really what they need.
Variable fonts are a particular kind of OpenType font. They're not a wholly new format, and their functionality is of a particular kind. If you have a typeface that doesn't lend itself to that functionality, there's little point in packaging it as a variable font. That leaves the 'one file' aspect of the technology as something that customers might want, but that's also addressable using a .ttc (now also works for CFF fonts), which is a more appropriate package for a typeface that doesn't have variable functionality.
3 -
@John Hudson Two things are for sure. The future is unknown. The market will decide.
Variable fonts may become just a niche product, and most of the font market may continue using single font files for multi-style font families.
However, it is also possible that variable font families may become main stream, replacing most current multi-file font family packages by single file packages. Variable fonts families may become ‘the new thing’ that most customers would prefer.
Insofar as variable font families are discrete variable font families, the new format may be just an efficient packaging format. What is the problem with that? Will the market appreciate the new format less, when it is used in this way? (I have a car that can drive over 200 km/h, but the maximum speed is 130 km/h. I do not a have problem with that. Perhaps the designers of the car are disappointed that I do not use the car’s full potential.)
If, in the future, a lot of foundries offer discrete variable font families, and customers like them a lot—does it make sense to tell your customers that that’s not what they really need?
Do tcc’s have a track record as a packaging format for multi-style Western font families? If not, is there a reason why a market adoption for such families would happen in the coming years? Does a tcc-packaged multi-style font family have a smaller or bigger file size, than the same family as a discrete variable font family?
a more appropriate package for a typeface that doesn’t have variable functionalityWhy suggesting that a variable font family with an avar table with a stair-step function, doesn’t have variable functionality? Both discrete variability and continuous variability, are variability.
0 -
@Belleve Invis : Rob has provided some answers. I'll try to fill in the rest.Belleve Invis said:@Rob McKaughan
I have some questions about using blend in CFF2.- Can I "blend" a subroutine index?
- Can a blended result be an argument of another blend operator? If so, then CFF2's blend CAN support non-linear interpolations.
- 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?
- Can I display them using GDI? If so, can variation being supported?
- Can I display them using DirectWrite in win32? If so, can variation being supported?
- Can I display them using DirectWrite in UWP? If so, can variation being supported?
- Are there any API, or API proposals for extracting outlines under certain style?
Belleve Invis said:I have a series of question about APIs, especially about win32:- Can I install a variable font directly into my system, using the existing control panel? If so, how will the result being organized? Shown as a family or a single file?
- Will GDI support displaying variable font? If so, predefined styles only or with interpolation?
- Will DW on Win32 support displaying variable font? If so, predefined styles only or with interpolation?
- Will DW on UWP support displaying variable font? If so, predefined styles only or with interpolation?
You can install a variable font in the Windows 10 Anniversary Update (version "1607", hereafter W10AU) using the existing control panel, provided the font looks like a traditional Windows-supported font with additional tables. A reason for stating that qualification is that AAT fonts with an sfnt version "true" haven't been supported in Windows, and some existing GX variation fonts have that sfnt version. Now, if you have a variable font with TrueType outlines (not CFF2, which is not yet supported in W10AU) and an sfnt version of 0x00010000, the existing control panel will reflect only the default instance, but DirectWrite may support more than the default instance.
In W10AU, GDI will support only the default instance of that font. That will likely change in a future release.
In W10AU, DirectWrite can support more than the default instance, with some qualifications. First, the rasterizer is capable of handling any arbitrary interpolation involving arbitrary axes. However, there's a current limitation in what can be enumerated and selected via the existing APIs. The existing APIs assume a family model with only weight, width and slant axes, and the slant axis is assumed to have a fixed enumeration of values -- normal, oblique or italic -- rather than continuous variation. So, the existing APIs can really only accommodate variation (in the Font Variations sense) in weight or width axes.
There's a further limitation in that the APIs are not currently interacting with the axis ranges defined in the 'fvar' table, but rather are only dealing with the weight and width axes by inference using the names provided by the named instances defined in the 'fvar' table. The way this is working is that the font presents a set of sub-family names that are then processed using the WPF Font Selection algorithm to infer a set of available positions within a weight/width space. Those are the faces that will be enumerated and that can be selected via the existing APIs.
These are API limitations in the W10AU release. This will change in a future release, probably in 2017: there will be new APIs that will enable selection of arbitrary instances on arbitrary axes, using a super-family model in which a family is not limited to WWS axes. The existing APIs that use the WWS family model will support enumeration/selection of any named instances with non-weight/width axes projected into family distinctions by means of the 'STAT' table; e.g., if a "Selawik" variable font has a named instance "Light Semi-Serif", then that would be selectable in the existing APIs using a family name "Selawik Semi-Serif" and weight = Light.
Note that DirectWrite is agnostic about the Win32 versus UWP app models, so the above comments regarding W10AU and what will be in a future release are applicable to DW apps built for either app model.
0 -
@Peter Constable
How about the "mixed installation" situation? Especially for UI fonts with complex shapes (like: ideographs), we can provide a set of fully-hinted, non-variable series (the hints are calculated using an AI), and one variable file that covers all other styles.
The hints are extremely important for UI display, given that most users in Asia are still using low-resolution monitors, and almost all of their applications are written in Win32/C++, and have at least 10 years of history. I hope that GDI and DW can prefer the non-variable one above the variable one, on given styles, like “regular”.
0 -
@Ben BlomWhy suggesting that a variable font family with an avar table with a stair-step function, doesn’t have variable functionality?Because what you've described, in terms of packaging individual masters into an OT Font Variations font without access to intermediate positions in the variations design space, is functionally identical, in terms of typography, to using separate fonts. Yes, I understand that there is a sense in which one could talk in terms of discrete variability instead of continuous variability, but I don't think it is very useful to talk in this way with regard to functionality.
With regard to TTCs in the font market(s), I'm not sure whether we can say how they will behave. Until very recently, they were a) limited to TrueType and b) could not be either opened by or generated from common font production tools. So the number of font makers who have experience creating them, let alone trying to sell them, is fairly small. They're probably in about the same state, in terms of customer familiarity, as variable fonts: i.e. the vanguard of web typographers seems aware of them and what they might mean in terms of single resource downloads when integrated with WOFF2.0 -
@Belleve Invis,How about the "mixed installation" situation? Especially for UI fonts with complex shapes (like: ideographs), we can provide a set of fully-hinted, non-variable series (the hints are calculated using an AI), and one variable file that covers all other styles...
A "mixed installation" -- combining a variable font with non-variable instance fonts -- is certainly possible. It would be up to different applications or platforms to determine which would be used if the axis values corresponding to the non-variable font were selected; the OpenType spec doesn't specify which should be preferred (just as it doesn't say what to do if you happen to have two fonts with the same family/subfamily names). In DirectWrite, I think we will likely select the more specific, i.e., the non-variable instance.
Note, though, that there's no reason why the variable font can't be hinted. Indeed, the approach to hinting that Greg Hitchcock, Mike Duggan and gang are recommending these days fits well with variable fonts since it avoids deltas and uses a limited number of CVTs, and means that hinting of a family represented as a variable font requires a lot less time than hinting a number of non-variable instance fonts.
0 -
But, if you want to display complex characters, like ideographs, clearly, you HAVE TO add deltas. It is a completely different MONSTER.Peter Constable said:
@Belleve Invis,How about the "mixed installation" situation? Especially for UI fonts with complex shapes (like: ideographs), we can provide a set of fully-hinted, non-variable series (the hints are calculated using an AI), and one variable file that covers all other styles...
A "mixed installation" -- combining a variable font with non-variable instance fonts -- is certainly possible. It would be up to different applications or platforms to determine which would be used if the axis values corresponding to the non-variable font were selected; the OpenType spec doesn't specify which should be preferred (just as it doesn't say what to do if you happen to have two fonts with the same family/subfamily names). In DirectWrite, I think we will likely select the more specific, i.e., the non-variable instance.
Note, though, that there's no reason why the variable font can't be hinted. Indeed, the approach to hinting that Greg Hitchcock, Mike Duggan and gang are recommending these days fits well with variable fonts since it avoids deltas and uses a limited number of CVTs, and means that hinting of a family represented as a variable font requires a lot less time than hinting a number of non-variable instance fonts.
... not to speak of the lack of y-axis AA in GDI.
When hinting letters, you have enough pixels, so the task is simply align points to key lines, and preserve stem widths. But ideographs are completely different. YOU DO NOT HAVE ENOUGH PIXELS. Just imagine: you have to fit 11 horizontal strokes in 12 pixels, and still preserving that character legible. Therefore, delta instructions are necessary, it will place some strokes to the same position, so you can read the general shape of that character.
(so, another question: is GDI too complex and old to maintain? I've heard that it is completely written in assembly, and have many JIT compilers in it.)1 -
Why suggesting that a variable font family with an avar table with a stair-step function, doesn’t have variable functionality?
Because what you’ve described, in terms of packaging individual masters into an OT Font Variations font without access to intermediate positions in the variations design space, is functionally identical, in terms of typography, to using separate fonts. Yes, I understand that there is a sense in which one could talk in terms of discrete variability instead of continuous variability, but I don’t think it is very useful to talk in this way with regard to functionality.@John Hudson An escalator that doesn’t move, is functionally identical to a staircase. According to your logic—the moment an escalator stops moving, we should call it a staircase (or we shouldn’t call it an escalator anymore).
This seems to be a case where the choice of terminology, functions as an expression of an opinion. Suggesting that a variable font family that fully complies with the specification of variable fonts, doesn’t have variable functionality—may be a recipe for confusion: “Here we have a variable font family, but it doesn’t have variable functionality”. (It would make more sense to describe the kind of variable functionality it has.)
0 -
Agreed that CJK hinting is completely different, in particular due to the need to do stroke reduction because there aren't enough pixels.Belleve Invis said
But, if you want to display complex characters, like ideographs, clearly, you HAVE TO add deltas. It is a completely different MONSTER.
... not to speak of the lack of y-axis AA in GDI.
When hinting letters, you have enough pixels, so the task is simply align points to key lines, and preserve stem widths. But ideographs are completely different. YOU DO NOT HAVE ENOUGH PIXELS. Just imagine: you have to fit 11 horizontal strokes in 12 pixels, and still preserving that character legible. Therefore, delta instructions are necessary, it will place some strokes to the same position, so you can read the general shape of that character.
(so, another question: is GDI too complex and old to maintain? I've heard that it is completely written in assembly, and have many JIT compilers in it.)
You can use deltas in a variable font; we just don't recommend it due to the complexity. The trouble with deltas is that they apply to all instances. But: you can wrap those deltas in a conditional using the GETVARIATION instruction so that they apply to only specific ranges in the designs pace. So, technically its possible to use delta hints to do stroke reduction in a variable font, although it requires more care in hinting, and requires the use of low level instructions (which we assumd most people don't do; choosing instead higher level constructs like VTTTalk, or the graphic hints in FontLab and Glyphs). That complexity is why we recommended against it.
However, it would be really interesting if someone took on the challenge to implement stroke reduction this way. Perhaps it's more straightforward than we had expected (e.g. wrapping the conditional logic in a common routine in the fpgm; maybe using CVTs in a clever way, etc). I'd be very curious about your thoughts on this as you've done a lot of work on hinting ideographs.
1 -
@Rob McKaughan
All “high-level” instructions produced by ideohint are in four types:- Place a point to a specific position (in pixels) in Y direction under certain size (in ppem);
- Align a point to a specific distance (in pixels) to another touched point, in Y direction, under certain size (in ppem).
- IP
- MDRP
ps. I am curious about how to represent them in VTTTalk.0 -
@Ben BlomAn escalator that doesn’t move, is functionally identical to a staircase. According to your logic—the moment an escalator stops moving, we should call it a staircase (or we shouldn’t call it an escalator anymore).No, we'd call it a broken escalator. I don't think either of us want to push that metaphor any further. I don't think a variable font that restricts access to the variations design space is a broken font: I just think it is one that has a different functionality from what customers are likely to associate with the term 'variable font'.
I did not, in any case, suggest that a variable font that restricted access to the variation design space should be called a non-variable font. I suggested that it should be called a restricted variable font. That seems to me simply descriptive.
You are right that this is all potentially confusing, but I said to the working group — when we were discussing how to name the technology — that it would be necessary to be able to talk both about the font format and about the kinds of typography that are made possible by it. So far, that terminology has not emerged, and we only have a word for the fonts using the technology, not to describe the typographic functionality that comes with being able to access interpolated instances in the variations design space. That's what I'm talking about when I say 'variable functionality'. Please suggest another term if you can think of one.
[I encouraged the working group to let such terminology emerge naturally, rather than trying to label things up front. Until people start doing new kinds of typography with variable fonts, we won't know how they will think about and describe that work.]“Here we have a variable font family, but it doesn’t have variable functionality”.
That seems to me much less confusing, as a statement, that just saying 'Here is a variable font', and leaving it to the customer to figure out why it doesn't have the same functionality as other variable fonts.
You see, I hope, the need to be able to make a statement that distinguishes font format and functionality? So what words to use?
0 -
Any OpenType font with features is a variable font, in as much as it can vary the glyph that sets a character—especially one with Stylistic Sets that cover an entire character set.
Slider Font might be a better term, as presumably a slider will always be used to make the OTVar fonts do their stuff.1 -
If you want to sow that confusion, it’s your call. But one could just as easily say any font that has multiple glyphs is a variable font.Nick Shinn said:Any OpenType font with features is a variable font, in as much as it can vary the glyph that sets a character—especially one with Stylistic Sets that cover an entire character set.
I know I don’t want to go down that path.Slider Font might be a better term, as presumably a slider will always be used to make the OTVar fonts do their stuff.
Not on the web! Nor for optical size, nor for auto-adjusting width to fit the text box, nor....
1 -
@Nick ShinnAny OpenType font with features is a variable font, in as much as it can vary the glyph that sets a character—especially one with Stylistic Sets that cover an entire character set.
In the context of OpenType, the term 'variable font' has a specific technical meaning that is explicitly stated in the specification.1 -
I don’t think a variable font that restricts access to the variations design space is a broken font: I just think it is one that has a different functionality from what customers are likely to associate with the term ‘variable font’.
@John Hudson What customers, in the future, are likely to associate with the term ‘variable font’, is dependent on what information customers get before/during/after the introduction of the new format. If customers are being told that each and every variable font will offer complete access to the full variations design space (will offer continuous variation), then that’s what customers will expect. If customers are being told that there are two kinds of variable fonts, one which offers continuous variation, and one which offers discrete variation, that that’s what customers will expect. There is a choice here, about how to introduce the new format to customers.
we only have a word for the fonts using the technology, not to describe the typographic functionality that comes with being able to access interpolated instances in the variations design space. That’s what I’m talking about when I say ‘variable functionality’. Please suggest another term if you can think of one.I’m not sure if it is smart to use the same term “variable” in two “unrelated” meanings: one for the font technology itself, and one for what can be done with it. In that situation, we would distinguish between two types of variable fonts: (1) variable fonts with variable functionality, and (2) variable fonts without variable functionality. This would be pretty confusing for me. When a font is called “variable”—I would expect that this characteristic of being “variable”, is reflected in some way in its functionality.
I’m afraid that the description “being able to access interpolated instances in the variations design space” is too vague in the current context. Does it mean access to all possible interpolated instances (continuous variation), or access to “a selection” of all possible interpolated instances (discrete variation)?
The term “restricted variable font” is indeed descriptive, although it makes one guess in what way the font is restricted. I agree with ybaggar, that this term is not a neutral description, because it suggests the font is incomplete or something like that—while it is not. It just isn’t a good marketing proposition, to offer “restricted variable fonts”.
I earlier suggested to distinguish between (1) “continuous variable fonts” and (2) “discrete variable fonts”. These are neutral and descriptive terms (descriptive, as long as an axis is not partly continuous and partly discrete, and as long as all axes are either continuous or discrete). I’m not sure whether the terms “continuous” and “discrete” are descriptions of functionality—but they do suggest “more” and “less” functionality (or “complete” and “limited” functionality).
0 -
Ben:
If you want to build and promote a variety of variable fonts under whatever branding name you like, feel free, but I see nothing resembling a compelling case for complicating the name of "regular" variable fonts to distinguish them from your "special" static-fonts-in-variable-font-packaging.
Part of the thing is, I just do not expect that going to extra trouble to make your fonts less functional, and explaining how you have deliberately crippled them, is going to be a popular value proposition. Sure, there are times and places where it will be needed or helpful, but they won't be the norm. Just use stand-alone fonts in those cases; it will be simpler.3 -
Thomas, we just disagree. We both cannot look into the future, so it’s not clear which share of the future variable fonts market will be continuous, and which share will be discrete. It is clear that you dislike the idea of discrete variable fonts, by calling them “deliberately crippled”, and suggesting that foundries should explain to their customers how they crippled their fonts. (What an excellent marketing strategy. In this way, they surely will sell a lot of them!)
Ray Larabie suggests, that it would be a good thing, if the font family with many stand-alone fonts, would be finished: “If OTvar kills the superfamily, it can’t happen soon enough for me”.
Why continue to create large multi-file font families, if the same functionality can be created much easier, and if the customers’ software supports variable fonts? There really is no “extra trouble” to create discrete variable font families, when compared to what have to be done to create font families consisting of many stand-alone fonts.
In the future, I expect that all font families I make, will be variable font families. I expect to make two versions. First I will crate a continuous variable font family. Then I will change or add some entries in the avar table of this continuous variable font family—and then, presto!, I have a discrete variable font family. (I hope there will be a tool available then, to do this change of the avar table in a few minutes. Then the “extra trouble” will take a few minutes.)
The real “extra trouble” might be to generate stand-alone fonts from a variable font family, but that’s another story.
Of course, there is a business case for a discrete variable font family as a mainstream format. It is easier, both for the seller and user of fonts, to have one file, instead of, say, ten files, to get the same functionality. In some situations, the smaller file size might be a reason to prefer the discrete variable font family over the stand-alone fonts. Some foundries might ask a lower price for a discrete variable font family, compared to the price of the stand-alone fonts variation of the same font family—because the variable font family is easier to make than the stand-alone fonts family. The price of the discrete variable font family, will surely be lower than the price of the continuous variable font family of the same typeface. If a customer wants to have the full continuous variable functionality, he has to pay a premium for that. Only the customers who need the full continuous functionality, will pay the premium price. For all other customers, a discrete variable font family will be a good deal. They don’t pay, for what they don’t need.
0 -
Actually, predicting the future is not always that difficult. I have a pretty good track record in this regard, and am happy to place my predictions in writing. Unless you plan to be a follower, you can't make business decisions, including investments of time and effort, without implicitly making such predictions.
This one seems pretty obvious to me, that vendors are not going to fall over themselves to do this thing—I don't see lots of people saying how exciting this idea of yours is to them, either as font vendors, or as end users.
I have some predictions, but I think I'll put them in a blog post (and link to this thread) instead of burying them in this thread.1 -
It’s okay to consider oneself to be a good guesser of the future—and then say there is no future for discrete variable fonts (without giving real reasons for that). However, it would be more helpful to discuss both the advantages and disadvantages of discrete variable fonts. I and others suggested that discrete variable fonts have advantages for the producers, vendors, customers, and users of font families—when compared to font families consisting of many stand-alone fonts. But what about the disadvantages?
The only disadvantage of discrete variable fonts I’ve seen discussed here, is, I would say, a “disadvantage-of-one’s-own-making”, and it goes like this. Customers and users of variable fonts will get confused, if the variable font does not offer the maximum possible continuous variation—because they expect each variable font to offer such continuous variation. (They expect that, because no one tells them that discrete variation is possible. No one should tell that, because the format was intended to be continuous.)
If I misrepresented this disadvantage, or if there are other disadvantages, I would be happy to hear about it.
0 -
Would you be in favor of limited scalable fonts as well? Why should users be able to set any imaginable size with a single font? In the old days, they had to buy discreet sizes. Another business model ruined by technology. No wonder it's so hard to make money in the type business.7
-
I sell a lot of single-font licences. Clearly, many users only need the single weight (or two), and relish exercising their financial acumen by not paying extra for what they don’t need, even if it’s a heck of a deal.
I predict this scenario will continue, because what is a variable font, businesswise, other than another way to package a typeface family?
The only way this could change is if variable fonts are sold for the same price as a single style, which I wouldn’t put past a very large, or very aggressive, marketer.
0 -
(Of course, if a variable font’s functionality is qualitatively different, e.g. “responsive”, that would change things.)0
-
Clearly, a variable font would have more value than a single-weight font, so the price ought to be higher. What the price should be relative to a multi-weight family is the question.
I have some families with as few as two or three weights, some with six or eight. The range from lightest to heaviest tends to be greater when there are more weights.
Perhaps price should be based somewhat on how much range is available. For instance, a variable font that went from ultra thin to ultra bold might cost more than one that went from light to bold. This is assuming that a very wide range of weights has some utility, which may not necessarily be the case. Ultra thin and ultra bold are much less useful than fonts in the light to bold range.
I've seen mentioned pricing based on the number of axes, which makes sense to me, and I think would make sense to buyers. But this still leaves open the question of how to price each axis.
My sense is that a reasonable price for a variable font would be roughly the same as three individual weights multiplied by the number of axes, or something like that. People who actually want lots of weights would be getting a better deal, but if it's too high, you're liable to shut out people who only need a few weights.
Alternatively, you could price it the same as a current full family with a range of weights, leaving customers who need only a few to purchase non-variable fonts in those weights. But it might be hard to get people to buy a "single" font for the price of eight.
Of course, whatever pricing you adopt might fail to work if some other pricing strategy becomes popular in the market.
Just my 2¢.2 -
Also, there is more need for very large weight spread families in print than in web use where screen resolution is not capable of rendering very subtle differences--at least not yet.0
-
There is a typographic reason to “prohibit” certain weight instances, namely those that create a visually annoying counterpane effect, in which stem widths are equal to the width between stems. However, rather than assume it’s our duty to protect typographers from themselves, it looks like they will have to assume that responsibility themselves.0
-
“Restricted variable fonts”This won’t pass through marketing. You can’t tell customers that the products they buy are restricted.1
Categories
- All Categories
- 43 Introductions
- 3.7K Typeface Design
- 798 Font Technology
- 1K Technique and Theory
- 617 Type Business
- 444 Type Design Critiques
- 541 Type Design Software
- 30 Punchcutting
- 136 Lettering and Calligraphy
- 83 Technique and Theory
- 53 Lettering Critiques
- 483 Typography
- 301 History of Typography
- 114 Education
- 68 Resources
- 498 Announcements
- 79 Events
- 105 Job Postings
- 148 Type Releases
- 165 Miscellaneous News
- 269 About TypeDrawers
- 53 TypeDrawers Announcements
- 116 Suggestions and Bug Reports