[UFS] Spec needs to be defined

[benkiel]

Opening this to discuss the UFS (or whatever the name will be), based on robotools/fontParts#424. This would be very handy to have for different models of font data (designSpace, Glyphs, etc).

[madig]

(@twardoch: I'm not sure I understand your thoughts in robotools/fontParts#424 correctly -- it sounds to me like you're primarily interested in an API or a (Python) object that allows one to logically bundle sets of masters beyond the semantics of a single Designspace (be it UFO font objects or FontLab or Glyphs master objects) and attach information to those sets?)

[madig]

I'm scratching my head here.

From the roadmap, "UFS" would be a rework of the UFO format to natively support multiple masters in one .ufs package, store global font info, group and feature data in one place, maybe reverse the layers-glyphs relationship, assign locations to layers, etc. An existing UFO v3 would be a single-master UFS, multiple-master fonts would work like .glyphs files, etc.

@twardoch's idea seems to be an add-on structure or API really that that decouples Designspace's source elements from

1. UFOs as the only possible source type (fontTools.varLib.build takes TTFont objects) and
2. the semantic need to interpolate.

and allows for an arbitrary amount of sets of any of the sources with optionally a Designspace attached (?). So it seems to be something very different? How would you store this set information in a .glyphs or .vfc file? Would it be an external file instead? How would you refer to masters in a .glyphs or .vfc file? Would editors work with that file or just fontParts? How do you map editor conventions? Think of intermediate masters that Glyphs.app associates as a brace layer with a specific master but in FL6 they seem to be free-floating.

---

Anyway, I'll assume that his proposal is an add-on file and thought some on what benefits this could bring. A Designspace ties together masters that are supposed to be interpolatable. The leading thought here is: what should a structure provide that does not easily fit Designspace semantics?

Font families come in these setups:

• All masters interpolate
• Some masters interpolate (e.g. wght-uprights and wght-italics are only compatible among themselves)
• No masters interpolate (e.g. legacy project with a 1:1 master->font relationship)

You may want to:

• Define global information that applies to the all masters regardless of compatibility. E.g. STAT table definitions, axis mappings.
• Group...
  • ... compatible masters into (sub)sets to be produced separately without duplicating Designspace files and syncing changes between them. E.g. a wght/wdth/slnt family can be grouped into a full-axis set (wght/wdth/slnt), a wght-axis-only set, a wght-slnt-axes-only set, ... while keeping the axis mapping and STAT information in one place (the same) across all of them.
  • ... (in)compatible masters into (sub)sets to semantically group them, e.g. if you run source linters on your fonts
  • ... (in)compatible masters into (sub)sets with a reduced glyph set

That's off the top of my head.

[twardoch]

My general thinking was:

• UFS should not strongly assume that fonts inside a set are for interpolation purposes. Basically, UFS could represent something like a variable font but should also be able to represent (at least not fully disallow it) something like TTC

• the file serialization (UFS) is, to me, somewhat secondary; I mean, with Designspace+UFO, we de facto already have something like UFS; it could be refined of course; basically, I think "designspace" is just a specialized case of "fontset" that could be universalized

• I was mostly interested in agreeing on a lightweight fontParts API so, roughly speaking, FontLab, Glyphs and UFS could use the same object structure (at least on the highest levels, where there is already a lot of similarities), no matter whether they strictly support UFO or UFS.

[madig]

Hm. This loads fine:

<?xml version='1.0' encoding='UTF-8'?>
<designspace format="4.0">
  <sources>
    <source filename="MyFont-Light.ufo" />
    <source filename="MyFont-Regular.ufo" />
    <source filename="MyFont-Bold.ufo" />
  </sources>
</designspace>

So existing DS strucures could indeed be used.

Edit: what kind of semantics would you need to store TTC information?

I guess one could also extend DS to be able to store multiple "sets" of sources and instances that share axes and lib, but then you could also use multiple DS files. 🤔

[belluzj]

Hello, I wrote in fontTools about a possible evolution of the designspace format that could support some of the use-cases of UFS.

Here is it: fonttools/fonttools#1507 (comment)

And the more detailed proposal (still a draft): https://github.com/daltonmaag/file-format-discussion/blob/main/proposals/designspace_5/README.md

[typesupply]

I'm going to close this issue as we seemed to be in consensus that this shouldn't be part of the UFO spec, but rather something higher like .designspace.