googlefonts / googlefonts/glyphsLib
Support brace and bracket layers
- Dominant language
- Python
- Stars
- 201
- Forks
- 56
- Avg merge
- 17m
- Merged PRs (30d)
- 1
Description
Thanks to Behdad's recent efforts on sparse masters, we could now support brace layers. This is probably an issue for multiple layers of the stack. I'll start here because glyphsLib needs to output something. I think this ties into https://github.com/fonttools/fonttools/issues/1308.
designspaceLib supports substitution rules (https://github.com/fonttools/fonttools/blob/master/Lib/fontTools/designspaceLib/__init__.py#L140) to support bracket layers. How should brace layers/sparse masters be supported? For every brace layer, make a new source entry with the appropriate location and set `layerName` to the name of the brace layer? If e.g. there was a brace layer for `e` named `Medium {465 100}` in `MyFont_Th.ufo`:
```XML
```
What already works is using a complete UFO (without feature file) as a sparse master, as I wrote here: https://github.com/googlei18n/fontmake/issues/477#issuecomment-440303283.
There's an example declaration for bracket layers at https://github.com/fonttools/fonttools/blob/master/Lib/fontTools/designspaceLib/__init__.py#L141. Will have to understand those better before including them in the example here.
Contributor guide
Research direction
Start by reading glyphsLib's Glyphs-to-UFO output path and the substitution-rule example in fontTools/designspaceLib/__init__.py, then compare the sparse-master discussion in fontmake issue 477 with fonttools issue 1308. Done means defining and implementing a supported representation for brace layers or sparse masters, including the designspace source entries illustrated in this issue.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- tooling
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100