variable fonts: trapezoids?

Because it's something other than meta-conversation about the site, I'll repeat here what I recently asked on the Glyphs forum:

Suppose I have a 2-axis 4-master variable font, say with wdth and wght axes, so narrow/light, narrow/bold, wide/light, and wide/bold masters. Let’s say master values are at 0/0, 0/100, 100/0, and 100/100.

If I want to add an optical size axis, but want to limit uses of it to narrower ranges of width and weight, what’s the proper setup? I’ll add an opsz value of 48pt to those preexisting masters, then:

  • Option one: Set those corners of the design space in from the extremes, eg. to 30/20/8pt, 30/80/8pt, 90/20/8pt, and 90/80/8pt. Essentially making not a cube but a trapezoid (or whatever the three-dimensional equivalent is called).

  • Option two: Generating the same designs as option one, but setting them to the extreme positions to get a proper cube. So what looked like 30/20/8pt is placed at 0/0/8pt, etc. This would mean changing the opsz slider would change the weight/width even though those sliders stay put, I think.

  • Option three: Design the masters at those extremes even though they’re beyond what I want people to use at small opsz, and find another way to constrain user access to them (so they live in the font but won’t be used). Could axis mapping do this?

  • Option four: Design the masters at those extremes even though they’re beyond what I want people to use at small opsz, and learn to live with people misusing them.


  • John HudsonJohn Hudson Posts: 2,863
    edited June 2021
    Hmm. This is the sort of issue that arises if you treat OT variable like MM, with masters at axis extrema, but then want to add an axis that only affects part of the design space. It is much easier if you have your default instance somewhere in the middle of the design space, and can then extend the axes from that location to control their interactions.

    The graph of a straightforwardly progressive opsz axis is often something like a sine wave, because one typically wants the axis to have a lot of influence at small sizes and progressively less influence at larger sizes. So it helps if the default instance is where the wave changes direction. In the case you describe, it is really helpful if the default instance is the point at which you would want the opsz axis to start/stop having an effect. I did something like this in a font in which the opsz axis has a lot of impact on glyphs in the text sizes, but then only affects hairline thickness in the larger sizes: two different behaviours in different parts of the design space defined by the location of the default instance.

    Since an OT variable font needs a default instance—the stored outline set—, it makes sense to put this in the position where it best enables you to control the design space in the way you intend.
  • Craig EliasonCraig Eliason Posts: 1,366
    Yes, you're telling me something I've suspected for a while but didn't want to believe. This default-on-the-inflection-point advice is really useful, because I've already found myself adding Glyphsapp "intermediate layers" at specific points on the first two axes. So I know the x,y,z of where the default should be created. But then will the endpoints of new masters at default-default-extreme spots suffice to create access to all of that same cubic design space?
  • John HudsonJohn Hudson Posts: 2,863
    But then will the endpoints of new masters at default-default-extreme spots suffice to create access to all of that same cubic design space?
    Yes, but you won’t necessarily like what happens in the corners. Every variable axis ‘in play’, i.e. that is somewhere other than the default instance setting for that axis, influences the position of a node, control handle, or anchor, amount of spacing or kerning for any location within the design space. Since this influence is additive, the further away you get from the default instance and the further from each axis, the more extreme the results can be. So when you get into the corners of the design space, you may see things you don’t want, especially if you have particularly extreme weight or width variation, or if you are mixing many more axes into the equation, or if you have made certain choices in how you define your shapes (e.g. I have seen inktraps turn parts of a glyph inside-out when subject to movement by multiple axes).

  • Craig EliasonCraig Eliason Posts: 1,366
    edited June 2021
    In which case I just add back my corner masters and accept the increased filesize/complexity as the cost of doing business?
  • John HudsonJohn Hudson Posts: 2,863
    Ideally, you would add corner delta sets only for the glyphs that require them. Actually, ideally this is something that your tools would do at the time the variable font is generated. So e.g. you might extrapolate a master at the corner between two or more axes, then go in an make adjustments to some of the glyphs, but when the font is generated the tool would write only those delta sets that differ from the calculated extrapolation at that design space location. Optimising the file size is something that should happen automatically and not something you should have to manage in the masters.

    Variable font development tends to be iterative—which is one of the things that makes it difficult to price for clients—because you can’t really know how much work needs to be done in the corners until you have made the axis extrema and tested their interactions.
Sign In or Register to comment.