Fontforge: Exporting UFO from FiraCode Variable TTF Corrupts features

[FredHappyface]

• Provide a general summary of the issue in the Title above.
• Before you open an issue, please check if a similar issue already exists or has been closed before.

Important

Mark with [x] to select. Leave as [ ] to unselect.

When reporting a bug/issue:

• [x] Screenshot
• [x] The FontForge version and the operating system you're using
• [x] The behavior you expect to see, and the actual behavior
• [x] Steps to reproduce the behavior
• [ ] (optional) Possible solution/fix/workaround

When you open an issue for a change/improvement/feature request:

• [ ] A description of the problem you're trying to solve, including _why_ you think this is a problem
• [ ] If the feature changes current behavior, reasons why your solution is better
• [ ] (optional) Possible solution/fix/workaround

Version

FontForge 20200314 as available https://ci.appveyor.com/project/fontforge/fontforge/build/artifacts
Windows 10 1909

Description

Converting FiraCode Variable TTF to UFO and importing causes errors in FontForge and other projects such as fontmake

Steps are as follows:

1. Open the firacode.ttf into fontforge
2. Generate a ufo font family
3. Import the ufo font back into fontforge

The error message

The error popup is as follows

And the warnings dialog

After dismissing the error, the font renders perfectly fine

Files

https://github.com/tonsky/FiraCode/blob/5cfaa1eacf6796632b24c593f4d30a48f8d3c2dc/distr/variable_ttf/FiraCode-VF.ttf

Thanks for your time 😄

[FredHappyface]

FiraCode-Light.ufo.zip

Here is the ufo file for reference

[ctrlcctrlv]

Confirmed.

@FredHappyface I will caution you, FontForge's support for variable fonts is very outdated. I do not think that multiple masters export to UFO at all. So, probably, we aren't the best tool for this—_right now, at least_! Better support is planned, but won't be anytime "soon". Maybe 2021.

However, this specific issue seems not a symptom of that, but rather FontForge creating corrupt lookups in the UFO which contravene FEA standard §4.d.

Specifically, we are generating lookupflag; lines, with no integer, or anything. E.g., from @FredHappyface's file:

lookup mkmkMarktoMarklookup2 {
  lookupflag;
  markClass [\uni0326 ] <anchor 599 0> @Anchor2;
  markClass [\uni0327 ] <anchor 600 0> @Anchor2;
  markClass [\uni0345 ] <anchor 470 0> @Anchor2;
  pos mark [\uni0345 ] <anchor 618 -368> mark @Anchor2;
} mkmkMarktoMarklookup2;

The standard does not allow for this. Seems we're hitting featurefile.c line 1368 (fprintf( out, " lookupflag" );) then skipping the loop and failing the two branches, so dropping right to 1386 (putc(';',out)).

Not sure what's causing this yet: otl->lookup_flags seems to contain either junk, or something we wrongly think is junk. We always write it, usually with 0, so something is up here. Indeed, it's possible that the OT folks have added something new. More research needed. 🛠️

[FredHappyface]

Hi thanks for the quick reply,

I've been following the instructions here:

https://github.com/fontforge/fontforge/issues/2882#issuecomment-523852365

My end goal is to create a nerd font with variable weights. So this was a proof of concept

Looking very forward to having variable fonts in FontForge (2021 would be awesome 😄 )

Thanks again for looking at this, and for an invaluable resource

[ctrlcctrlv]

Ah-ha! So that's why your font has "VF" in the title. Always funny when someone quotes my own work back at me. I'm glad that my tutorial has helped, in some small way. I'll figure out this bug some time this week, hopefully, if someone else doesn't get to it!

[FredHappyface]

Yeah it was really useful! Wouldn't have had the foggiest without it.

If I bin the features.fea everything aside from the ligatures work pretty well.