Update Big Shoulders from v1.0 to v1.1

[xotypeco]

https://github.com/xotypeco/big_shoulders

this updates Big Shoulders from 1.0 to 1.1, and adds Big Shoulders Inline and Big Shoulders Stencil

some notes from fontbakery results

1. in Big Shoulders Inline: fail because the UPM is set to 4000. this is a detailed typeface with several outlines per glyph, so 4000 was the smallest grid I could use. 2048 was pointed out as largest allowed grid.

2. in Big Shoulders Inline and Stencil: fail from a lack of HVAR; not sure how to add that.

3. In Big Shoulders, Inline & Stencil: fail from wght axis saying coordinates aren't multiples of 100. it's looking at the axis coordinate rather than each instance's defined style name and weight (all of which are actually multiples of 100). wasn't sure what I should do (if anything) to fix.

and I think that's all I'm lacking.

[davelab6]

in Big Shoulders Inline: fail because the UPM is set to 4000. this is a detailed typeface with several outlines per glyph, so 4000 was the smallest grid I could use. 2048 was pointed out as largest allowed grid.

That check result need to be improved further; I filed fonttools/fontbakery#2827 (comment) to address this, and you can ignore it for now.

in Big Shoulders Inline and Stencil: fail from a lack of HVAR; not sure how to add that.

@m4rc1e please add instructions on how to resolve this to the FB check result text and let @xotypeco know here :)

In Big Shoulders, Inline & Stencil: fail from wght axis saying coordinates aren't multiples of 100. it's looking at the axis coordinate rather than each instance's defined style name and weight (all of which are actually multiples of 100). wasn't sure what I should do (if anything) to fix.

Please post the exact FB result on your repo as an issue, so we can investigate it there :)

[xotypeco]

thanks @davelab. didn’t see that comment on FB, the increased UPM worried me since Big Shoulders Inline is such a weird edge case. will post fb results on the repo.

[m4rc1e]

in Big Shoulders Inline and Stencil: fail from a lack of HVAR; not sure how to add that.

In Big Shoulders, Inline & Stencil: fail from wght axis saying coordinates aren't multiples of 100.

Please don't generate the fonts using glyphsapp. Use fontmake and you'll get the HVAR and avar tables.

I've been writing some documentation which should clear some of these issues.

[xotypeco]

fontmake still pukes on the brace layers. to verify: is that an expected result?

you & @yanone worked around that with a script he'd made, back in the fall, but I thought I remembered it was to be a nonissue by now.

if the failure is an expected result I’ll just grab his script and proceed per your notes from back then.

[laerm0]

There's a script to fix brace layers? Huh. Didn't know that. I've just been doing them in a .designspace like so:

   <rules>
    <rule name="bracket_redo">
      <condition minimum="330" name="Weight" />
        <sub name="e" with="e.330"/>
    </rule>
  </rules>

This would swap the e with e.bold at weights greater than 330 (and that's not user weight space, that's design weight space, in case your stem weights aren't at the even 400 Regular/500 Medium/etc weight break points).

This goes in after the </instances> stuff is closed. If you need to switch to .designspace for doing bracket weight swaps, PK, lemme know and I'll chip in. AFAIK, the reason bracket glyphs don't work in fontmake is because bracket layers are a Glyphs innovation and not a TTF standard thing.

@m4rc1e @yanone Is that script an update of the one @mjlagattuta wrote in 2018?

[yanone]

These are the scripts that I wrote: https://github.com/yanone/Yanone-GlyphsApp-Scripts

[xotypeco]

perf. thanks much; I had completely forgotten about the flattening step. in what order do they need to be applied?

[xotypeco]

I have all these files generating correctly; a few questions for @m4rc1e, @yanone and possibly @davelab6 before re-committing finals. mostly about outputting as variable.

1. what stood in the way of hosting variable Big Shoulders on Google Fonts in its initial release? there's not one there, despite the project being specifically made for that purpose.

2. I want to upload these font files with statics named "Big Shoulders Text" and "Big Shoulders Display" as we did before, but in the variable output, I'm going to name it "Big Shoulders" with instances beginning with "Text" amd "Display" and then the weight name after that. this is so things show up more sensibly in font menus.

let me know if there are any objections to 2).

[m4rc1e]

1. what stood in the way of hosting variable Big Shoulders on Google Fonts in its initial release?

Time. It takes longer to produce a VF which conforms to our spec. We also didn't support variable fonts with multiple axes when we released v1 of the family.

2. I want to upload these font files with statics named "Big Shoulders Text" and "Big Shoulders Display" as we did before, but in the variable output, I'm going to name it "Big Shoulders" with instances beginning with "Text" amd "Display" and then the weight name after that. this is so things show up more sensibly in font menus.

For VFs with an "opsz" axis, we expect the instance names to use point sizes e.g

32pt Bold Italic or 12pt Regular

https://github.com/googlefonts/gf-docs/tree/master/Spec#instances

Once we have a single VF with the correct instance names, we'll hide the v1 family and upload the VF as a new family (it should simply be called "Big Shoulders"). The users still using v1 won't be disrupted since we'll still be serving the fonts. It just means new users will use the VF family instead since v1 isn't visible in the catalogue.

[xotypeco]

thanks @m4rc1e I had forgotten.

making sure I’ve got this right:

in the case of Big Shoulders, since it's 2 axes, you'd have a single VF where names would be

10pt Thin, 72pt Thin
10pt Light, 72pt Light
10pt Regular, 72pt Regular

and then statics would remain broken into two families, Text and Display, to correspond with existing statics, e.g.

Big Shoulders Text-Thin, Big Shoulders Display-Thin
Big Shoulders Text-Light, Big Shoulders Display-Light
Big Shoulders Text-Regular, Big Shoulders Display-Regular

yes?

[m4rc1e]

@davelab6 I'm not too sure what we should do in this situation.

We currently have Big Shoulders released as two families, Big Shoulders Text and Big Shoulders Display. If we release a VF which contains an opsz axis, we won't need both families anymore. Can we safely deprecate the V1 family and serve v2 as a single family? I'm concerned that we may break existing docs on gsuite.

[xotypeco]

@m4rc1e that'll break everything in all the city government offices and all the city websites, which we can't do right now. the web and social is basically running the city's COVID-19 operations, and that is critically important to the community.

is it a problem to you to make variable family weight names different from statics? changing variables and web-served fonts to different names might be less of a problem than the downloaded statics.

we may need to just pause adding all this until the pandemic blows over, considering how much Big Shoulders is being used as a community voice. I'm going to talk to the city creative director and will post his feedback.

[xotypeco]

city response: just tell us what new files are and we can adjust. but not now.

we need to pause this process until the pandemic calms down, since this will generate a change in files. IT needs to install files on laptops for people without admin access—and most are away from the office right now.

additionally, the communications office is doing a couple new public pieces every day, so we can't disrupt their workflow.

so. @davelab6, please add your opinion about filenames, especially human-understandable weight schema. the more clearly understandable this is to the average citizen who isn't a designer, the better.

(edit: human-readable schema is my concern only for downloadable ttfs. sorry to be unclear there.)

[xotypeco]

@m4rc1e @davelab6 I’ve added revised vfs and ttfs per the above conversation. I named statics with human-readable names so they don't break for city employees replacing their existing files.

fontbakery reports are attached to the 1.1 files

the only fails are

1. pertaining to the weights of the fonts, complaining that they're not at 100-unit increments, but it's looking at the interpolation values. each instance has a weightClass set to 100-unit increments

2. complaining that Thin is set to 100 instead of 250, but I left that at 100 per @m4rc1e's work last round.

edit: the city's creative department says it'll only take an hour or so to update all sites to variable versions of the fonts, so we're no longer worried about that, and all desktop machines are manually updated, so updating static fonts on GF won't disturb anything.

[xotypeco]

these files are all ready to go. fontbakery reports included in the release files.

[davelab6]

It remains undetermined what the process of deprecation of 'sibling' or 'sub' families will be (such as Open Sans Condensed into Open Sans itself, when Open Sans has a Width axis.) Certainly a key principle will be not to break any existing usage; once a font enters the API, it is very unlikely to be removed.

If we release a VF which contains an opsz axis, the 'legacy' sibling families are still useful for places that don't support variable fonts (like Google Docs) and also all the existing integrations.

Until a deprecation/upgrade process is determined, we should generally prefer not to add a lot more such sibling families to the library; so, e.g., we don't want to add the new widths of Open Sans as sibling/sub families.

Big Shoulders is an exception, in that late last year I decided to make the optical size styles available as legacy sibling families, Text and Display. The existing integrations of these families can benefit from the "silent upgrade" that a Weight axis can offer... but, then a visit to https://fonts.google.com/?vfonly will show the set of sibling families, when ideally we would only show the parent family there (eg Open Sans or Big Shoulders only)

The inline and stencil "treatments" have not been developed in the first place as integral parts of the variation design space, but as 3 separate 'sibling' families, where all 3 have the same range of weights and optical sizes as 2 axes:

• Big Shoulders
• Big Shoulders Inline
• Big Shoulders Stencil

Without optical size axis support, that turns into 6 siblings legacy families:

• Big Shoulders Text
• Big Shoulders Text Stencil
• Big Shoulders Text Inline
• Big Shoulders Display
• Big Shoulders Display Stencil
• Big Shoulders Display Inline

If we add the 4 new ones and ship all 6 with a Weight axis only, and then ship 3 new families with Weight and Optical Size axes, we will indeed have 9 families in the API.

The most simple depreciation process is then to de-list the 6 Weight-only families from the fonts.google.com catalog, but keep list them in Google Docs. I'm not sure if there are 2 ACLs, or just 1.

[xotypeco]

The inline and stencil "treatments" have not been developed in the first place as integral parts of the variation design space, but as 3 separate 'sibling' families,

to add: Big Shoulders, Big Shoulders Inline, and Big Shoulders Stencil are organized as three separate families because my testing during development showed that combining them into one family was counterintuitive to ease of use, an important factor in developing a suite of typefaces usable by non-designers. (Big Shoulders is primarily intended to be used by anyone who wants to express themselves as a citizen of Chicago, and is being advertised as such throughout the city.)

advanced users with access to variable fonts didn't think to find all three versions inside a Big Shoulders menu item, and struggled to conceive that all three were the same family, since they are all so visually different. splitting them into three menu items clarified things considerably.

[davelab6]

Thanks for explaining. We can all hope the general state of font picking UX improves such that a single "Big Shoulders" would be easier. Until then, I'm fine with this :)

[vv-monsalve]

Could it be possible to handle all of this with a scalable approach? Otherwise, it would be managing more than one objective and at least one risk factor at the same time.

Step 1. Update the statics font.
This would permit us to test the new fixes performed on the font first, to ensure everything is performing well on key factors like the vertical metrics or scalable font production, and to not break anything since the files would remain the same name (for now) and it would not be needed to change any CSS on the city website.

Step 2. Upgrade Big Shoulders to a variable font.
Here

we'll hide the v1 family and upload the VF as a new family (it should simply be called "Big Shoulders"). The users still using v1 won't be disrupted since we'll still be serving the fonts.

The new Vf family would be listed as a parent family only, with its static companions that would remain eligible to use independently like in any other case already published.

The legacy sibling could be listed on Google Docs to support (? Not entirely sure of this point).

The migration to the instances with new names would be smoother as Step 1. already made certain the compatibility and functioning of the fonts. Now it would be possible to make it trough

"the city's creative department says it'll only take an hour or so to update all sites to variable versions of the fonts"

Variable font only publishing schema:

Big Shoulders
     BigShoulders72pt-Black.ttf
     BigShoulders72pt-Bold.ttf
     BigShoulders72pt-ExtraBold.ttf
     BigShoulders72pt-Light.ttf
     BigShoulders72pt-Medium.ttf
     BigShoulders72pt-Regular.ttf
     BigShoulders72pt-SemiBold.ttf
     BigShoulders72pt-Thin.ttf
     BigShoulders10pt-Black.ttf
     BigShoulders10pt-Bold.ttf
     BigShoulders10pt-ExtraBold.ttf
     BigShoulders10pt-Light.ttf
     BigShoulders10pt-Medium.ttf
     BigShoulders10pt-Regular.ttf
     BigShoulders10pt-SemiBold.ttf
     BigShoulders10pt-Thin.ttf

Step 3. Release Big Shoulders Stencil.
It would follow the same criteria as for Big Shoulders, listed as a sibling family on the catalog. Static fonts would be the same 16 opsz+weight combinations also.

Step 4. Release Big Shoulders Inline
In the same way as Stencil.

In this step by step way we would:

• Prioritize the current users of the font, which would be the non-expert primarily.
• Proceeding in a safer way for the update of the currently used font.
• Minimise to the most the possible impact of the migration.
• To not unnecessarily overcharge the API with 9 families and leave them as 3 siblings Vf

[davelab6]

I see now that my mistake was in approving BOTH Text and Display name particles in the initial release :) Ideally, I would have approved only Big Shoulders and Big Shoulders Display, although perhaps Big Shoulders Text and Big Shoulders might make more sense, but I have a bias for smaller 'text' sizes as default :) It depends which is the 'default' in the opsz VFs. @xotypeco how did you set up the design space? :)

I agree we should break down the process into milestones, to avoid managing more than one objective/risk-factor at the same time. Here is my personal proposal:

Step 1. Update the existing families (statics)

Update Big Shoulders Text and Big Shoulders Display families, with static fonts.

These should be instantiated from the variable fonts to ensure the 2 are as close as possible, to make the jump in future steps small as possible.

Step 2. Release the new families (statics)

Add Big Shoulders Text Stencil, Big Shoulders Display Stencil, Big Shoulders Text Inline and Big Shoulders Display Inline families, with static fonts.

This should follow the same instantiation process as in Step 1.

Step 3. Update with Weight axes

Update Big Shoulders Text Stencil, Big Shoulders Display Stencil, Big Shoulders Text Inline and Big Shoulders Display Inline families with variable fonts containing a wght axis, that 1:1 matches the prior static releases.

Step 4. Release new families with Optical Size axese

Add Big Shoulders, Big Shoulders Stencil, and Big Shoulders Stencil with wght and opsz axes.

This will be some months away, as other families with opsz will be released first and all the inevitable issues resolved.

Step 5. De-list in fonts.google.com

Since there are now 9 families, de-list the 6 with only a wght axis from fonts.google.com.

But, since the opsz styles are not available in GSuite, only de-list 3 (Text, or Display)`in GSuite.

[xotypeco]

but I have a bias for smaller 'text' sizes as default :) It depends which is the 'default' in the opsz VFs. @xotypeco how did you set up the design space? :)

I agree with your bias towards text.

I haven't manually set a default, so it's the first master, meaning Text Thin.

however!

I didn't set a default only because it needs to be a master & not instance, which was impossible in design files. but I'm generating from a file with {300,10} flattened into a master—meaning Text Regular can be a default. (that's my preference.) cool?

also: what's the issue with opsz axis?

[davelab6]

You should not create masters out of instances, it bloats the filesize.

In this case, we just need you to say what you want the opsz default to be in the GF API when it is not specified; you can use any size in your range.

@vv-monsalve said today she thinks she may be able to prepare this within the next 2-3 weeks :) So next steps are to hear what she finds from her analysis of the project :)

[vv-monsalve]

Once defined the list of steps for the release of the project, the first thing needed would be the final version of source files to work from them.

I went back to the files and ran FB checks for the rest of the family (the first assessment was made on BigShouldersText only as a sample of the project). The main Fail is for Vertical Metrics to match across all the Font Families, solving this is a crucial factor for publishing.

The source files must ensure:

• Vertical metrics matching for all the Family (testing there is not clipping issues, e.g. Vietnamese)
• Most common kerning cases are present
• The compatibility between glyphs
• Ideally, the brace layers flattened on the source file

Having the source files I'll restart the QA process, create the build script to automated the production process, go through the remaining issues to solve them, and finally create the needed tables for the variables.

It is still a semi-long way to go. But having solid source files would assure the process ;)

[davelab6]

@vv-monsalve @xotypeco and I discussed this again, and we agreed that in fact the opsz-max ought to be the default since these are primarily display-usage families.

[vv-monsalve]

I see now that my mistake was in approving BOTH Text and Display name particles in the initial release :) Ideally, I would have approved only Big Shoulders and Big Shoulders Display, although perhaps Big Shoulders Text and Big Shoulders might make more sense, but I have a bias for smaller 'text' sizes as default :) It depends which is the 'default' in the opsz VFs. @xotypeco how did you set up the design space? :)

I agree we should break down the process into milestones, to avoid managing more than one objective/risk-factor at the same time. Here is my personal proposal:

Step 1. Update the existing families (statics)

Update Big Shoulders Text and Big Shoulders Display families, with static fonts.

These should be instantiated from the variable fonts to ensure the 2 are as close as possible, to make the jump in future steps small as possible.

Step 2. Release the new families (statics)

Add Big Shoulders Text Stencil, Big Shoulders Display Stencil, Big Shoulders Text Inline and Big Shoulders Display Inline families, with static fonts.

This should follow the same instantiation process as in Step 1.

Step 3. Update with Weight axes

Update Big Shoulders Text Stencil, Big Shoulders Display Stencil, Big Shoulders Text Inline and Big Shoulders Display Inline families with variable fonts containing a wght axis, that 1:1 matches the prior static releases.

Step 4. Release new families with Optical Size axese

Add Big Shoulders, Big Shoulders Stencil, and Big Shoulders Stencil with wght and opsz axes.

This will be some months away, as other families with opsz will be released first and all the inevitable issues resolved.

Step 5. De-list in fonts.google.com

Since there are now 9 families, de-list the 6 with only a wght axis from fonts.google.com.

But, since the opsz styles are not available in GSuite, only de-list 3 (Text, or Display)`in GSuite.

A lot has changed regarding the opsz access since our original releasing plan, so I would like to confirm if we would stick to it for the releases before starting the PR process.
All three families are ready to go onboard now

[xotypeco]

Display Regular should probably be variable origin.

[xotypeco]

sorry, Display Light should probably be the variable origin. (that master was called Regular at one point and I keep forgetting it's not any more.)

[davelab6]

Sounds good to me. @vv-monsalve all ok?

[vv-monsalve]

Ok. I'll change the default to Light.

[davelab6]

@xotypeco Viviana and Marc have taken a look today, and there is a problem with glyphsLib which makes changing the default a very costly change, so we can't do it.

[vv-monsalve]

Step 2. Release the new families (statics)
Add Big Shoulders Text Stencil, Big Shoulders Display Stencil, Big Shoulders Text Inline and Big Shoulders Display Inline families, with static fonts.

I'll proceed with the PRs of this step.

[xotypeco]

@davelab6 keeping default on Big Shoulders as it currently stands will be fine, I’m not terribly invested in that detail. thanks for update.

…

On Oct 9, 2020, at 11:02 AM, Viviana Monsalve ***@***.***> wrote:  Step 2. Release the new families (statics) Add Big Shoulders Text Stencil, Big Shoulders Display Stencil, Big Shoulders Text Inline and Big Shoulders Display Inline families, with static fonts. I'll proceed with the PRs of this step. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[vv-monsalve]

Continued in #3433