Upgrade stylistic sets description check to FAIL

[felipesanches]

Original title of this issue was:

"stylistic sets must provide description text"

This check was originally proposed by Denis Jacquerye (@moyogo)

Programs such as InDesign, TextEdit, Inkscape use that info to display to the users so that they know what a given stylistic set offers.

note: A feature record points to a name table entry with the description string.

[RosaWagner]

I just discovered this check. Why "must"?

• The font is not broken if stylistic set doesn't have description
• Fonts for GF are mostly used on the web, we shouldn't make mandatory some optional desktop features
• Accumulating fails that can be ignored is most probably a bad idea (like the avar table one, most of the time ignored cause doesn't fit the common usage).

[m4rc1e]

Agree with Rosalie on this one. Should be downgraded to a WARN imo.

[vv-monsalve]

Agree, this should have only a WARN loglevel status.

[davelab6]

I don't agree, I want a FAIL because its better when these exist than not at all.

Per chat today with @twardoch we should a WARN when there's no localization of the strings when the fonts support 2+ scripts

[davelab6]

@twardoch also recommended to develop common recommendations for typical stylistic sets

[davelab6]

@vv-monsalve also noted a bug in the check that only ss01 was reported when the font has 12.

[felipesanches]

@vv-monsalve also mentioned that she had a hard time making the feature work even while following a GlyphsApp tutorial. I'd like to review that tutorial, can you please share the link to that?

[m4rc1e]

Are named stylistics sets even implemented in fontmake?

[davelab6]

https://glyphsapp.com/learn/stylistic-sets

[davelab6]

Are named stylistics sets even implemented in fontmake?

@moyogo do you know?

[RosaWagner]

For the glyphapp thing, there are problems when you use glyphs 2 and glyphs 3. It is not handled the same way.

[vv-monsalve]

https://glyphsapp.com/learn/stylistic-sets

At the end of this tutorial

[moyogo]

Fontmake can take the FEA featureNames syntax:

feature ss01 {
    featureNames {
        name "Stylistic Set 1";
} ss01;

There's a PR (googlefonts/glyphsLib#615) to translate the Glyphsapp feature notes to FEA syntax but that it needs more work.

[RosaWagner]

So I confirm, using glyphs 3 format 2, stylistic sets' names don't get exported.

[tiroj]

This is something Adobe wanted added to OpenType, and then failed to do a very good job consistently displaying the feature names in their own software. InDesign still only sometimes displays them.

A lot of other software makers have not simply neglected to display the names but have made a conscious decision not to hand over aspects of their user interface to fonts, knowing that they would be the ones to deal with support calls when the names are not correctly implemented in the fonts, are not localised to the user UI, or are offensive.

The names are technically optional, and I think should be treated as such by FB. If you want to flag them as a preferred procurement option for Google Fonts, which require a waiver if not included, go ahead, but if FB is intended as a general QA tool a Warn is more appropriate than a Fail.

Note that not all tools for developing OTL support featureParamsOffset, so for some workflows adding names to SS and CV features requires manually hacking the GSUB and name tables.

[felipesanches]

If you want to flag them as a preferred procurement option for Google Fonts, which require a waiver if not included, go ahead, but if FB is intended as a general QA tool a Warn is more appropriate than a Fail.

This check (com.google.fonts/check/stylisticset_description) is currently included in the vendor-specific googlefonts profile, so it is up to the Google Fonts team to decide whether this should be a FAIL or a WARN.

https://github.com/googlefonts/fontbakery/blob/main/Lib/fontbakery/profiles/googlefonts.py#L5274

If this kind of checking is useful for other vendors (or as a general policy for any font project), then it could be included in other profiles such as the universal profile and in that case I agree that it might be better to classify it as a WARN-level check in that more general scope.

[felipesanches]

I've just read my own message and noticed that the way I said it may have sounded a bit harsh. @tiroj, I'd like to clarify that we are grateful to hear your input and we're taking them into consideration in order to improve fontbakery.

Since we still have issues with this check, I decided to at least temporarily downgrade it to WARN-level.

I believe that at some point in the future the googlefonts profile should bring this check back to FAIL-level, but only after we figure out how to better inform the users on how to fix the problems reported, as well as making sure that fontmake has proper support for using the info form the project source files when building font files.

[tiroj]

Understood.

Since we have some projects that don’t use fontmake for OTL, this will also give me some time to figure out if there is a way to add SS and CV feature descriptive strings to output from VOLT projects or other tool chains. I can imagine a few more or less complicated manual procedures, and some longer term options in terms of new tooling.

[felipesanches]

The check is now WARN-level and we've got a new FontBakery release including it: https://pypi.org/project/fontbakery/0.7.37/

[davelab6]

That sounds good, thanks @RosaWagner , @vv-monsalve , @moyogo , @felipesanches , @tiroj for looking ino this.

[felipesanches]

OK, here are the next steps:

• document how descriptions are set in the major font editors
• add that info to the check rationale
• ensure fontmake is able to build source files that include these stylistic set description strings
• review the comments in this thread to make sure we address any concerns about this check brought up here
• only then, upgrade the check to a FAIL

[tiroj]

ensure fontmake is able to build source files that include these stylistic set description strings

It would be great if there were a couple of options in this respect: to be able to get description strings from AFDKO .fea syntax, and create the featureParams as part of the OTL compilation, but also to have a mechanism to add featureParams entries to precompiled GSUB and name tables.

[bobh0303]

a mechanism to add featureParams entries to precompiled GSUB and name tables.

SIL's FontUtils font-hacking suite of tools has ttffeatparms which can do what you want. We've used it for both VOLT- and fontTools-compiled OT font files.

FontUtils has been around a while and we're not actively enhancing it very much these days, but we're still using it in our workflow.

[bobh0303]

• ensure fontmake is able to build source files that include these stylistic set description strings

Can't tell from this thread whether you all know this or not, but fontTools is able to compile Adobe's Stylistic Set and Character Variant UI strings syntax into TTFs -- we're doing that in our workflow.

[davelab6]

Thanks @bobh0303 this is all super helpful to know! :)

[tiroj]

Can't tell from this thread whether you all know this or not, but fontTools is able to compile Adobe's Stylistic Set and Character Variant UI strings syntax into TTFs -- we're doing that in our workflow.

Have you any experience using Adobe’s syntax just to add SS and CV name strings to already compiled GSUB tables using fontTools? My assumption was that any .fea code in the pipeline would overwrite the entire GSUB table, meaning that you either use .fea for all the OTL programming or none of it. It would be handy indeed if there were an additive option.

[bobh0303]

Have you any experience using Adobe’s syntax just to add SS and CV name strings to already compiled GSUB tables using fontTools? My assumption was that any .fea code in the pipeline would overwrite the entire GSUB table, meaning that you either use .fea for all the OTL programming or none of it. It would be handy indeed if there were an additive option.

I do not have any such experience and, like you, suspect any .fea code in the pipeline would overwrite the entire GSUB (and GPOS and GDEF, for that matter) subtable(s).

I think a general solution to "additive" (or one might call it, "incremental") compilation of OT subtables is going to be hard. However the more limited task of taking a subset of fea -- namely just otherwise-empty feature blocks containing some featureParam records -- parsing it and adding the results to existing GSUB and name tables would likely be a relatively straight forward programming task for someone competent in the innards of fontTools.