I am facing issues with the structure of the OpenType feature code when exporting to UFOs. My Glyphs source contains instance-specific GPOS (contextual kerning) which needs to replace the dist feature. I’m using the Replace Feature parameter to do so and it works fine when I export binaries directly from glyphs however, the features.fea file contained within the UFO package retains the original contents of the dist feature (i.e. the code for the Regular weight is applied to all masters). Additionally, the UFO does not contain the standard dist feature information (generated automatically by Glyphs when producing Indic fonts).
When I diff the features.fea file found in the temp folder and the features.fea in the UFO package, the GPOS data is entirely different.
Is this a known issue? If yes is there a workaround other than me manually transplanting the temp folder .fea file into the UFO package?
As an aside, this also affect how FontMake generates UFOs.
Hi Kalapi, I already sent the Glyphs file to the support email with an explanation. For UFOs the dist gets saved in the kerning.plist because it is just kerning. Glyphs makes it a dist feature on export for the Kannada and leaves Latin in kern. It shouldn’t really matter, but the Microsoft specs for Indic scripts say to use dist. That’s all from 15 years ago and I’m not sure it really matters. I’d ask others like John Hudson if that has ever actually been an issue.
glyphsLib (not fontmake itself) doesn’t handle the Replace Feature custom parameter. I’m submitting a pull request right now where I fixed that to make it work. The real issue is what you described about all instances getting the same feature code. That needs to be fixed in each Replace Feature parameter. Currently you are using reference lookups to point to code that’s saved under languagesystems. All that code should be moved into each instance specific Replace Feature parameter. Then the Glyphs export should be correct. glyphsLib isn’t going to work yet for Replace Feature, but hopefully after today it will be fine.
Not sure automated code that is not visible in Font Info > Features is supposed to go into the UFO, since it is not part of the .glyphs file either. It does not do that for mark/mkmk either, does it?
This can’t be saved as UFO because it has multiple masters. The only thing automated is the GPOS including kerning and that gets put into the UFO kerning.plist on export which seems totally fine. The real question is that since Glyphs converts that to a dist feature on OTF/TTF export should the exported UFO also contain that in features.fea as a dist feature? Like I said above I’m not sure that’s really necessary, but that’s one big difference. If it really should be a dist feature and not kern then glyphsLib will also need the same logic that Glyphs uses to determine which scripts use dist.
The main difference between the dist and kern features is that the former is on by default (due to Indic scripts containing non-optional inter-glyph kerning). This was done specifically to ensure that kerning for Indic scripts works regardless of how an application chooses to handle kerning in scripts where it might be arguably ‘optional’ (e.g. MS Word). Thus, it is still very much useful and should be preferred over the kern feature.
I have updated the glyphs file to reflect exactly what you said. Now the instance specific lookups are in a single line in the ‘Replace Feature’ parameter to stop them from being included in every instance (I’ll send the latest source over in a bit). I’ve performed tests on the binaries and they work fine.
I’ll lookout for the update on glyphsLib and fontmake.
