Can/should custom/new axes use location names in the STAT table?

[arrowtype]

Describe the issue

The Axis Registrty newly-merged axes Bounce, Informality, and Spacing.

I am using these in Shantell Sans. Currently, I have instances at various locations along these axes.

Should these instances be specified and named in the STAT table? I’ve looked for an answer in the GF Guide, but I don’t see the answer for custom/new axes.

Currently, I am setting STAT locations in a Python script, and here are the dicts used for these new axes:

    dict(
        tag="BNCE",
        name="Bounce",
        ordering=2,
        values=[
            dict(value=0, name="No Bounce", flags=0x2),
            dict(value=62.5, name="Bouncy"),
            dict(value=100, name="ExtraBouncy"),
        ],
    ),
    dict(
        tag="INFM",
        name="Informality",
        ordering=3,
        values=[
            dict(value=0, name="Normalized", flags=0x2),
            dict(value=100, name="Informal"),
        ],
    ),
    dict(
        tag="SPAC",
        name="Spacing",
        ordering=4,
        values=[
            dict(value=0, name="Default", flags=0x2),
            dict(value=500, name="Max Spacing"),
        ],
    ),

I’m happy to provide more detail if it’s helpful! Thanks.

[davelab6]

Spac max looks wrong, as the registry max is 100?

These look ok to me.

I might recommend value=60 for name="Bouncy" to keep it simple and symmetrical but it's not a big deal

[arrowtype]

Oh, good catch on the spacing max being wrong! It’s correct in the fvar, but was indeed in need of an update in the STAT table.

As for BNCE=62.5, I tried 50 and I tried 75, and it felt just right in the middle of those, at 62.5. Of course, 60 is functionally very similar, but I I like counting in 8ths more than in 10ths. :)

[arrowtype]

Also, thank you for your feedback here!

[arrowtype]

I might recommend value=60 for name="Bouncy" to keep it simple and symmetrical but it's not a big deal

I ended up thinking this idea through a little further... but ended up at the same decision as before.

https://github.com/arrowtype/shantell-sans/issues/123

[RosaWagner]

dict(value=0, name="Normalized", flags=0x2), should be "Default" as in axis registry (to avoid fontbakery FAIL).

We often put more in the STAT than the Axis Registry would allow, indeed. But don't forget that there might be in the future new rules about the names, as it happened with the opsz axis (now Xpt instead of "Text", "Display" etc). Whatever you choose here could be revoked later and may confuse user when upgrading. Hence why we only add the "Default" location of custom axis (for now) in the STAT table. A next step would be to chose on a naming system that makes sense and upgrade the custom axis families.

In any case, for now, the STAT values without FVAR instances counter-part are not so important, so I don't see a problem in experimenting here. But it may be relevant to go with only Default now, onboard, think about names and then update?

[vv-monsalve]

Hi @arrowtype

The short answer is yes. We are using the STAT table to provide information for defined instances that can go beyond the ones allowed in the fvar and this especially applies to custom axes.

We have included information about this in the GF-Guide

According to the Google Fonts specification, every instance that is allowed to be a part of the fvar table should also be listed in the STAT table with equivalent values and names. However, the STAT table can also include axis values with string labels which can add extra style variants. This means that fonts with a wght axis range of 1 to 1000 can have named instances in the STAT table for the 1 (Hairline) and 1000 (ExtraBlack) positions for desktop applications that could make use of this table information.

The above is particularly crucial for variable fonts that only include custom axes. The STAT table with a full set of style variants defined for all the custom axes will provide richer information about the axes of variation and individual styles within the family. You can inspect Sixtyfour as a reference.

I'm closing this issue here. Please feel free to reopen it if you have further questions.

[arrowtype]

Thanks for the update, @vv-monsalve! Sounds good to me.