lib key in .designspace rather than separate file?

[twardoch]

Since statmake already relies on the presence of a special lib key if STAT defines non-variable axes (like italic 0/1), and there seems to be no movement on upstreaming stylespace — shouldn't statmake be extended so that it accepts the entirety of stylespace being stored as a custom lib key (org.statmake.stylespace or so) inside .designspace?

The CLI would need to be changed so it uses optional args, which IMO are more readable than positional args anyway (esp. if it's more than 2 positional args)

statmake [-s stylespace] -m designspace -f infont [-o outfont]

If -s is not provided, statmake should look in the "org.statmake.stylespace" key of the designspace file.

The choice of -m is convenient since fontmake users it as well.

statmake should overwrite the original font only if -o is not provided. If it is, it should output a new file.

[davelab6]

Where is the upstream for stylespace?

[madig]

You are looking at it 😁

Currently out of London, will reply when I get back.

[madig]

Hm. I guess you could cram it into the existing Designspace file, although you might not want it if you actually have additionalLocations. The motivation for an external file was partly that we ship VFs in several subsets, which means having several Designspace files lying around that reference a different subset of masters (hence that masters/ destroying issue report I filed for FL6). Having one external file makes it easier then.

I'll put the CLI changes on the Todo list.

I'd like to upstream Stylespaces at some point, my impression was that there was a general lack of interest among fontTools maintainers so far. If your Stylespace file can fit into one Designspace file, modifying the actual Designspace format as outlined in https://github.com/fonttools/fonttools/issues/1507 would be even more elegant. Maybe this can tie into your idea of a more general "font set". One day :)

PS: I'd be curious to know where you are using statmake?

[twardoch]

• "masters/ destroying issue" is fixed

• The lib thing would make sense in so far that I’d like to implement a generic lib system in FLVI where we have a Custom section in Font Info > Font where lib entries from .designspace would be stored, a Custom section in Font Info > Master where lib entries from .ufo would be stored — and we already have lib key in the Source panel for lib entries of a .glif.

The Custom stuff would be JSON (like the Source panel stuff), but you’d be able to make the data travel VFC/VFJ <-> DesignSpace+UFO <-> possibly Glyphs. (Since glyphsLib already puts many of the Glyphs custom parameters into lib, that’s logical).

• FLVI does not yet natively properly export STAT, but we have those "Axis Instances" in Font Info, which are effectively STAT records (named locations for each axis). We’re changing that a bit now, but overall, those should be used to build the STAT table, and I’m thinking of just using statmake directly. The internal axis instances notation would be extended to cover the most interesting things.

We already cover ElidableAxisValueName by surrounding the name with parantheses, but we don’t yet have a notation for linked_value. But — if the stylespace entries optionally go into the .designspace lib, we would ultimately allow users to set up STAT type 4 or whatever else entries in the JSON Custom section that I mentioned above.

The Axis Instances super-simple notation would cover 90% of cases (then the lib portion or a .stylespace file would be generated by FLVI when building VF — since we already use varLib for this) while the optional JSON Custom params that give you the extra detail would be used instead if present.

[madig]

Interesting. How would the lib system handle external files that are invariably going to crop up when you have e.g. uprights and italics that are not compatible and therefore in different Designspace files?

[twardoch]

In FontLab VI, you cannot have different designspaces in one VFC/VFJ (i.e. FontLab font). Because a FontLab font can only have one main master. So your upright designspace used one VFC, and italic another. It is possible to declare some masters in FLVI non-interpolable (e.g. if you just want to package some single styles in one VFC), which is kind of like my "font set" proposal. But a font set is just a generalized designspace with interpolation being optional. But I don't think we should allow multiple designspaces in one font set — that's too much complexity, I think.

Therefore, really, a "lib" of a .designspace file really is the font-level Custom data, and a "lib" of a .ufo is the master-level Custom data. If you have just a standalone UFO, its lib still can and should be on FLVI master level.

[twardoch]

Overall, I'm suggesting that stylespace should just be allowed to live inside DesignSpace lib — then it'd be a FontLab font-level Custom data, which feels right.

Sure, there are multi-file setups which call for a rather different structure. But UFO isn't really good for such setups anyway — you cannot share GLIF files between UFOs, which is really terrible — it's not clear how to store glyphs that don't have any variation. You may put them into the Regular (main) UFO. But then you may want to define in your Condensed a kerning pair between a glyph that is actually condensed and one that doesn't change — how do I do it? Well, I have to duplicate the GLIF then. And it's virtually impossible to make TTCs sensibly.

I wrote about shortcomings of UFO many times. It's good that it exists, but it isn't really a format made for more complex relations and assets sharing. You can share features but only because the FEA syntax happens to have "include", so you can kind of cheat a bit. But you cannot share much else. So I'm not really concerned about sharing one stylespace between many .designspace files — stylespace is very minimal data and there's no harm in actually duplicating it.

[madig]

I am open to allowing whole Stylespaces into the Designspace lib, but want to keep the capability to have external references. The STAT table is family-global information, while VFJs/DSes are sub-family containers. The reality of business doesn't always map cleanly to a single file.

Having one VFJ per Designspace is reasonable, but as I said about potentially many Designspaces per project, having one file/source of truth helps in the daily work routine. Designers must be able to understand and edit the files by hand themselves and they already struggle with all the different files as is. We make use of include in almost all projects to share feature files, and we want this for Stylespace files as well. Duplicated and de-synchronized data the designer didn't see in a torrent of Git diff shit is a real thing that happens and results in time lost to QA :(

Overall, I'm suggesting that stylespace should just be allowed to live inside DesignSpace lib — then it'd be a FontLab font-level Custom data, which feels right. [...] I wrote about shortcomings of UFO many times. It's good that it exists, but it isn't really a format made for more complex relations and assets sharing.

Whatever format you use, I think there is a fundamental data relationship complexity imposed on us by Unicode and OpenType that is easy or hard to work with depending on the workflow decisions you make in your editor/tools. And I think no-one really figured it out in a round and sound way yet...

it's not clear how to store glyphs that don't have any variation. You may put them into the Regular (main) UFO. But then you may want to define in your Condensed a kerning pair between a glyph that is actually condensed and one that doesn't change — how do I do it?

I don't understand these examples, can you elaborate? Mind you, at DaMa we are interested in pushing UFO forward, so far there just haven't been pressing needs that made operations allocate time and money. We do indeed work with copying glifs and whole UFOs around to achieve specific things (i.e. turn an existing family into a VF which needs VF-specific adjustments which can't be cleanly added on top of the static masters without redoing engineering, or work on different scripts for a family in different repos while copying the Latin over because the projects go at different speeds, etc.). There is more to it than the raw capabilities of the format.

[twardoch]

Hm... Well, let’s say I have the Lato family that is supposed to ship as 2 VFs, one upright with the fvar.wght axis and one italic with the fvar.wght axis. So I have 2 VFCs that translate to 2 DSes with their UFOs (that now can share the same masters folder finally, when I work in FLVI).

I just consulted with the colleagues at MS who confirmed that for the VFs, I would have these STATs

1. In Lato VF upright:

axes:
-   name: Weight
    tag: wght
    locations:
    -   name: Hairline
        value: 100
    -   name: Thin
        value: 200
    -   name: Light
        value: 300
    -   name: Regular
        value: 400
        linked_value: 700
        flags:
        - ElidableAxisValueName
    -   name: Medium
        value: 500
    -   name: Semibold
        value: 600
    -   name: Bold
        value: 700
    -   name: Heavy
        value: 800
    -   name: Black
        value: 900
-   name: Italic
    tag: ital
    locations:
    -   name: Upright
        value: 0
        linked_value: 1
        flags:
        - ElidableAxisValueName

2. In Lato VF italic:

axes:
-   name: Weight
    tag: wght
    locations:
    -   name: Hairline
        value: 100
    -   name: Thin
        value: 200
    -   name: Light
        value: 300
    -   name: Regular
        value: 400
        linked_value: 700
        flags:
        - ElidableAxisValueName
    -   name: Medium
        value: 500
    -   name: Semibold
        value: 600
    -   name: Bold
        value: 700
    -   name: Heavy
        value: 800
    -   name: Black
        value: 900
-   name: Italic
    tag: ital
    locations:
    -   name: Italic
        value: 1

So it’s not really one STAT for the family, is it? Each DS has its own stylespace. Which could live in the DS. But I think the ability to keep that data in dedicated files is useful as well.

(I'll DM you on the other issues as they're a bit offtopic).

A.

[madig]

It's a separate raw STAT table, but one global Stylespace file that statmake tailors to the VF in question :)

[twardoch]

Oh, I see, so that's why those additional locations are needed in DS (I was wondering). Somehow I didn't realize that statmake subsets the stylespace as it compiles it into the STAT table of a font :)

[madig]

Maybe I should point this out better somewhere. Hm. The matter of STAT tables is, in general, confusing.

I also need to write a apply to static font function some time so that eventually, all fonts are properly marked.

Edit: updated the readme.

[twardoch]

I think right now we still don't have very good visual examples on how STAT tables are intended to be used in apps, so people don't know what it's for. I like STAT a lot, it basically mirrors the Font Info UI I made for Fontographer 5 :)

But there are things that are unclear. How shall the ranges be made? Should they touch or maybe a range should really be just +/–5 or 10 around a named point? Are the ranges really useful?

And of course, indeed, if you productize your family that in the sources is 2 very long axes as 24 "variable instances" i.e. variable fonts that only have short axis ranges around the critical points (because maybe you don't want to offer one $700 font), then setting the STAT up becomes a bit tedious (though if statmake uses just one stylespace, then it actually would be cool — I'll need to check).

[madig]

statmake currently does not consider ranges, other than additional fields for a defined stop. I.e. for https://github.com/daltonmaag/statmake/blob/master/tests/data/Test.stylespace#L110-L120, your instance must land on 900, putting one at 901 will result in a missing entry or a raised exception, forgot which. I personally have not seen an understandable use for ranges, so meh.

[anthrotype]

I personally have not seen an understandable use for ranges, so meh.

I read on some mailing list that Adobe apps will show a style name “Medium-499” for wght=499, which is a bit more user-friendly than something like “weight-499” or whatever. So, if your ranges cover a whole axis, as you move the slider, you will only see human-readable names.

[madig]

https://github.com/daltonmaag/statmake/releases/tag/v0.2.0