Support bracket layers in Glyphs

[robmck-ms]

Bracket layers in Glyphs are a very convenient mechanism for drawing alternates for glyphs. It would be very helpful if fontmake supported Glyphs' bracket layers, storing the layers as additional glyphs in the glyf table, and generating the necessary rvrn feature and Feature Variations code in GSUB.

This could be implemented using Rules in the .designspace file. Fontmake would just generate the rules append the alternate glyphs to the glyf table. Fonttools.varLIb could consume it all and generate the FeatureVariations code. This would also free us up from depending on feature file syntax.

[robmck-ms]

Bonus: I would love it if fontmake put all the alternates glyphs at the end of the glyf table. This means that if we add an alternate in a later version, the alternate would go at the end, and the glyph order of the previously released glyphs would be preserved (so that VTT sources continue to work).

[robmck-ms]

Some context: currently my workaround is to manually duplicate the alternate glyphs, hand-code the rvrn feature, extra lookup, and FeatureVariations code, then use ttx to overwrite the GSUB table. It also means I need to re-merge GSUB anytime something else in GSUB changes. This makes for a bit of a tedious workflow.

[weiweihuanghuang]

I'm having this issue at the moment as well but I don't understand how to do this for brace trick, I have for example this scenario:

2 masters, light and bold, i need to add a regular in the middle, i tried to extrapolate the end masters to and have them switch between at the 'regular' breakpoint but the intermediate instances aren't correct anymore
(in reality i have 3 masters, and sometimes have 2 intermediate masters due to extreme contrast change over a large weight range)

Do you have any ideas?

[davelab6]

This is becoming a critical blocker for Google Fonts weight upgrades :)

[mjlagattuta]

Until it is supported in fontmake I have workarounds for both brace and bracket layers at the moment and have been getting decent results.

Here is the script I use for fixing brackets:
https://gist.github.com/mjlagattuta/2bf902fe218ed2e82f82c3b919fbfa12
I plan on cleaning it up, at the moment it is very messy at the moment, but it works well. It does not support glyphs with a single bracket, but this should not be too difficult to add. It does support combinations of bracket and reverse bracket layers (Useful to keep your master layers true to their final output)

Essentially the process is:

• Parse all glyphs with brackets and all glyphs that use a component that uses brackets
• Duplicate those glyphs and add a suffix
• Determine which set of outlines should be the new glyph
• Move layers around accordingly + delete bracket layers
• Scale the bracket values and then normalize but do not map the values
• Write the bracket values to a python file which will use varLib's addFeature Variations
• Now with bash
  • Build the new .glyphs file with fontmake
  • Run the generate python file on the ttf

[madig]

Basic bracket layer support is in glyphsLib master. It uses Designspace's rules element, so it's usable today.

[weiweihuanghuang]

Does that mean bracket layers work without any extra work – i.e. none of the above duplication steps and running extra scripts ?

[madig]

Yes, under a few conditions:

1. You have to use a .designspace file, no it-just-werks until we release a new glyphsLib (or you install git master). Note that fontmaking from a .glyphs file and from a .designspace file may give you different results, use glyphs2ufo --generate-GDEF or something to keep the changes to a minimum. Yes this is hairy and rage-inducing. Working on it.
2. Actually, just pip install git+https://github.com/googlei18n/glyphsLib.git inside a virtual environment and use glyphs2ufo WorkSans.glyphs and inspect the .designspace file. Look for the <rules> segment and note that glyphs2ufo automatically extracts bracket layers to free-standing glyphs. So if you make a separate glyph for the brace layer, e.g. "cent" and "cent.rvrn", you can just write the <rules> element yourself and fontmake and co. will take care of the rest.

Ask if you want me to clarify something, it's close to 1am here and I should be asleep.

[anthrotype]

It should just work as soon as we tag a new glyphsLib release (Nikolaus can you do that?) and then update and merge the pending fontmake PR, and tag new fontmake release. Note that I am travelling this week so it may take a bit.

[madig]

I can but then we have source layers in .designspace files while fontmake can't reliably compile them yet, which will probably lead to anger and misery 😢

I still need to figure out how to change _add_MVAR to accommodate for sparse masters with missing tables...

[madig]

I just found a bug in git master glyphs2ufo that makes WorkSans-Regular.ufo be empty. Joy.

[madig]

fontmake 1.9.1 supports brace and bracket layers automatically.

[weiweihuanghuang]

@madig is it still the same protocol as here #399 (comment) ? I'd love to try it out.

[madig]

Just take e.g. Work Sans and do fontmake -g WorkSans.glyphs -o variable :)

I just realized that this won't work for generating static fonts. There, you need to glyphs2ufo WorkSans.glyphs and look at https://github.com/LettError/ufoProcessor to generate prepared instance UFOs that take source layers into account, then run fontmake on those.

[weiweihuanghuang]

Wow that's great!!! So it uses brace OR bracket layer glyphs and the weight naming right? What should one do in the situation where you have brace glyphs, but the glyph is being swapped out with a custom parameter.

[madig]

It uses brace AND bracket layers. Custom renaming/swapping parameters are currently not supported. What do you mean by weight naming?