[OTVar] Introducing OpenType variable fonts

John Hudson
John Hudson Posts: 3,204
edited September 2016 in Font Technology

A single font that behaves like multiple fonts

As I post this, colleagues from Microsoft, Google, Apple, and Adobe are at ATypI 2016 in Warsaw making the first public announcement of the OpenType Font Format specification version 1.8, and its key new technology: OpenType Font Variations.*

The Font Variations working group is pleased to be partnering with TypeDrawers to provide a centralised location for online discussion of the new technology. Members of the working group will be monitoring this thread and any others including the tag [OTVar] in the subject line, ready to answer questions. General questions or feedback on the technology can be provided in this thread. For discussion about specific aspect of the technology, or for individual queries, we recommend starting a new thread with an appropriate subject line, e.g. ‘[OTVar] CFF 2’.

* A note on terminology: the official name of the technology is ‘OpenType Font Variations’, while fonts including the variations technology are referred to as ‘variable fonts’ (a term introduced by Nick Sherman: 'Variable Fonts for Responsive Design').

Links

Introducing OpenType Variable Fonts
A medium.com article that I was tasked to write by the working group, explaining major aspects of the technology and highlighting some key implications of the format architecture for font makers and font tool developers.

OpenType Font Variations Overview
The new chapter of the OpenType specification explaining how OT font variations work.

OpenType 1.7 → 1.8 changes
A useful diff version of the two most recent version of the specification, highlighting changes.

Announcements by three of the working group industry partners:
Adobe • Google • Microsoft

Note that links to the OpenType specification currently point to a specific /otspec180/ folder. It is recommended to link to the published version of the specification when it is updated to the new version.
Tagged:
«1345678

Comments

  • Thomas Phinney
    Thomas Phinney Posts: 2,889
    FontLab announces support for OpenType variable fonts.
  • Belleve Invis
    Belleve Invis Posts: 269
    edited September 2016
    https://github.com/caryll/otfcc/issues/32

    Track this please :)

    (but I do not have any test payloads for now...)
  • [Deleted User]
    [Deleted User] Posts: 0
    The user and all related content has been deleted.
  • Chris Lozos
    Chris Lozos Posts: 1,458
    Adobe still has not totally supported stylistic sets so why dream they would move more quickly on this?
  • Daniel Gamage
    Daniel Gamage Posts: 2
    https://www.periscope.tv/w/1PlKQeQEkYkKE

    I just wanted to point out the file savings demo around 16:00, which is a little self-evident but didn't occur to me until someone pointed it out.
  • Peiran Tan
    Peiran Tan Posts: 22
    I’m curious about how this could be controlled in the browser (or maybe it’s because I haven’t read enough spec that is already published). Is it controlled through CSS -font-feature-settings? Would we in the future write super-long declarations?
  • Chris Lozos
    Chris Lozos Posts: 1,458
    I am very curious about how the new design axis will work.  If there is only one 'file" how will the weights be interpreted--mostly, how will the type designer supply the information that the 'file" will use to interpret weights?  Will we still draw them as always but the software will package them in a different way with data tables to point the "file" in the correct direction as defined by the type designer?
  • John Hudson
    John Hudson Posts: 3,204
    James M, I spun-off your interesting point about naming of arbitrary instances to a new thread:
    http://typedrawers.com/discussion/1765/otvar-naming-arbitrary-instances
  • John Hudson
    John Hudson Posts: 3,204
    Pieran, yes, the idea is that variable font design space will be addressable in CSS. Members of the Font Variations and W3C CSS working groups are in contact, and variable fonts are on the agenda for this month's W3C TPAC meeting. Topics will include not only mechanisms to explicitly specify instances in CSS, but also enable conditional dynamic (responsive) web typography with variable fonts.
  • John Hudson
    John Hudson Posts: 3,204
    Chris, yes, you've got it: font makers will design as they do already, with multiple master design sources, and font tools will write this to the variable font as a single set of outlines and deltas to the axis extremes and any intermediate masters within the design space.

    We're deliberately avoiding using the term 'master' when referring to the variable font data, because there is only one set of outlines stored, but we use the term when talking about sources. One of the criteria for the format was that it should be easy to generate from the kinds of interpolable sources that font makers are already typically making.

    [Note also the aspect of all this for which David Lemon received applause during the ATypI announcement: Adobe are updating the CFF rasteriser to allow overlapping outline paths.]
  • John Hudson
    John Hudson Posts: 3,204
    [Now going on vacation for 24 hours. Hopefully some of the other working group members start contributing here, although many of them are in Warsaw at the moment.]
  • Kent Lew
    Kent Lew Posts: 944
    Adobe are updating the CFF rasteriser to allow overlapping outline paths.
    Excellent! That answers that. One of the first questions I had upon reading the overview.
  • Ben Blom
    Ben Blom Posts: 250
    font makers will design as they do already, with multiple master design sources, and font tools will write this to the variable font as a single set of outlines and deltas to the axis extremes and any intermediate masters within the design space.

    For a font family with many different weights, the distance between the two ends of the weight axis is too big to only design the two fonts for the extremes of the axis. Because of that, I am used to design a “weight axis” font family as three separate fonts: (A) a font somewhere in the middle of the weight axis, (B) one at the thinnest end of the weight axis, and (C) one at the heaviest end of the weight axis. After that, the intermediate fonts are being created by interpolation between (B)-(A) and (A)-(C). Now I wonder if it is possible to feed three such fonts to the “variable_font”_font_tools to create a variable font which contains all relevant info from all those three fonts?

  • Read Roberts
    Read Roberts Posts: 7
    Yes, it is. In fact, you get the most resolution out of the normalized design space if you do exactly that. Variable fonts must have a 'default' design which is, by definition, at position 0 along every axis, with range from -1.0 to 1.0. Basically, anything you can do in Superpolator or FontLab you can build directly as a variable font, including master designs at arbitrary points in the design space.  However, there can be conflict between accuracy of design intent (improved by having more master designs)  and file size (improved by having fewer master designs). For example the Adobe font family AcuminPro has 16 masters for two design axes, width and weight. This is to some extent a historical accident - it was originally designed with a smaller design space than it has now, and this was done by adding more master designs to the original set - but most of the masters are really needed. If Adobe built this as a variable font, the it would be nearly as large as 16 separate faces. However, using just 4 master designs looks OK to the casual users, but would not be acceptable to the original designers. It would take some thought to decide just how many and which masters to use to make a variable font for this family. Maybe there will be different choices for different markets - fewer masters for variable fonts for smart phone apps, more for a variable font for tablet apps, or other venues where file size is not an issue. We are all just beginning to think about these issues.
  • Dave Crossland
    Dave Crossland Posts: 1,430
    Kent Lew said:
    Adobe are updating the CFF rasteriser to allow overlapping outline paths.
    Excellent! That answers that. One of the first questions I had upon reading the overview.
    Although Toshi asked if they will update it to allow components, and it seems, no.
  • Simon Cozens
    Simon Cozens Posts: 747
    Richard Fink said:
    I don't think it's cynical, however, given the magnitude of the task, to assume it will take a long time to materialize.
    Can't see it any other way. 

    It's great that we're seeing support in font editors already, which is imperative for getting variable fonts out there, but it is indeed a huge task to make this happen down at the user level. Take an application like InDesign: you will need to implement it in the UI, have a renderer which supports it for display, have something which vectorizes it to PCL or PS for print, and you will also have to update the file format to store user choices about font variations. And a similar story for every single document-based file format; for instance, we're going to need a new PDF specification to handle this. (Not a hard job thinking about how PDF works, but new specifications, and then their implementation in readers, take time.)

    I can see that it is going to happen, but I can't imagine you'll be printing out documents with variable fonts for a few years yet.
  • Khaled Hosny
    Khaled Hosny Posts: 289
    Printers do not need to know anything about variable fonts, not even PDF. You just send/embed an interpolated instance, and it will be the same as ever.
  • Simon Cozens
    Simon Cozens Posts: 747
    edited September 2016
    Huh, yeah, that would be a smart way to do it. And if you're generating instances as traditional OTF, you don't even really need a separate screen renderer either. So if you have to generate instances for this stuff already, it might make sense to have an instance generator step before your shaping step, rather than trying to render CFF2 directly. I'll have to look at the freetype implementation to see how it's being handled.

    But you would still need to build the UI, store the settings in your document format, and you would still need to plug your instance-generator into the layout and processing pipeline. So still a lot of work to be done before it filters down to the user.
  • Chris Lozos
    Chris Lozos Posts: 1,458
    And here I sit, nearing the completion of a superfamily with 13 weights--done the old fashioned way.  Here is hoping the new technology will help me in future ventures.
  • Mark Simonson
    Mark Simonson Posts: 1,736
    Chris: Judging from watching the video of the ATypI presentation that Erik van Blokland shot (the one that Daniel shared above), particularly the part where David Lemon generates an OTvar font from the existing source of their recent Acumin family, we will be able to build on what we are already doing with masters in our current font tools.
  • James Puckett
    James Puckett Posts: 1,995
    edited September 2016
    Georg is already beta testing exports of two-master fonts from existing Glyphs source files. It doesn’t work well, but I’m sure it will get fixed once ATypI is over ;)
  • Nick Shinn
    Nick Shinn Posts: 2,210
    edited September 2016
    I would imagine it could produce a surge in the number of typefaces published, if it is any kind of workflow speeder-upper.

    I have a backlog of undeveloped ideas; meanwhile I am churning through the production of multi-font families.

    Therefore the business trick will be to publish more typefaces, fewer fonts.

Categories