[OTVar] Introducing OpenType variable fonts

124678

Comments

  • Nick ShinnNick Shinn Posts: 1,420
    Two reasons that Multiple Masters didn’t catch on:
    1. Output issues at service bureaux.
    2. No foundries producing fonts in the format. I tried, but there were technical problems I couldn’t surmount—mind you, that was before the interweb, so help was hard to get.

  • Two thoughts:

    • In the future, the most sold variable fonts may be “restricted variable fonts”.
    • In the future, there may be tools to convert a “restricted variable font” into an “unrestricted variable font”.
  • Ray LarabieRay Larabie Posts: 890
    edited September 2016
    This format was developed out of self-interest.
    You could say that about a lot of things.  But we always find ways to exploit new toys and make them work in our own interest.

    This won't revolutionize the way designers create static graphics. It doesn't give those designers anything they couldn't get from a superfamily. If you're thinking this won't have an affect on that particular buyer/seller relationship, you're probably right.

    I think this is mainly about having scalable fonts in scalable systems rather than saving bandwidth. If I want an ad that looks good on a billboard, smartwatch and everything in between, in portrait, square and landscape, I want it to scale. But we can't use a superfamily for that. So now we have this new thing. Your average web site doesn't need it. But a certain segment of the market is going to want scalable fonts.
  • This format was developed out of self-interest.
    You could say that about a lot of things.  But we always find ways to exploit new toys and make them work in our own interest.
    To be clear, I meant what I wrote as a literal response to Richard’s question, not as a value judgement. I don’t mean to dismiss the entire variation font format or its developers. Only to point out that, at this time, “There isn’t much of a sales pitch…”, and that for most users this will remain the case for at least several years.
  • How much slower will this make text rendering engines to support this? It sounds like a not insignificant additional amount of processing to produce what would have previously been a more straightforward translation. Anyone producing benchmarks?
  • TimAhrensTimAhrens Posts: 25
    edited September 2016
    Thanks for your detailed explanation, John.

    Trying to summarize:

    • We only have a meaningful reduction in data size (compared to single-style fonts) if there are more styles used than the number of masters. In practice, this means at least three different non-italic weights (e.g. Regular, Semibold, Bold) used on the page. As far as I have seen, this is rare on the web.

    • If the number of masters is equal to the styles used on a web page then we might have a slight reduction in raw data, plus a reduction of server requests. Arguably, this could equally be achieved by a generic compression format.

    • If the number of masters is greater than the styles used then variable fonts serve more data than single-style fonts.

    • With variable fonts, italics still have to be loaded using a separate server request. Also, shared data is transferred twice.

    Starting to wonder whether a much more primitive multi-file-compressed-container format could have solved the size and server requests issue more efficiently and more flexibly (as in: users build the multi-font resource from standard fonts themselves according to their needs, possibly automated by their website building tools).
  • One of the reasons why we only see two weights per website is because a third would add to much load.
  • So using two single fonts versus one variation font the later does give a similar download and technical complexity – but gives a lot more options. 
  • TimAhrensTimAhrens Posts: 25
    edited September 2016
    One of the reasons why we only see two weights per website is because a third would add to much load.

    Sure, it may be one of the reasons. But is it the main reason, most of the time? This would be interesting to investigate

    So using two single fonts versus one variation font the later does give a similar download and technical complexity – but gives a lot more options. 

    File size reduction is one goal of variations fonts, “more options”, i.e. stepless interpolation is the other one. At least as I understood (I am surprised the OT spec does not formulate the goals it wants to achieve).
     
    I was strictly referring to the fil size goal here. Le’s not mix things here – the goals should be discussed independently, maybe they should even even be solved by different means, and Tinbergen would say.

  • [...] most web sites don’t get enough traffic for reducing font data usage to have widespread appeal.
    These sound like the words of someone who doesn't have to deal with SEO-obsessed customers raving about Google PageSpeed rankings on a daily basis. Whether smaller fonts files are overrated in the big picture or not, they'll always be preferable over larger fonts.
    If the number of masters is equal to the styles used on a web page then we might have a slight reduction in raw data, plus a reduction of server requests. Arguably, this could equally be achieved by a generic compression format.
    We've got TrueType Collections technology on the shelf, which apparently is being implemented in WOFF2 and is likely easier to implement in browsers than variable fonts. This would combine variants in a single file, sharing certain tables. Not as efficient as variable fonts, but combined with HTTP/2 (reducing overhead of requesting multiple files over a network) and WOFF2 (very good compression) might be as, or more, efficient as variable fonts for small sets of weights/variants. I wrote about about that on Typographica.

    In the end I think variable type will be simpler and more efficient than stringing together a few separate solutions that sorta do the same, but I agree that overselling the compression benefits might backfire.
  • 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.
    well, universal means operating-system level solutions: variable fonts UI on android, macOS, iOS, (the linux desktops). and the web platform, via the css API (taken care of by the determined w3c organisation).

    individual application vendors (adobe, microsoft office group, google office group, quark) will not work towards the goal of getting this in the hands of everyone.

    only with well-designed variable fonts UI—meaning the right level of power and complexity for a whole spectrum of different users—rolled out universally, there is a platform to actually sell (or even, give away) variable fonts.
  • TimAhrens said:

    Starting to wonder whether a much more primitive multi-file-compressed-container format could have solved the size and server requests issue more efficiently and more flexibly (as in: users build the multi-font resource from standard fonts themselves according to their needs, possibly automated by their website building tools).
    I did a quick test with two styles, Light and Extra Bold.

    Raw TTF (unhinted): 286 kB (143 kB each)
    Packed into a TTC: 261 kB
    Compressed as WOFF2: 66 kB

    Same as TTF/GX (via Glyphs export): 191 kB
    Compressed as WOFF2: 62 kB

    So in theory, the TTF/GX contains the whole upright family, but to be true to the original design it would need at least a third master in the middle, and maybe some more exceptions.
  • thanks for that question Caren, and making me think about it.

    1) you point out yourself that the collaboration is ‘unprecedented.’ and it creates no president.

    2) quite a bit of this thread is devoted to what made the companies involved sign off on the time and budget of the ones involved in the standard—did anyone work as a ‘frog’ (unpaid) on this up to now?

    3) implementing the back-end for getting vari-fonts rendered looks go (to me); the same people from the big four involved in the standard will spec or write the implementation in their company, signed off by the same manager for the same rationale.

    4) vary-fonts will work on the web, via the css API. it seems in practice that an API is a lot easier to do than GUI (although an API is also a user interface). this will make the core use cases for the technology work.

    5) now for the universal UI. for the operating systems, this has to be made by very different teams at mostly the same companies (apple, microsoft, google). the managers of these other teams will look at their spreadsheets and say: ‘why would we spend a penny on supporting this? it works on the web, where it belongs.’

    it is the same as OpenType features: the mechanical, can-be-just-made-by-engineers, brings-in-the-money part works. then the GUI part needs to be done, which is a rocket-science design problem, not for the faint of heart. and then the GUI part becomes optional; best figured out first by someone else, somewhere else.

    6) for applications, it is one at the time (as long as they cannot—or do not want to, like adobe and office apps—get it for almost free from the operating system), each app with their own manager with a spreadsheet, even when they are part of the same company. see how OpenType features worked out at adobe: every app in a different state of neglect.

    conclusion: universal UI will happen when one of the operating system companies finds a good business reason to do this. then the other operating systems may follow (feature parity). most of the apps will pick it up then for free, or even unwittingly. the home-brew class of apps (where it comes to typography), adobe and offices, will follow their own, individual, trajectory.

  • 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.
    I was wondering about that. Good to hear. I think it is a valid criticism from variable fonts skeptics that type designers are also there to make certain choices that (some) users cannot or do not want to do; that they don't necessarily want/need an infinite amount of possibilities but a detemined amount of options.
    I think I would call this a 'restricted variable font'.
    I wouldn't. I think this assumes that the proper behavior for a variable font is to offer all the range of interpolation (all that is possible is available). It doesn't have to be. It is a pretty important thing, also for business reasons. We will have to see how things develop… but let's say a client of mine want the Regular and Bold styles of a font only in a variable font because smaller size, less requests etc but doesn't want to pay for the Medium style. In such a case I would want to provide a variable font that switches from Regular directly to Bold. I don't think that is a restricted variable font, it is a variable font containing what the client wants and expects, and for a lesser price.
    Therefore I don't think
    Obviously such restriction would be likely to provoke support calls from customers used to variable fonts behaving differently.
    is necessarily true. It really depends what the purpose of the variable font we're speaking about is. I might not be confortable letting users decide what weight of Regular they should set the main text of their website in, while having no problem letting them decide how wide or condensed a headline sans-serif should be. It will be part of the marketing to explain the purpose and possibilities of a given variable font. At the same time, how webdesign and the webdesigners expectations evolves will determine how much freedom type designers will want to give with interpolation.
    Ben Blom said:

    Two thoughts:

    • In the future, the most sold variable fonts may be “restricted variable fonts”.
    Given what I described, I could definitely see that.
    In the future, there may be tools to convert a “restricted variable font” into an “unrestricted variable font”.

    Sure. But the piracy ship has sailed a long time ago. WOFFs can easily be converted back into OTFs. Our fonts are available on message boards and torrent platforms. At this point, worrying about that doesn't make much sense anymore.
  •        I think I would call this a ‘restricted variable font’.

    I wouldn’t. I think this assumes that the proper behavior for a variable font is to offer all the range of interpolation (all that is possible is available). It doesn’t have to be.

    Agreed. How about “discrete variable fonts” and “continuous variable fonts”?

  • TimAhrens said:
    I like the idea of reducing the file size. If we really take this issue seriously then some questions arise:

    1• 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.

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

    2a) 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?

    2b) 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.

    1. The details of exactly how many instances will be needed to make one or the other route more efficient will vary greatly, depending on how many masters are in the font, how many instances are used, and what compression scheme you are comparing against. We will need a fair number of production fonts and some experiments before I would be willing to make any strong generalizations.

    I will note, however, that additional masters can be substantially more compact than separate fonts. But how much so varies....

    2. It's hard to say what tool swill emerge and which will be used by users vs which will be used by foundries vs which will be used by hosting services. I do think the variable-fonts situation will encourage foundries and web font services to allow certain kinds of subsetting of axes/instances as is already being done for glyph complements today.
  •   OK. The fog slowly lifts...

    Variable Webfont Feature and Benefit #1: Client-side generation of font-weights on the fly, interpolated by the browser from a single file, instead of multiple files, each generated for a specific font-weight, means that a single browser request for a single file can generate what previously required up to nine separate files to travel over the network and required nine different browser requests.

    Do Variable Webfonts Sound quicker? More efficient?  You bet. 

    For example, to get the full range of weights for a font named greatfont.ttf
    Today, in the absence of Variable Webfonts, you would have to download the following files:

    greatfont-thin.ttf           (font-weight: 100  Thin || Hairline)
    greatfont-extralight.ttf  (font-weight: 200  Extra Light || Ultra Light)
    greatfont-light.ttf          (font-weight: 300 Light)
    greatfont-normal.ttf      (font-weight: 400 Normal)
    greatfont-medium.ttf     (font-weight: 500 Medium)
    greatfont-semibold.ttf   (font-weight: 600 Semi Bold || Demi Bold)
    greatfont-bold.ttf          (font-weight: 700 Bold)
    greatfont-extrabold.ttf  (font-weight: 800 Extra Bold || Ultra Bold)
    greatfont-heavy.ttf        (font-weight: 900 Black || Heavy)

    And so, there's part one of the sale pitch.

    It sounds great but I'm wondering if it's precisely true.

    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? 

    For example, here on TD, designers like James Montalbano and Chris Lozos have pointed out that for them, the interpolations generated by the existing technologies for generating font weights automatically - like multiple master - are very much subject to review.  They tweaking from there as a starting point. Ultimately, it's the eye that rules. 
     
    So, my question is, will the interpolations done in the browser match up exactly to the interpolations done by a type designer and posted individually on the back-end?

    And if that's not what happens by default, CAN it match up exactly? - are there mechanisms for tweaking the results at different weights or are you stuck with what gets produced automatically? 
  • Just a reminder: variable font may be easier for pirating, given that the font file contains all design-time data for generating styles.
  • Side note: I really don’t hope to see Adobe cramming sliders into their already-crammed OpenType feature panel.
  • The sliders where there until some years ago. And it was not cramped, just one small section with a few sliders. 
  • Just a reminder: variable font may be easier for pirating, given that the font file contains all design-time data for generating styles.
    It will generally still be easier to just go download a zipped filed containing the entire type family. It’s not as if they’re hard to find.
  • On the subject of piracy and licensing and fallback fonts: as a developer you'd want to create a site with variable fonts, and then automating the CSS and fonts for older browsers. This would be similar to current build processes where fallbacks for older browsers are derived from modern technologies: adding CSS prefixes, resizing images, using bitmaps instead of SVG, etc.

    As an example, a build process would inspect the CSS and see that one typeface is being used in two weights and four widths, all contained in the single file `my-variable-font.woff2`. It would then generate fallback CSS for older browsers, splitting those two weights and four widths to six separate old fashioned fonts files, e.g. `my-favariable-font-thin.woff2`, `my-variable-font-bold.woff2`, etc.

    This would be a lot easier for developers, especially when you're playing with custom axis or variants that aren't offered as a regular old OTF/TTF font by the designer/foundry.

    I can imagine this'll open a huge can of licensing worms. What are your thoughts on this?
  • Erik van BlokandErik van Blokand Posts: 19
    edited September 2016
    @Roel Nieskens apart from the licensing issue, I would not trust a CSS centric tool to be precise enough to assemble a working instance font out of a variable font. I don't think foundries would look forward to handling support questions when such a tool fails either.
  • Perhaps instead of "cramming" sliders into the opentype panel, Adobe might redesign the UI of their products and do a better job of it--including making sensible access to stylistic sets.
  • I have a series of question about APIs, especially about win32:

    1. 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?
    2. Will GDI support displaying variable font? If so, predefined styles only or with interpolation?
    3. Will DW on Win32 support displaying variable font? If so, predefined styles only or with interpolation?
    4. Will DW on UWP support displaying variable font? If so, predefined styles only or with interpolation?
     @Mike Duggan

  • @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.
  • TimAhrens said:
    Starting to wonder whether a much more primitive multi-file-compressed-container format could have solved the size and server requests issue more efficiently and more flexibly (as in: users build the multi-font resource from standard fonts themselves according to their needs, possibly automated by their website building tools).

    It's worth mentioning that the arithmetic isn't as simple as counting the number of masters vs the number of static fonts that might be used. A "master" in a variable font is stored much more compactly than a static font. A static font would include a bunch of extra tables beyond the glyf table, plus there's the extra overhead of a separate set of TrueType hinting instructions. Finally, the outline data can be more efficiently stored in a variable font than in a second static font: the variable font only stores deltas (often with only 8 bits per delta), and need not store every point (e.g. in a lowercase o, only the four extrema points likely need deltas, not the other control points which will get piece-wise interpolated similar to the IUP instruction in TrueType).

    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.

    So, the only real way to see if there are savings for an fvar font vs N static fonts is to do the file comparison.
  • @Roel Nieskens apart from the licensing issue, I would not trust a CSS centric tool to be precise enough to assemble a working instance font out of a variable font. I don't think foundries would look forward to handling support questions when such a tool fails either.
    Why wouldn't you be able to generate a precisely matching instance font in a build process? You could simply calculate the outlines based on the values for all the axis, no?
  • @Erik van Blokand Rereading your comment, I want to clarify that this conversion would be done by a build process (in JavaScript, Ruby, Python) on the server/developer side, not something CSS related in the browser.
Sign In or Register to comment.