Big Shoulders Stencil Display: Version 2.000 added

[vv-monsalve]

153c0bc: [gftools-packager] Big Shoulders Stencil Display: Version 2.000 added

• Big Shoulders Stencil Display Version 2.000 taken from the upstream repo https://github.com/xotypeco/big_shoulders at commit xotypeco/big_shoulders@41153e6.

7a1bd23: [gftools-packager] ofl/bigshouldersstencildisplay remove METADATA "source". #2587

[vv-monsalve]

This PR upgrades Big Shoulders Stencil Display into a Variable Font.
OFL.txt and Description files were added in #3432

[thlinard]

Hi @vv-monsalve

The API will deliver an Extra-Light static file for which the VF doesn't have a corresponding instance.

@RosaWagner has already done a PR to fix a similar problem (googlefonts/rubik#38 to fix #3214, see also #3411): you might as well correct it before release.

[thlinard]

Same remark for PR #3438 #3437 #3435 #3434 #3433 #3432

[RosaWagner]

@thlinard I don't know if the missing ExtraLight is intended or not, but sometimes designers don't want to include them. Although it would be nice to have perfect consistency between the STAT and what the API does, and even if we should try to do so as much as possible, it is not always possible and we try to find the best compromise with the designers upstream. If I fixed it before, it was because it could be done for that situation.

[thlinard]

@thlinard I don't know if the missing ExtraLight is intended or not, but sometimes designers don't want to include them. Although it would be nice to have perfect consistency between the STAT and what the API does, and even if we should try to do so as much as possible, it is not always possible and we try to find the best compromise with the designers upstream. If I fixed it before, it was because it could be done for that situation.

Hi @RosaWagner

Whether the designer approves it or not, there will be an ExtraLight weight, because

When a variable font is onboarded to Google Fonts, we will provide instantiated static fonts for legacy applications. Thus, bear in mind Google’s API will automatically create all the 100x weights along the used range of the axis when producing static fonts, whether or not they are included in the designer's original design space.
https://github.com/googlefonts/gf-docs/tree/main/Spec#stat-table

The purpose of this PR is to provide "variable fonts containing a wght axis, that 1:1 matches the prior static releases" (#3433): this is a good goal, but in fact this PR, by wanting to achieve this goal, is going to make it fail (because of what the API is doing with VFs, which will give new statics, including an extra weight, ExtraLight). You would better meet the spirit of this goal by providing VFs whose instances 1:1 match the statics provided after release.

I believed for a while that the VF format would appear as more modern and offering more possibilities, but I realized that this is not always the case when my users started complaining about VFs and asking me for statics, to have more weights: please, don't release VFs that have fewer instances than the number of static weights! This will only make the VF appear as a crippled format.

[vv-monsalve]

Hello @thlinard. We appreciate your interest in the fonts we serve. Just as all the questions and requests submitted by users, we take notes on the comments received. We evaluate them and eventually will include them in our workflow as we advance with the improvements of our process and tools. However, the priority evaluation and the way and the time in which, if necessary, we address them depends on a series of internal factors to coordinate. Therefore it is not immediate and will depend on the Google Fonts Team.

Finally, bear in mind that this is a Libre Fonts platform, where we receive many contributions from many sources and motivations. We are not and will not always be in the position of demanding particularities or changes to designers who already completed a huge amount of work.

[thlinard]

Hi @vv-monsalve
I'm well aware of this (maybe you've noticed that I'm not quite a new one here: two months ago, @davelab6 wrote to me to praise my assessments, which I am grateful to him, because I try to help).

I presume we agree that when this PR is pushed to production, users will download an ExtraLight static font, whether its creator objects or not. And I think that will be a problem. The fix I'm suggesting is easy: one line in the Python font script + recompiling, to avoid a lot of trouble down the road.

Edit: I took a closer look at the sources, there will be more than one line to change, but there is no master to create, it's just interpolation anyway.

[davelab6]

when this PR is pushed to production, users will download an ExtraLight static font, whether its creator objects or not. And I think that will be a problem. The fix I'm suggesting is easy: one line in the Python font script + recompiling, to avoid a lot of trouble down the road.

I agree, but I also want to see progress on getting this update out, and despite that it looks like a quick script change and recompile, there's a lot of additional stakeholders and distribution points to keep appraised and in sync for this particular project which make that prohibitive.

So what I'd like to see is

• @vv-monsalve merges and pushes this PR to production now
• @vv-monsalve files a bug upstream to address this STAT issue
• @vv-monsalve makes sure that the next time we PR this family, this improvement is made
• @vv-monsalve updates the Spec with PRs to include new guidance about avoiding "thinly spread" ranges such that the intermediates are not different enough, and avoid 'gaps' in the ranges; if the designer is thinking of gaps, that probably means they should reduce the range

[davelab6]

WHOOPS lol

[thlinard]

Thank you Dave!

[vv-monsalve]

Updated

Big Shoulders Stencil Display: Version 2.000 added

---

55877c0: [gftools-packager] Big Shoulders Stencil Display: Version 2.000 added

• Big Shoulders Stencil Display Version 2.000 taken from the upstream repo https://github.com/xotypeco/big_shoulders at commit xotypeco/big_shoulders@41153e6.

8c09744: [gftools-packager] ofl/bigshouldersstencildisplay remove METADATA "source". #2587

[vv-monsalve]

• @vv-monsalve merges and pushes this PR to production now

@davelab6 I've spotted a new issue about the weight value in the metadata. It was included as 400 despite the default is the Thin. Correcting myself here, I just found the source of reference and this is ok.

I'll have to inspect this in detail as the current build schema for this project is from one year ago when we were following an entirely different workflow. I will take this as an opportunity to give gftools builder approach a trial for this project. So, despite what we agreed on the call, I'm turning this PR into a draft for now. I still would like to give builder a trial.

On the other hand, I already reported the requisition of the ExtraLight weight to the Designer. Perhaps we could include it while switching to Builder.

[davelab6]

Perhaps we could include [the new 200 style] while switching to Builder.

I believe we've agreed to do that with him :)

Generally, I think switching to the builder is a good idea, especially for projects like this where we expect more updates from the designer in the future, and as the builder itself improves, that will propagate to the project and help keep it conformant with our requirements.

[vv-monsalve]

I believe we've agreed to do that with him :)

We have now, this comment was done the same day I wrote him about that :)

Generally, I think switching to the builder is a good idea, especially for projects like this where we expect more updates from the designer in the future, and as the builder itself improves, that will propagate to the project and help keep it conformant with our requirements.

Agree, this was my reasoning to turn this as an opportunity to switch to the builder approach.

[vv-monsalve]

Updated

Big Shoulders Stencil Display: Version 2.001 added

---

f8ce3f7: [gftools-packager] Big Shoulders Stencil Display: Version 2.001 added

• Big Shoulders Stencil Display Version 2.001 taken from the upstream repo https://github.com/xotypeco/big_shoulders at commit xotypeco/big_shoulders@c32776c.

e3f4866: [gftools-packager] ofl/bigshouldersstencildisplay remove METADATA "source". #2587

[vv-monsalve]

The font includes now the ExtraLight Instance.

[vv-monsalve]

Updated

Big Shoulders Stencil Display: Version 2.001 added

---

3185d42: [gftools-packager] Big Shoulders Stencil Display: Version 2.001 added

• Big Shoulders Stencil Display Version 2.001 taken from the upstream repo https://github.com/xotypeco/big_shoulders at commit xotypeco/big_shoulders@2f924dd.

6c5f261: [gftools-packager] ofl/bigshouldersstencildisplay remove METADATA "source". #2587

[vv-monsalve]

The PR was updated to solve STAT table (with no opsz axis) as mentioned in #3434

[gf-bot]

Fontbakery report

Fontbakery version: 0.8.2

[8] BigShouldersStencilDisplay[wght].ttf

⚠ WARN: Are there caret positions declared for every ligature?

• com.google.fonts/check/ligature_carets

--- Rationale ---
All ligatures in a font must have corresponding caret (text cursor) positions
defined in the GDEF table, otherwhise, users may experience issues with caret
rendering.
If using GlyphsApp or UFOs, ligature carets can be defined as anchors with names
starting with 'caret_'. These can be compiled with fontmake as of version
v2.4.0.

• ⚠ WARN This font lacks caret position values for ligature glyphs on its GDEF table. [code: lacks-caret-pos]

⚠ WARN: Is there kerning info for non-ligated sequences?

• com.google.fonts/check/kerning_for_non_ligated_sequences

--- Rationale ---
Fonts with ligatures should have kerning on the corresponding non-ligated
sequences for text where ligatures aren't used (eg
https://github.com/impallari/Raleway/issues/14).

• ⚠ WARN GPOS table lacks kerning info for the following non-ligated sequences:

  • f + f
  • f + i
  • i + f
  • f + l
  • l + f
  • i + l

  [code: lacks-kern-info]

⚠ WARN: Combined length of family and style must not exceed 27 characters.

• com.google.fonts/check/name/family_and_style_max_length

--- Rationale ---
According to a GlyphsApp tutorial [1], in order to make sure all versions of
Windows recognize it as a valid font file, we must make sure that the
concatenated length of the familyname (NameID.FONT_FAMILY_NAME) and style
(NameID.FONT_SUBFAMILY_NAME) strings in the name table do not exceed 20
characters.
After discussing the problem in more detail at `FontBakery issue #2179 [2] we
decided that allowing up to 27 chars would still be on the safe side, though.
[1] https://glyphsapp.com/tutorials/multiple-masters-part-3-setting-up-instances
[2] https://github.com/googlefonts/fontbakery/issues/2179

• ⚠ WARN The combined length of family and style exceeds 27 chars in the following 'WINDOWS' entries:
  FONT_FAMILY_NAME = 'Big Shoulders Stencil Display Thin' / SUBFAMILY_NAME = 'Regular'

Please take a look at the conversation at fonttools/fontbakery#2179 in order to understand the reasoning behind these name table records max-length criteria. [code: too-long]

⚠ WARN: A static fonts directory with at least two fonts must accompany variable fonts

• com.google.fonts/check/repo/vf_has_static_fonts

--- Rationale ---
Variable font family directories kept in the google/fonts git repo may include a
static/ subdir containing static fonts.
These files are meant to be served for users that still lack support for
variable fonts in their web browsers.

• ⚠ WARN Please consider adding a subdirectory called "static/" and including in it static font files. [code: missing]

⚠ WARN: Ensure Stylistic Sets have description.

• com.google.fonts/check/stylisticset_description

--- Rationale ---
Stylistic sets should 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.

• ⚠ WARN The stylistic set ss01 lacks a description string on the 'name' table. [code: missing-description]

⚠ WARN: Ensure fonts have ScriptLangTags declared on the 'meta' table.

• com.google.fonts/check/meta/script_lang_tags

--- Rationale ---
The OpenType 'meta' table originated at Apple. Microsoft added it to OT with
just two DataMap records:
- dlng: comma-separated ScriptLangTags that indicate which scripts, or languages
and scripts, with possible variants, the font is designed for
- slng: comma-separated ScriptLangTags that indicate which scripts, or languages
and scripts, with possible variants, the font supports
The slng structure is intended to describe which languages and scripts the font
overall supports. For example, a Traditional Chinese font that also contains
Latin characters, can indicate Hant,Latn, showing that it supports Hant, the
Traditional Chinese variant of the Hani script, and it also supports the Latn
script
The dlng structure is far more interesting. A font may contain various glyphs,
but only a particular subset of the glyphs may be truly "leading" in the design,
while other glyphs may have been included for technical reasons. Such a
Traditional Chinese font could only list Hant there, showing that it’s designed
for Traditional Chinese, but the font would omit Latn, because the developers
don’t think the font is really recommended for purely Latin-script use.
The tags used in the structures can comprise just script, or also language and
script. For example, if a font has Bulgarian Cyrillic alternates in the locl
feature for the cyrl BGR OT languagesystem, it could also indicate in dlng
explicitly that it supports bul-Cyrl. (Note that the scripts and languages in
meta use the ISO language and script codes, not the OpenType ones).
This check ensures that the font has the meta table containing the slng and dlng
structures.
All families in the Google Fonts collection should contain the 'meta' table.
Windows 10 already uses it when deciding on which fonts to fall back to. The
Google Fonts API and also other environments could use the data for smarter
filtering. Most importantly, those entries should be added to the Noto fonts.
In the font making process, some environments store this data in external files
already. But the meta table provides a convenient way to store this inside the
font file, so some tools may add the data, and unrelated tools may read this
data. This makes the solution much more portable and universal.

• ⚠ WARN This font file does not have a 'meta' table. [code: lacks-meta-table]

⚠ WARN: Does the font have a DSIG table?

• com.google.fonts/check/dsig

--- Rationale ---
Microsoft Office 2013 and below products expect fonts to have a digital
signature declared in a DSIG table in order to implement OpenType features. The
EOL date for Microsoft Office 2013 products is 4/11/2023. This issue does not
impact Microsoft Office 2016 and above products.
As we approach the EOL date, it is now considered better to completely remove
the table.
But if you still want your font to support OpenType features on Office 2013,
then you may find it handy to add a fake signature on a dummy DSIG table by
running one of the helper scripts provided at
https://github.com/googlefonts/gftools
Reference: https://github.com/googlefonts/fontbakery/issues/1845

• ⚠ WARN This font has a digital signature (DSIG table) which is only required - even if only a dummy placeholder - on old programs like MS Office 2013 in order to work properly.
  The current recommendation is to completely remove the DSIG table. [code: found-DSIG]

⚠ WARN: Are there any misaligned on-curve points?

• [com.google.fonts/check/outline_alignment_miss](https://font-bakery.readthedocs.io/en/latest/fontbakery/profiles/<Section: Outline Correctness Checks>.html#com.google.fonts/check/outline_alignment_miss)

--- Rationale ---
This check heuristically looks for on-curve points which are close to, but do
not sit on, significant boundary coordinates. For example, a point which has a
Y-coordinate of 1 or -1 might be a misplaced baseline point. As well as the
baseline, here we also check for points near the x-height (but only for lower
case Latin letters), cap-height, ascender and descender Y coordinates.
Not all such misaligned curve points are a mistake, and sometimes the design may
call for points in locations near the boundaries. As this check is liable to
generate significant numbers of false positives, it will pass if there are more
than 100 reported misalignments.

• ⚠ WARN The following glyphs have on-curve points which have potentially incorrect y coordinates:
  • percent (U+0025): X=515.0,Y=1.0 (should be at baseline 0?)
  • percent (U+0025): X=269.0,Y=1598.0 (should be at cap-height 1600?)
  • g (U+0067): X=109.0,Y=2.0 (should be at baseline 0?)
  • g (U+0067): X=424.5,Y=2.0 (should be at baseline 0?)
  • registered (U+00AE): X=163.5,Y=1600.5 (should be at cap-height 1600?)
  • registered (U+00AE): X=527.5,Y=1600.5 (should be at cap-height 1600?)
  • uni00B2 (U+00B2): X=213.0,Y=1602.0 (should be at cap-height 1600?)
  • uni00B2 (U+00B2): X=133.0,Y=1601.0 (should be at cap-height 1600?)
  • uni00B5 (U+00B5): X=205.0,Y=-0.5 (should be at baseline 0?)
  • questiondown (U+00BF): X=430.5,Y=2.0 (should be at baseline 0?) and 78 more. [code: found-misalignments]

Summary

💔 ERROR	🔥 FAIL	⚠ WARN	💤 SKIP	ℹ INFO	🍞 PASS	🔎 DEBUG
0	0	8	49	10	151	0
0%	0%	4%	22%	5%	69%	0%

Note: The following loglevels were omitted in this report:

• SKIP
• INFO
• PASS
• DEBUG