Feature request: The ability to export stylistic set 30 to 99 with feature names

Glyphs
1

In the current version of Glyphs 3 it is possible to export ss21 and above without any issues, and the features work as intended in the applications that support them.

There is however a few caveats. ss30 and above will not export if given a feature name, an entry that the program allows you to make use of.

7
71180×312 44.5 KB

When you try to export a stylistic set that is not ss01 - ss29 with a feature name attached you’ll get the following error message.
45

At the moment, this how Glyphs 3 treats stylistic sets.

ss01 - ss20 : can be exported, has name box, will export if given name
ss21 - ss29 : can be exported, has name box, will export if given name
ss30 - ss99 : can be exported, has name box, will not export if given name

I find it somewhat odd that one can export ss21-ss29 with feature names but not ss30-ss99.

1
an example of how stylistic sets 30 and above looks in applications without a feature name attached.

While ss21 and above are not at the moment an official part of the opentype specification, it is very likely that they’ll be made official at some point in the near future. Multiple programs already supports these stylistic sets, and it would therefore be beneficial to export these stylistic sets with names attached for use in those applications.

Glyphs already supports ss21 - ss29 almost in full. The only thing that appears to differentiate them from ss01 - ss20 is that their default feature names are listed as “ssxx” instead of “stylistic set xx”. This does not have any effect on how the features works in Glyphs however.

8

Since ss21 - ss29, while not part of the opentype specification, is supported in full in Glyphs 3, I see no problem with adding full support for rest of the set.

2

The OpenType specification only defines ss01 to ss20. If you include ss21–ss99 in your fonts, those are ad hoc features which many applications will not support. While the OpenType spec does not rule out developers defining their own features, there’s no reason to expect Glyphs to support features that do not officially exist.

1 Like
3

I outlined most of the reasons for why I believe they should be supported in my main post. They are already partially supported, with ss21-ss29 being supported in full. Making it possible for Glyphs to export the rest of these sets with names attached is something I believe shouldn’t be too much to ask. The rest of the support needed for these stylistic sets appear to have already been implemented.

If strict adherence to the opentype standard was a must, then I would question why ss21-ss29 are already supported at the level that they currently are.

If enough fonts and software makes use of these features there will eventually be enough evidence for a proposal for their addition to be written and eventually accepted into the specification. The reason for why only 20 was originally accepted appears to be due to a lack of evidence that fonts would need more than 20, and that other opentype features couldn’t make up for the lack of the rest of the sets.

There was some discussion regarding this back in 2019. I am not sure if the possible proposal that was mentioned at the end, ended up being written though.
https://lists.aau.at/pipermail/mpeg-otspec/2019-March/thread.html#90

4

I would use more than twenty ssNN features if they were in the spec. If anyone is up for submitting a proposal for expanding the number past twenty, I can contribute material. (But I myself won’t use a tag that’s not been officially accepted.)

5

I am currently busy writing busy writing unicode proposals myself, so an opentype proposal is not something I have time to write at the moment either unfortunately.

The only reason for why I am adding them is because they are supported in some of the software I make use of. Opentype support is overall quite spotty, so I’ll support relevant features that software supports.

Software can be updated to support these feature and others later, if enough fonts make use of them.

6

According to the OpenType spec, ss## features are intended for style sets that change a group of glyphs. I suspect your font does not have more than 19 different style sets but instead many variants of individual glyphs. For that, there are character variants (cv01–cv99), see the following thread for details:

7

I use stylistic sets to change groups of glyphs and for individual variants I use character variants. As such I follow opentype spec as it is described.

I simply have more than 20 groups of glyphs that I need to change through stylistic sets, groups of glyphs where character variants or other opentype features doesn’t work as a substitute.

I currently have a bit over 30 distinct stylistic sets in my font and will likely end up with a bit over 40 when it is done.

For changing individual characters there is 99 entries to use, that most software should support equally.

For changing groups of glyphs, there are 20 entries that are supported in most software and 79 sets that are only supported sporadically due to not being officially part of the specification at the moment.

To remedy this issue I put the most useful stylistic sets as the top 20 entries and put the rest in subsequent less supported entries.

8

I would advice against using ss## above ss20 since those features may be defined in a future version of the OpenType standard but with slightly different recommendations regarding names, lookup types, etc. Your font would clash if such a revision of the OpenType spec was published. Instead, use capital-letters-only feature tags for custom features. The spec guarantees to never define such features so there will be no clashes with future software. Otherwise, consider splitting the font into two font files, each containing 20 style sets.

9

I don’t see how they would define ss21 differently from ss20. It is clear that ss21-ss99 have been reserved for this purpose and will be made official when a proposal can be presented showing that there is a need to officially add them to the specification.

As I have said earlier using ss21 and above already works in certain software without any issues. SS21 and similar feature codes are not supported and won’t be useful for this purpose.

The only thing I am asking is for you to enable exporting of feature names for ss30 and above so I don’t have to find a way to edit in the names myself to the already exported font files. I am not sure why this would be something you would have any issue with supporting. The only difference would be that stylistic set 30 would be able to have a custom name instead of being locked to the name “Stylistic Set 30”.

1 Like
10

Feature names should also be added to the character variants feature.

Feature names are in this case an official part of the opentype specification and Glyphs should support them by default.

11

Glyphs does support them, but there is no UI. Add them as specified by the AFDKO spec:

cvParameters {
    FeatUILabelNameID {
        name 3 1 0x0409 "Alternative small a";  # English US
        name 1 0 0 "Alternative small a";  # Mac English
    };

    FeatUITooltipTextNameID {
        name 3 1 0x0409 "The small a has many forms to offer.";  # English US
        name 1 0 0 "The small a has many forms to offer.";  # Mac English
    };

    SampleTextNameID {
        name 3 1 0x0409 "alpha all axx";  # English US
        name 1 0 0 "alpha all axx";  # Mac English
    };

    ParamUILabelNameID {
        name 3 1 0x0409 "Single story";  # English US
        name 1 0 0 "Single story";  # Mac English
    };

    ParamUILabelNameID {
        name 3 1 0x0409 "Alpha form";  # English US
        name 1 0 0 "Alpha form";  # Mac English
    };

    Character 0x0061;
};
1 Like
12

Is UI support something you would consider adding at some point? UI support would be very useful when working with 50+ character variants as it would show the name of the feature parenthesised in the feature list. It would also be easier to write all the entries correctly if it was included.

13

UI for cv## names is on the list, but I cannot promise any timeline for now.

14

That’s fine, a confirmation that it is on the list is good enough for me.

15

It would be probably be a good idea to show this information somewhere on the site. There appears to only be a “learning” page for stylistic sets and not character variants, but a small section for this could probably be added there. I can’t find any mention of it in the handbook either.

16

The handbook builds on the AFDKO spec; stuff like sub and pos rules are also not explained there. Once the UI lands, we will add the relevant documentation to the handbook/tutorials. Currently, few apps support cv## names anyway, so it is difficult to make recommendations for how a good sample text would look like or how verbose the tooltip should be worded.

17

That makes sense, thanks.