designspaceLib: ideas for supporting STAT table information

I am throwing around some ideas in my head on how to best support STAT table generation from a Designspace and used Behdad’s idea from https://github.com/LettError/designSpaceDocument/issues/8#issuecomment-333539801 to sketch out some example Designspace files in the fictitious format "5.0". Maybe we can even enhance Designspace as a format if we place STAT information front and center?

I think there are three different use-cases that a Designspace needs to support:

• Designspace for a full variable font that contains everything.
• Several Designspaces for several distinct VFs …
  • … that belong to the same family but aren’t compatible on the outline-level (e.g. upright and italic)
  • … that may have been added after the initial design but may not be outline-compatible with the old releases.
  • … which actually are compatible but that you want to partition into several Designspaces because you want to offer several editions (everything, just upright, just italic, …)
• Static fonts for both cases above.

Sketches

In the following sketches, I removed all tag attributes I found redundant. The only thing that has to be looked up in the UFO is the family name, all other attributes should be computed from the information in the file. It should still be possible to override e.g. the Postscript font name, but the default should have something sensible and pre-computed.

Designspace contains whole family

Here I took the Designspace of one of our fonts and sketched it up:

Venn.txt

Notes:

1. The labels are assigned in design space, because design space coordinates are used to define instances, so matching them is easier.
2. These labels are all format 1, except the label that uses “linkedvalue”, which needs format 3.

Example for format 4 axis values

I think format 4 has been invented to support Decovar.

DecovarAlpha.txt

Notes:

1. Here, I defined the labels outside the axis and then refer to them in the instances. I’m not sure about this, maybe it’s better to add a label tag to instances like this:

    <instance>
      <label value="Default" /> <!-- Adds a format 4 STAT entry at this location -->
      <location>
        <dimension name="Inline Skeleton" xvalue="0" />
        <dimension name="Worm Skeleton" xvalue="0" />
        <dimension name="Stripes" xvalue="0" />
        <dimension name="Rounded" xvalue="0" />
        <dimension name="Flared" xvalue="0" />
        <dimension name="Rounded Slab" xvalue="0" />
        <dimension name="Shearded" xvalue="0" />
        <dimension name="Bifurcated" xvalue="0" />
        <dimension name="Open Inline Terminal" xvalue="0" />
        <dimension name="Slab" xvalue="0" />
        <dimension name="Inline Terminal" xvalue="0" />
        <dimension name="Worm Terminal" xvalue="0" />
        <dimension name="Weight" xvalue="0" />
        <dimension name="Inline" xvalue="0" />
        <dimension name="Worm" xvalue="0" />
      </location>
    </instance>

Designspace contains parts of the family

Here I looked at the STAT table of the SourceSansVariable(Roman|Italics) fonts and sketched up their Designspace files.

SourceSansRoman.txt SourceSansItalic.txt

Notes:

1. The weight axis contains two labels for “Regular” because format 2 does not provide a LinkedValue field. I’ve raised this here: https://github.com/adobe-fonts/source-sans-pro/issues/164#issuecomment-463006052. It’s violating the current STAT specification – maybe this should not be supported in designspaceLib?

Separate file for defining axis labels?

Maybe it’s worth defining a new file format to collect the information for all axes, a Stylespace so to speak? The file contains the same information as a Designspace that contains a complete family but can be shared between different (subset) Designspaces.

Or maybe not?

Potential Problems

I think the biggest impedance mismatch would be that no editor I know of separates out the individual style names for each axis, e.g. in Glyphs, you name your instances “Extra Bold Compressed” etc. instead of (“Extra Bold”, “Compressed”). I’d have to implement some form of string splitting and guessing in glyphsLib to scrape the info back out (we need more of that in glyphsLib).

What do you think?

[belluzj]

Yes that’s why I think it’s worth bringing it up during the UFO meeting. It’s probably easier to evolve the existing designspace format (and bank on existing familiarity, documentation and implementation) rather than invent a new thing from scratch.

I also think it would make sense to invest more in the documentation of the designspace format, following the same proposals that we wrote for UFO: validation suite to allow implementers to check that they support the new features, mini-specifications for lib keys, etc. If that kind of practices and the matching infrastructure become a thing for UFOs, I think it would make sense to use the same practices and infrastructure for the designspace validation suite and specification, as the two formats often work together. Like, the UFO website could be the UFO + designspace website and have all the various specifications hosted in one place, and the UFO validation suite could be the UFO + designspace validation suite.

[belluzj]

I’m bumping this proposal on behalf of Dalton Maag, and in light of the upcoming UFO spec meeting (which I don’t think will address any designspace concerns, except maybe in relation with the UFS proposal).

Nikolaus and me wrote a bit more about this idea and others to expand the designspace format here.. The main idea is to make it possible to:

• have a single designspace file for a whole font project,
• that covers both interpolatable sources and non-interpolatable ones (e.g. uprights vs italics),
• that includes STAT information, and
• that lists all the “products” that can be built from the source files, i.e. several variable fonts and several static instances.

These ideas stem from our heavy reliance on designspace files at Dalton Maag, and the business use-cases for the format that have emerged. At the moment we make do with separate .stylespace files for STAT information, and several related but different designspace files per variable font that we produce for each font project; hence the proposal to unify all these files into one, to reduce information duplication and ensure that updates to the “design space” are consistent.

What do you think?