[OTVar] Introducing OpenType variable fonts

135678

Comments

  • Ray Larabie
    Ray Larabie Posts: 1,431
    Even italics with fundamentally different letter forms have a lot of symbols which are essentially oblique. Punctuation, math symbols. Could italics could be an axis with a mix of alternate forms and deltas?
  • Peiran Tan
    Peiran Tan Posts: 22
    John Hudson said:
    @Thomas Phinney wrote

    Yes, you can use CSS font-feature settings. It already works with variable fonts in Chrome and Edge browsers on the latest Windows 10, in fact. I think you can see it in the demo video.

    Unless I missed something very significant, what this means is that these browsers have been updated to support named instances in variable fonts, i.e. CSS font-feature properties can be used to reference named instances in variable fonts in the same way that they can be used to reference stand-alone fonts. This is a big step in terms of already being able to take advantage of the file size benefits and single-resource aspects of variable fonts, but doesn't yet mean that arbitrary instances or responsive typography are possible with CSS. We're just beginning the process of engagement with the W3C CSS working group.
    _____

    I suspect that for font makers and typographers, it is the arbitrary instance and dynamic variation aspects of variable fonts that strike a chord, more than the packaging benefits, so I think it is important to be very clear what we mean when we talk about things being 'supported' or 'working'. Those of us in the working group knew all along that support for named instances was going to come first, but this might not be obvious to people who are excited by the prospect of responsive typography.
    Yes, the arbitrary instance and dynamic variation is heaven, especially for web. But no, packaging benefits are also huge. Imagine only requesting one file for a webpage using more than two weights (better, imagine this webpage is CJK). Imagine loading one file with a slant axis to do both upright and italic on the same webpage (assuming it’s a neo-grot with oblique).

    And then pack this with dynamic subset... ohmygawd
  • Peiran Tan
    Peiran Tan Posts: 22
    Another question (perhaps a bit technical):

    Original MM starts with pairs of extremes to interpolate intermediate instances, while TrueType GX starts with the median default. Tom Rickner spoke at Typo Berlin about the differences—this decision was hint-based. But I didn’t quit really understand. How does TT GX’s delta value allow extrapolation instead of interpolation? (I’m guessing OTVar inherits this by large)
  • Read Roberts
    Read Roberts Posts: 7
    @Belle Invis: Our intention is that TrueType and CFF2 formats have the same functionality. A single glyph can only reference one glyphVariationData, therefore the vsindex must apply to the whole glyph and must appear at the beginning of the charstring. We will update the spec to state this.
  • Belleve Invis
    Belleve Invis Posts: 269
    @Read Roberts

    Thank you.
  • John Hudson
    John Hudson Posts: 3,186
    @Peiran Tan

    Original MM starts with pairs of extremes to interpolate intermediate instances, while TrueType GX starts with the median default. Tom Rickner spoke at Typo Berlin about the differences—this decision was hint-based. But I didn’t quit really understand. How does TT GX’s delta value allow extrapolation instead of interpolation? (I’m guessing OTVar inherits this by large)

    There is no extrapolation in GX or OTVar; that is, the design space is constrained by the axes, and no value is ever extrapolated beyond the extremes of an axis or the corners of the design space that are defined by those extremes. So from a type designer's perspective, the model is quite like multiple master, because the extremes of the axes have to be provided (the corners can be interpolated, or can also be provided). These extremes are expressed in the font as delta sets from the normalised median outline set (with intermediate delta sets as desired by the font maker, for one or more glyphs at any position in the design space).

    the median default

    Note that although the outline set occupies the normalised median point of each axis (0, relative to the extremes -1 and 1), the outline set does not need to be the median design along any of the axes. That is to say, the outline set for a font with a weight axis between UltraLight and UltraBlack does not need to be exactly in the middle between these two extremes. The outline set can be located anywhere along the axis, and could even be the UltraLight or UltraBlack design itself (in which case one would have an axis in one direction only, since there is no extrapolation).



  • Rob McKaughan
    Rob McKaughan Posts: 39
    As John points out to @Peiran Tan's question, the default instance need not be between two extremes. E.g. if your Regular can be accurately interpolated between Ultra Light and Ultra Black, then setting your default instance to the Ultra Light and only using one side of the axis may lead to more efficient data storage as you only need one set of deltas (for the Ultra Black) as opposed to two (e.g. if you had Regular as default, you'd need deltas for Ultra Light and Ultra Black).

    This brings up an important consideration for file size optimization (to @Roel Nieskens's question): in some typefaces, it may be possible to dramatically reduce the variable font's file size by eliminating redundant deltas like the Regular in the above example. Plus, the gvar table provides a ton of interesting ways of saving file size. All of this could add up to much more space efficiency than the WOFF2 compressor could do. I suspect that, as an industry, several folks will come up with interesting ways of optimizing the size of variable fonts. Someday, there will likely be font file optimizers that you run before doing WOFF encapsulation / compression.

    Of course, that means that the design space as expressed in the variable font file may be very different than the one the type designer drew.
  • John Hudson
    John Hudson Posts: 3,186
    E.g. if your Regular can be accurately interpolated between Ultra Light and Ultra Black, then setting your default instance to the Ultra Light and only using one side of the axis may lead to more efficient data storage as you only need one set of deltas (for the Ultra Black) as opposed to two (e.g. if you had Regular as default, you'd need deltas for Ultra Light and Ultra Black).
    With the caveat, of course, that the fallback display in an environment that does not support variable fonts will be the Ultra Light outlines (at least, for TTF; there is no fallback for CFF2 fonts in such a situation).
  • Denis Moyogo Jacquerye
    Denis Moyogo Jacquerye Posts: 191
    edited September 2016
    One of my colleagues was wondering what happens with the PANOSE in OS/2.
  • Dave Crossland
    Dave Crossland Posts: 1,429
    edited September 2016
    http://practicaltypography.com/the-scorpion-express.html
  • John Hudson
    John Hudson Posts: 3,186
    @Denis Moyogo Jacquerye

    One of my colleagues was wondering what happens with the PANOSE in OS/2.

    Excellent question. I recall discussion of PANOSE during the working group meetings, but there's no change to the spec regarding them. I think this is an oversight, and I'll make sure it is on the list of things for attention. As I recall, the general feeling about PANOSE is that it is already so unreliable — not to mention Latin-centric — that it might as well be ignored. But there should be some statement as to how PANOSE should be set or not for variable fonts.

    Personally, I'd be happy to see the PANOSE portion of the OS/2 table deprecated.
  • TimAhrens
    TimAhrens Posts: 57
    edited September 2016
    I like the idea of reducing the file size. If we really take this issue seriously then some questions arise:

    • From which number of used instances are variable fonts more size-efficient than single style fonts? Could a two-master variable font be smaller than the equivalent two single style fonts? Naturally, we need to compare compressed data; comparing raw data is meaningless. I’d be curious whether a good compression algorithm could pack two individual fonts into one file with the same size as a (compressed) two-master variable font.

    • What about cases when the user does not make use of all the possibilities (masters) that the font offers?

    Say, a variations font has a weight and width axis but someone uses only the regular width. Will there be tools (and will foundries allow) to “subset” variations fonts by removing unused masters/axes, similar to removing unused glyphs? Or, will foundries provide optional weight-axis-only variable fonts for these cases?

    Or, if a user only needs a single (interpolated) instance, would the foundry allow to generate a single-master font from it so as to reduce the data size?

    To me, it appears that a lack of understanding by the font user, or a lack of tools or the appropriate EULAs, could eventually lead to more data being transferred than with the single-style system.
  • Andreas (Eigi) Eigendorf
    Andreas (Eigi) Eigendorf Posts: 4
    edited September 2016
    John Hudson said:
    @Denis Moyogo Jacquerye

    One of my colleagues was wondering what happens with the PANOSE in OS/2.

    Excellent question. I recall discussion of PANOSE during the working group meetings, but there's no change to the spec regarding them. I think this is an oversight, and I'll make sure it is on the list of things for attention. As I recall, the general feeling about PANOSE is that it is already so unreliable — not to mention Latin-centric — that it might as well be ignored. But there should be some statement as to how PANOSE should be set or not for variable fonts.

    Personally, I'd be happy to see the PANOSE portion of the OS/2 table deprecated.
    The PANOSE spec is ready for variable fonts: 
    1.5 Digit values of 0 and 1
    The reader will notice that the value 0 and 1 are defined as Any and No Fit for every digit in the PANOSE system. These have specific meanings to the mapper. 0 means match that digit with any available digit. This allows the mapper to handle distortable typefaces such as multiple master fonts in which, for example, weights may be variable ...

    The problem is the implementation in fonts and tools. Most tools use 0 for undefined values. Maybe we need a new fsSelection flag in the OS/2 table which says "0 in PANOSE is a meaningful value" 


  • Dave Crossland
    Dave Crossland Posts: 1,429
    https://www.wired.com/2016/09/apple-google-adobe-microsoft-join-forces-make-typographic-history/
  • John Hudson
    John Hudson Posts: 3,186
    Andreas:

    The problem is the implementation in fonts and tools. Most tools use 0 for undefined values. Maybe we need a new fsSelection flag in the OS/2 table which says "0 in PANOSE is a meaningful value" 

    I suggested something similar to the working group — an fsSelection bit to indicate 'PANOSE is not junk' — but mostly as a joke. Such a flag, more general that what you suggest, could then be paired with a spec recommendation that the PANOSE value for variable fonts be set in some specific way. But I still don't think there's enough value in PANOSE to merit such a solution. The PANOSE data in the vast majority of fonts is junk, and that which is used by software — e.g. the monospace setting — is available from fonts in other data. Also, if font matching is really desirable, then the new STAT table could be extended to provide actual variable matching for the most important attributes (style, weight, width, proportion), à la Adobe's MM solution for embedding fallback in PDF.
  • John Hudson
    John Hudson Posts: 3,186
    @TimAhrens

    Excellent questions.

    With regard to subsets of variation axes, or custom instances as standalone fonts, these are very much EULA and business model issues. In my Medium article, I pointed out the potential for custom 'slices' of variation design space and tailored named instances. These are services that a foundry can offer, as are custom instance fonts, and I think a customer that cares enough about data size, or compatibility with older software for arbitrary instances, should be able to pay for that service. My take on this will probably be: a) if the customer wants individual non-variable fonts that correspond to the standard named instances in a variable font, there will be no additional charge (i.e. these are just two different packaging formats for the standard instances, one of which also has variable typography potential); b) if the customer wants non-standard named instance built into a variable font, or individual non-variable fonts of the same, then there will be a fee, because this is a customisation job; c) if the customer wants a variable font that behaves in a different way than the standard one, there will be a fee, because this is a customisation job. Another option would be to try to anticipate some of the customer requirements, and offer variable fonts with different axes sets as products, so e.g. a customer who never wants to use width variations can license the font with just weight axis, without needing to pay for customisation. Another, more radical option, is to stop selling font licenses, and instead sell a typeface service that includes access to the standard fonts in assorted formats, and options for various kinds of customisation. In any case, making the customer aware of how the fonts work and how they can be adjusted to meet the customer's needs is the important thing, and arguably the last option does this better because it is explicit in what the customer is buying.

    As to whether foundries would or should allow customers to modify variable fonts or produce their own derivative custom instance fonts, that doesn't seem very different from the sort of modification or format conversion that EULAs already have to either allow or prohibit. I suspect there will be as little consistency in foundry preference in future as there is already.
  • peter sikking
    peter sikking Posts: 24

    hey y’all, first post here.

    I guess quite a few people around here know me for my designs of font tools (or the attempt to get an interaction design project for OpenType features off the ground). For those not familiar with me, you can check me and my work out in this talk I did (with Lasse Fister) this year at TYPO talks:

    http://typotalks.com/videos/metapolator-present-future/

    It is gratifying to read both here and on twitter that people are quite aware that the new variable fonts tech is hot, but might never catch on if the font-end-user UI is daunting and balkanised, instead of empowering and universal.

    Empowering and universal UI is where I have worked for the last 2 decades. From experience: a unified solution still means optimised variations for desktop, mobile and web platforms. On top of that the full spectrum from expert typographer to general fonts-don’t-matter users must be covered.

    Universal also means that ‘everyone’ needs to be able to use it, which means rolling out an infrastructure project. Having done a couple of these projects, I know that the no.1 success factor is that a single organisation is determined to push it through (i.e. to cover the costs and effort). Without that, nothing is going to happen (see OpenType features UI).

    I cannot see that single, determined organisation at the moment for variable fonts UI. With that, no chance exist to work on an empowering and universal solution, that then can be taken by the big players in desktop, mobile and web and be moulded in their own image.

    We will just have to wait (for years, some insiders tell me) for the situation to become unbearable for an organisation and for them to get determined.

  • Chris Lozos
    Chris Lozos Posts: 1,458
    Universal also means that ‘everyone’ needs to be able to use it
    Meaning software vendors like Apple, Adobe, Microsoft, and Quark need to help the user get to it with ease and use it without pain and suffering.
  • Caren Litherland
    Caren Litherland Posts: 4
    edited September 2016
    Peter Sikking wrote:
    the new variable fonts tech is hot, but might never catch on if the font-end-user UI is daunting and balkanised, instead of empowering and universal.
    Yes.

    Then Peter wrote (my emphasis):
    I know that the no.1 success factor is that a single organisation is determined to push it through (i.e. to cover the costs and effort). Without that, nothing is going to happen
    Why? One of the most significant aspects of this effort, it seems to me, is an unprecedented collaboration among corporations and independent designers. Why can’t the same sort of collaboration on front-end tools lead to “an empowering and universal solution”?

  • Nick Shinn
    Nick Shinn Posts: 2,207
    edited September 2016
    If, rather than providing a typeface family, e.g. RRIBI, as a collection of fonts, I publish it as a single variable font, but with the styles limited to RRIBI, this would be seamless, with no visible change required of UIs.

    I would be inclined to prohibit other, user-generated instances, as being “faux”.

    However, should I permit user generation of instances, that would occur via a new sub-menu.

    **

    Is that what will happen to UIs?
  • John Hudson
    John Hudson Posts: 3,186
    edited September 2016
    I would be inclined to prohibit other, user-generated instances, as being “faux”.

    Nick, yes, variable font named instances should appear in font UIs exactly as if they were independent fonts. But shipping a variable font to customers while disallowing (in the EULA) use of other instances within the design space, is likely to cause confusion and almost certainly to result in inadvertent EULA contravention. If users are working in a software environment that provides access to arbitrary instances in variable fonts, it will be difficult to get them not to treat different variable fonts from different foundries in the same way in their work. Indeed, most users are unlikely to be aware that they are not permitted to use the fonts in a way that the font format delivered and their software makes possible. It's one thing for a EULA to specify that a font cannot be redistributed, or embedded in particular kinds of products, or modified; it's another entirely to say that it can't be tracked out, or coloured red, or, indeed, have faux bold or italic applied. Prohibiting access to arbitrary instances in the design space of a variable font would be in the same category, I think: practically impossible to police or enforce.

    So I think a legal, EULA-based mechanism for such restriction is a non-starter. There is, however, a technical mechanism you could use. It is possible to build a variable font in such a way that all the design axes work in discrete steps between named instances, with no intermediary interpolated instances. The effect in a variations UI, i.e. one in which a user could typically access an interpolated, non-named instance, would be of toggling between the named instance. So a slider or dial interface would jump from one named instance to the next, rather than exposing the design space between them.

    I think I would call this a 'restricted variable font'. Obviously such restriction would be likely to provoke support calls from customers used to variable fonts behaving differently.
  • Richard Fink
    Richard Fink Posts: 165
    I have a list of urls for about thirteen different articles about variable fonts.
    After reading all of them plus everything on this thread, outside of explaining that multiple weights can be generated on the fly, so to speak, nothing else is clear.
    1) What are the features and corresponding benefits of Variable Fonts?
    2) What problems does the format solve?

    Unless these can be explained simply, in a way that any potential end-using customer can understand them, there's trouble brewing. 

    What's the sales pitch? Outside of interpolation (for only Latin fonts, that's all I've seen examples of so far), what's the fuss?
  • Chris Lozos
    Chris Lozos Posts: 1,458
    The big pitch is file size to speed up caching of fonts enough that there is minimal if any lag time.
  • James Puckett
    James Puckett Posts: 1,992
    What's the sales pitch? 

    There isn’t much of a sales pitch. This format was developed out of self-interest. Some big companies want to spend less money serving fonts. Some of their big customers want to spend less money serving fonts. So they found a way to do it. Selling it to everybody else isn’t a priority. Nor should it be. These fonts probably won’t be usable outside of browsers for years, and most web sites don’t get enough traffic for reducing font data usage to have widespread appeal.

    …what's the fuss?

    Conference attendee exuberance overflowing onto twitter. In two weeks variation fonts will disappear into the back of our minds. Only the powers that be will have much reason to think about them until they’re ready for mass consumption.

  • Chris Lozos
    Chris Lozos Posts: 1,458
    The buzz may briefly fade but it will return as soon as some people use it well enough to show its potential.  I am sure there will be some new developments out of it that have yet to surface but they will.

Categories