Re-implementing rvrn feature

[aaronbell]

Discovered that in the original build script, the rvrn feature was being implemented separately from the general build process. So once the build process switched to UFR, the rvrn feature no longer worked.

To resolve this issue, I've re-integrated the .rvrn glyphs back into the base variants using the standard Glyphs bracket trick, and updated the features to reflect the new export naming convention.

Verified that the feature (as well as titl and tnum) are working once again.

[aaronbell]

@weiweihuanghuang When you have a chance, can you take a look at this?

[weiweihuanghuang]

Hey Aaron I haven't had a chance to look yet but I just saw this issue, do you know anything about this?
#70

[aaronbell]

I don’t. It appears that the actions, here at least, completed successfully.

[bennetfabian]

I don’t. It appears that the actions, here at least, completed successfully.

The last run was a few months ago. When you run it again right now it fails.

[bennetfabian]

This is what running this action now looks like:
https://github.com/bennetfabian/Work-Sans/actions/runs/1604928810

[aaronbell]

Looks like there is an issue with processing a particular glyph layer name:

File "/home/runner/work/Work-Sans/Work-Sans/venv/lib/python3.8/site-packages/ufoLib2/objects/layerSet.py", line 227, in getitem
224
layer_object = self._layers[name]
225
KeyError: '{137}'

It may be that ufoLib2 doesn’t support brace layers. And it may be that the newer version of ufoLib2 has resolved that limitation (which is why upgrading appears to fix things).

Not sure why the issue would crop up on the forked repro and not here, though.

[bennetfabian]

Looks like there is an issue with processing a particular glyph layer name:

File "/home/runner/work/Work-Sans/Work-Sans/venv/lib/python3.8/site-packages/ufoLib2/objects/layerSet.py", line 227, in getitem

224

layer_object = self._layers[name]

225

KeyError: '{137}'

It may be that ufoLib2 doesn’t support brace layers. And it may be that the newer version of ufoLib2 has resolved that limitation (which is why upgrading appears to fix things).

Not sure why the issue would crop up on the forked repro and not here, though.

Well, the GitHub Action always pulls the latest version of all libraries so the Action run from 5 months ago ran with totally different versions as they were the latest back then but not anymore.

Maybe we could change the action's "on" parameter and add workflow_dispatch so it can be ran manually. I bet that it will output the same if we run it in this repo.

[bennetfabian]

Yup, just confirmed that back then on August 6 when the action last ran the latest versions of the packages were:
fontmake==2.4.0
gftools==0.7.4

My common sense suggests that the updates to those packages in the meantime since Aug 6 somehow broke the building process.

Now the question is if we

• just do the comfortable but maybe riskier way of changing the requirements.txt to use the latest version which doesn't fail
• try to fix the sources itself which may be more future-proof if there ever are any updates to the repo again or OpenType specs get changed

What do you guys think? @weiweihuanghuang @aaronbell

[aaronbell]

I would suggest changing the sources. 🙂

[weiweihuanghuang]

Thanks for the rundown. @aaronbell In what way should I change the source?

[bennetfabian]

I can report that Work Sans now builds successfully without any changes. The new updates in the underlying libraries used for font building must have been updated to fix the problem!
Therefore #70 can be closed.