Are customers buying or using variable fonts?

Eris AlarEris Alar Posts: 403
edited December 2022 in Type Business
I was not sure if this belonged in type business or type technology.

As a graphic designer, primarily working in print, I almost never use variable fonts and find them intimidating often. Or, more precisely, I don't have the confidence they will work as reliably as standard fonts, especially if I am working in a team sharing project files. 

I'm aiming to work on a display face of my own design this year, and so was dreaming about how I would release this so-far-fictional design, and it got me thinking about variable fonts.

I was apologising to a type designer friend recently about my lack of use of variable fonts. They said most people are not using them, and it got me wondering if there was any public data that could shed light on the subject.

Do any resellers or foundries share this info? Have I missed a conversation about it elsewhere?  
«1

Comments

  • Google fonts has a bunch of variable fonts, and represents a large chunk of the market. It shows usage statistics, so might be a good place to start.
  • Type Network dedicated a lot of effort this year to talking about and promoting variables (and testing them, and shipping them), but I’ll only say they are not exactly burning up the charts yet — and we probably would have been surprised if sales really took off at this time. It’s an investment and it’s still early, and there’s still work to be done with application support and end user awareness. We think it’s important to be ready when someone decides they’re ready to license and use them.

    As available typefaces and usage grows, I think it will be interesting to see what kind of typefaces are popular, and for which media.
  • edited December 2022
    I am not averse to potentially using variable fonts, but the vast majority of software I use does not natively support variable fonts, or at least not in a way that works well. So far for me the advantage mostly manifests in using pre-baked variants generated from the variable base (which is a useful thing already, by the way).
    However, I do not really consider variable fonts (at this stage) to be essential, and the projects I'm working on are not variable... though maybe one day I would work on doing variable versions, who knows? I'll admit that I am totally non-expert in that but it seems to make everything more complex than the task of drawing béziers...
    By the way — and this totally is just what I would find useful personally — I would love to see some more classic serif text fonts supporting optical sizing (which is the main variable feature I like to see and which I find most useful).
  • edited December 2022
    I think it still makes sense, actually! For instance in a LaTeX package that invokes a font that has optical sizes, the sizes would be loaded according to the font sizes used in the document... just like is done for Computer Modern (which is itself, you could say, one of the earliest variable fonts, although certainly unconventional in many ways compared to how modern fonts work).
    Of course, while METAFONT CM is fully variable, the Type 1 conversions of the CM family presume that only certain fixed optical sizes will ever be used … making CM more like the physical type that preceded it, in fact. And, to be honest, a robust set of optical sizes in fixed form are probably about all I would need as a user, though VFs can be very useful for generating these sizes from the single source (though this makes making the source more complex).
    The biggest issue for me is that I think designing variable fonts leads to many of the same issues we saw with MM fonts, which is why I suspect we will never see them come out as abundantly.
    Of course, there is very significant ground to cover for Variable/MM fonts in general, though. Even if you just look at revivals, consider how many designs originally made for pre-digital typography come in different optical sizes, of which only one was digitized. On the other hand, it seems the most common variable I see in new fonts, weight, is easier to make through interpolation between existing weights of the same optical size. But I'm not sure what the real application is for being able to set semi-boldness in such a granular way.
  • John HudsonJohn Hudson Posts: 2,553
    It depends who are your customers and in what market segment you operate. I have customers who are specifying that they want variable fonts and are willing to pay for me to do the work to make existing families into variable fonts, but that’s particular to OEM licenses for the tech market.
  • VF's are used more and more on Websites. The main benefit is that they optimize resources (Less KB to load, less request, etc). AFAIK they work reliably on the web.
    I have no information about how they perform in apps.
  • Ahhh, I hadn’t noticed they made that work for variables!
  • Thomas PhinneyThomas Phinney Posts: 2,408
    edited January 3
    Variable fonts are seeing strongly increasing use on the web:
    https://almanac.httparchive.org/en/2022/fonts#variable-fonts

    I occasionally run variable font stats on the entire Google Fonts library. The overall library has been growing steadily for many years, and is now at 1474 families. The past year and a half or two years, it was holding steady at about 18% of all Google Fonts families being variable fonts. But now it is at 19% (ok, 19.13% to be exact). This includes some of the most popular fonts available through Google Fonts, such as Open Sans, Montserrat, Oswald, the various Roboto families, Raleway, Inter, Nunito, Playfair, Rubik, Work Sans, etc.
  • PabloImpallariPabloImpallari Posts: 662
    edited January 3
    VF's are used more and more on Websites. The main benefit is that they optimize resources (Less KB to load, less request, etc). AFAIK they work reliably on the web.
    I have no information about how they perform in apps.
    I want to add something to my previous post:
    The fact that "I have no information about how the perform on apps" is actually a GOOD indicator that they work fine in apps too. Because when thing don't work as expected we usually get complains very quickly (fox example when style linking fails in MS word, or things like that). So far no one ever complained to me about VF's on apps, so its pretty safe to assume they work pretty well everywhere. However: when developing you VF's: follow the Spec and test as much as you can before releasing, so you are in the safe side. And if something fails on a certain specific app, you can blame the app developers :)
  • We haven't received a request for a variable version of anything yet.
  • Dave CrosslandDave Crossland Posts: 1,242
    edited January 23
    I've never really understood the conniptions by people who don't perceive the value of variable fonts; they will continue to use static fonts. Support for static fonts isn't going away. 

    (Not aiming this at anyone in particular :) )
  • JoyceKettererJoyceKetterer Posts: 730
    edited January 23
    @Dave Crossland Speaking only for myself, I absolutely think they are valuable but I don't want my company to be a technology early adopter.  It's just business strategy.  I think it can be hard to differentiate that from not caring when one is mostly surrounded by a bunch of enthusiastic nerds who love new things?  Isn't it s reasonable business decision to wait and they those people iron out the kinks?
  • Evie S.Evie S. Posts: 69
    I think early adopter is an exaggeration. It's been a feature in Adobe software for 3 years and counting, plus support in every widely used web browser. Variable fonts won't work for every customer, but having them is a huge plus especially for display type, like OH no's Obviously.
  • Dave CrosslandDave Crossland Posts: 1,242
    Not caring = no conniptions :)
  • Ray LarabieRay Larabie Posts: 1,267
    I think 2023 is the year it all happens. I started gearing up last autumn, and I just released a variable-only typeface. I don't understand why the “from” price is displayed that way—it's only twelve bucks.

    I'm hoping that distributors will step up this year. Even if they don't allow users to adjust the sliders, they could at least allow animated GIFs to demonstrate the capabilities. Some distributors, like FontSpring, FontBros, and Creative Market will accept variable submissions, even though they’re not currently displayed correctly. Monotype’s tool flat-out rejects them. At the very least, it should detect that it’s a variable font and override the overlap warnings.

    Customers' trust when purchasing a variable font from a distributor is currently required to be especially high. I'm presently pricing them low since I don't believe the client should bear all the risk. It may not function with their programs and may cause printing issues, but it should be entertaining to experiment with. While adjusting weights, widths, and optical sizes is useful, there is also a world of gimmicks possible that can drive a designer's imagination, or at the very least provide some amusing dials to twiddle.

    Does it make financial sense to release non-variable styles along with variable fonts? Probably not. But with some typefaces, the variable aspect could be the whole point. If all we’re really providing is finer weight and width adjustments, nobody’s going to get excited about this. Take a chance, do something interesting with variable fonts, and push this forward. That’s the only way we can get the distributors to step up and support variable fonts.

  • Christopher SlyeChristopher Slye Posts: 93
    edited January 24

    I'm hoping that distributors will step up this year. Even if they don't allow users to adjust the sliders, they could at least allow animated GIFs to demonstrate the capabilities. Some distributors, like FontSpring, FontBros, and Creative Market will accept variable submissions, even though they’re not currently displayed correctly. Monotype’s tool flat-out rejects them.


    We (at Type Network) accept them and have a nice UI for trying out the axes. I’m sure there’s a better version in our future, but we like it. We just need more people to notice!
  • DanRhatiganDanRhatigan Posts: 29
    edited January 24
    I’m mostly impressed with Adobe’s roll-out, although I have the same slight grumbles as Thomas. My battle cry the whole time I was at Adobe was that their implementation would likely make or break the general creative user’s adoption of variable fonts, even if VFs became the default delivery mechanism on other platforms. I suppose we’ll start to see in the coming months. 
  • An interesting aspect of Adobe's interface is the placement of various handles around the main display that allow for an easy visual tour of the axes, as well as a quick indication of which axes exist, e.g., no arched handle at the top = no italic axis.

  • Aside from an oddity about defaulting to the minimum on every axis, instead of the settings of the default instance, it looks pretty good.
    I would like to put this statement in context. First, it is important to understand the technical setup of Variable Fonts. Every VF will have an “origin”, which is the drawing from which every other instance is derived, by way of deltas. The origin (or default instance) is the place at which all axes intersect, consequentially this default will often be an extreme style like “Light Condensed” or similar.

    Now, it it possible to insert intermediate sources at a more reasonable spot in the design space (and make that the default), however this comes at the expense of added file size. Many projects based on older source data (like Kepler, Myriad, etc) do not have intermediate sources, therefore the default, representative style is – for better or worse – Light Condensed.

    You also said “yes, the full variable releases of Myriad and Minion” — I wish this were true.
  • Ray LarabieRay Larabie Posts: 1,267
    @Frank Grießhammer Unless I misunderstood the warnings, to pass Adobe's FontBakery test, intermediate masters are required. Two of my fonts only had masters on the corners, and I had to add intermediate masters to make them pass.
  • edited January 24
    @Ray Larabie You misunderstood the (admittedly, poorly-worded) warnings.
    https://forum.glyphsapp.com/t/variable-font-origin/24441/14
  • Dave CrosslandDave Crossland Posts: 1,242
    Frank Grießhammer said:

    Many projects based on older source data (like Kepler, Myriad, etc) do not have intermediate sources, therefore the default, representative style is – for better or worse – Light Condensed.
    ...but, taking any VF with only a wght axis, the OpenType spec says that the wght axis default is 400, so even if the font has only 2 masters at min and max, the default value must be 400, not whichever master is in the glyf table?
  • zakkurizakkuri Posts: 1
    edited January 25
    @Dave Crossland The spec says 

    Recommended or required “Regular” value:
     400 is required.

    And below that it says

    In a variable font that implements 'wght' variations, the value in the usWeightClass field of the OS/2 table must match the default 'wght' value specified in the 'fvar' table.

    None of that says the wght axis default is 400. The default is whatever you want it to be. To be compliant you must also define a so-called "Regular" instance at 400 which is something fontbakery checks for, but nothing says that 400 must be the default. 
  • Dave CrosslandDave Crossland Posts: 1,242
    edited January 25
    https://learn.microsoft.com/en-us/typography/opentype/spec/dvaraxistag_wght literally does say that as quoted, except it uses the word Regular instead of default. 

    I think I was also imprecise about the difference between default and regular, and not communicating the clarity I kindly think you are missing :) 

    The default master ending up in the glyf table is a technical detail of implementation.

    What users expect is the Regular weight 400, Regular width 100, etc. That isn't necessarily any master location. But it is what users expect to see as the style rendered when nonaxes value are input.
  • jeremy tribbyjeremy tribby Posts: 142
    edited January 25
    Aside from an oddity about defaulting to the minimum on every axis, instead of the settings of the default instance, it looks pretty good.
    I would like to put this statement in context. First, it is important to understand the technical setup of Variable Fonts. Every VF will have an “origin”, which is the drawing from which every other instance is derived, by way of deltas. The origin (or default instance) is the place at which all axes intersect, consequentially this default will often be an extreme style like “Light Condensed” or similar.

    Now, it it possible to insert intermediate sources at a more reasonable spot in the design space (and make that the default), however this comes at the expense of added file size. Many projects based on older source data (like Kepler, Myriad, etc) do not have intermediate sources, therefore the default, representative style is – for better or worse – Light Condensed.
    I don't understand this. why would you need intermediate sources when you can set a default axis location with the "default" attribute on an AxisDescriptor in your designspace?

    for example, to set the origin at regular weight and regular width:

    <axes>
      <axis tag="wght" name="Weight" minimum="100" maximum="900" default="400">
         ....
      </axis>
      <axis tag="wdth" name="Width" minimum="70" maximum="100" default="100">
         ....
      </axis>
    </axes>

    doesn't that work? in Glyphs 3 it's a custom parameter called "Variable Font Origin."  I forget where exactly this ends up in the binary, but websites like FontGauntlet parse it just fine, don;t see why Adobe couldn't. I may be misunderstanding you (or myself 😅) though


  • Jens KutilekJens Kutilek Posts: 291
    edited January 25

    for example, to set the origin at regular weight and regular width:

    <axes>
      <axis tag="wght" name="Weight" minimum="100" maximum="900" default="400">
         ....
      </axis>
      <axis tag="wdth" name="Width" minimum="70" maximum="100" default="100">
         ....
      </axis>
    </axes>

    doesn't that work? in Glyphs 3 it's a custom parameter called "Variable Font Origin."  I forget where exactly this ends up in the binary, but websites like FontGauntlet parse it just fine, don;t see why Adobe couldn't. I may be misunderstanding you (or myself 😅) though


    You need a master at all locations pointed at by minimum, maximum, and default. So for your wght axis, you would need 3 masters; for your wdth axis, you would need 2 as the default is the same as maximum.

    It's possible that Glyphs automatically adds a master at the location when you use the "Variable Font Origin" custom parameter. You should notice a difference in file size. Correction: In Glyphs, you can only point the "Variable Font Origin" to masters that exist in the file. So you couldn't set a Regular origin if your only masters are wght=100 and wght=900.
Sign In or Register to comment.