New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Upgrade stylistic sets description check to FAIL #3155
Comments
Ensure Stylistic Sets have description. Stylistic sets must provide description text. Programs such as InDesign, TextEdit and Inkscape use that info to display to the users so that they know what a given stylistic set offers. (issue fonttools#3155)
Ensure Stylistic Sets have description. Stylistic sets must provide description text. Programs such as InDesign, TextEdit and Inkscape use that info to display to the users so that they know what a given stylistic set offers. (issue fonttools#3155)
Ensure Stylistic Sets have description. Stylistic sets must provide description text. Programs such as InDesign, TextEdit and Inkscape use that info to display to the users so that they know what a given stylistic set offers. (issue fonttools#3155)
Ensure Stylistic Sets have description. Stylistic sets must provide description text. Programs such as InDesign, TextEdit and Inkscape use that info to display to the users so that they know what a given stylistic set offers. (issue #3155)
I just discovered this check. Why "must"?
|
Agree with Rosalie on this one. Should be downgraded to a WARN imo. |
Agree, this should have only a WARN loglevel status. |
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 |
@twardoch also recommended to develop common recommendations for typical stylistic sets |
@vv-monsalve also noted a bug in the check that only |
@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? |
Are named stylistics sets even implemented in fontmake? |
@moyogo do you know? |
For the glyphapp thing, there are problems when you use glyphs 2 and glyphs 3. It is not handled the same way. |
At the end of this tutorial |
Fontmake can take the FEA featureNames syntax:
There's a PR (googlefonts/glyphsLib#615) to translate the Glyphsapp feature notes to FEA syntax but that it needs more work. |
So I confirm, using glyphs 3 format 2, stylistic sets' names don't get exported. |
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. |
This check (com.google.fonts/check/stylisticset_description) is currently included in the vendor-specific 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 |
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 I believe that at some point in the future the |
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. |
OK, here are the next steps:
|
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. |
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. |
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. |
Thanks @bobh0303 this is all super helpful to know! :) |
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. |
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.
The text was updated successfully, but these errors were encountered: