Support (or don't) Glyphs-specific variable feature syntax

[simoncozens]

Glyphs has a different variable feature syntax to Adobe/fonttools/FontCreator. Instead of:

conditionset bold {
    wght 140 180;
} bold;

variation rlig bold {
   sub dollar by dollar.bold;
   sub cent by cent.bold;
} rlig;

Glyphs produces

feature rlig {
#ifdef VARIABLE

condition 140 < wght < 180;
sub dollar by dollar.bold;
sub cent by cent.bold;

#endif
} rlig;

Do we want to support this? I think probably not. Glyphs should do the right thing here.

[anthrotype]

would be nice to be able to automatically translate from one to the other form when converting glyphs=>UFOs, but if it's too much trouble we shouldn't bother.
But I also think Glyphs.app should be updated to support the official form (if it doesn't work already, does it?)

[schriftgestalt]

It would be nice if there where a spec that all parties had discussed and had agreed to. Now we have a suggestion that some parties just found good enough and went ahead and implemented it.

[simoncozens]

Welcome to OpenType.

[vv-monsalve]

would be nice to be able to automatically translate from one to the other form when converting glyphs=>UFOs, but if it's too much trouble we shouldn't bother.

This would be nice, indeed. Would it be too much trouble?

Glyphs is suggesting since 2021, so I can see more cases coming (I have on at the moment).

[HugoJourdan]

would be nice to be able to automatically translate from one to the other form when converting glyphs=>UFOs, but if it's too much trouble we shouldn't bother.

Same problem here.

I also tried to use syntax from Adobe/fonttools/FontCreator in Glyphs and export variable with fontmake, but I got the same problem.

[simoncozens]

The Adobe/fontTools variable fea syntax should work already; the Glyphs 3 variable fea syntax should not. What's happening in your case, Hugo?

[BaGsn]

I tried Adobe syntax and got the same error as with Glyphs one, but with conditionset instead of condition:
Expected glyph class definition or statement: got NAME condition
Expected glyph class definition or statement: got NAME conditionset

[jpt]

Do we want to support this? I think probably not. Glyphs should do the right thing here.

I for one think glyphsLib should support this. This issue has been open long enough that there are probably a bunch of Glyphs files in the wild that already do it the Glyphs way

[jpt]

@anthrotype

would be nice to be able to automatically translate from one to the other form when converting glyphs=>UFOs, but if it's too much trouble we shouldn't bother.
But I also think Glyphs.app should be updated to support the official form (if it doesn't work already, does it?)

I'm not currently familiar with glyphsLib's codebase, so I'm not really sure how much trouble it would be, but for what it's worth, to do this using the actual Glyphs API it would be something like:

from fontTools.designspaceLib import DesignSpaceDocument, RuleDescriptor
import re

def getAxisNameByTag(font, tag: str) -> str:
    return next((axis.name for axis in font.axes if axis.axisTag == tag), None)

def getBoundsByTag(font, tag: str) -> list:
    index = next((i for i, axis in enumerate(font.axes) if axis.axisTag == tag), None)
    if index is not None:
        coords = [master.axes[index] for master in font.masters]
        return [min(coords), max(coords)]
    return [None, None]

def parseCondition(condition, font):
    tag = re.search("< (\w{4})", condition).group(1)
    axis_name = getAxisNameByTag(font, tag)
    bounds = re.findall("\d+(?:\.|)\d*", condition)
    bounds = [float(b) for b in bounds]
    if len(bounds) < 2:
        _, max_bound = getBoundsByTag(font, tag)
        bounds.append(max_bound)
    return {'name': axis_name, 'minimum': bounds[0], 'maximum': bounds[1]}

def getConditionsFromOT(font):        
    feature_code = next((feature_itr.code for feature_itr in font.features if "condition" in feature_itr.code), "")
    
    condition_list, replacement_list, condition_index = [], [[]], 0
    for line in feature_code.splitlines():
        if line.startswith("condition"):
            conditions = [parseCondition(cond, font) for cond in line.split(",")]
            condition_list.append(conditions)
            condition_index += 1
        elif line.startswith("sub"):
            replace = tuple(re.findall("sub (.*) by (.*);", line)[0])
            if len(replacement_list) < condition_index:
                replacement_list.append([])
            replacement_list[condition_index-1].append(replace)

    return [condition_list, replacement_list]

def applyConditionsToRules(doc: DesignSpaceDocument, condition_list: list, replacement_list: list):
    rules = [RuleDescriptor(name=f"Rule {i+1}", conditionSets=[cond], subs=repl) for i, (cond, repl) in enumerate(zip(condition_list, replacement_list))]
    doc.rules = rules
    return doc

Font = Glyphs.font
doc = DesignSpaceDocument()

condition_list, replacement_list = getConditionsFromOT(Font)
doc = applyConditionsToRules(doc, condition_list, replacement_list)

print(doc.rules)

...and after adding the rules you'd want to remove the #ifdef VARIABLE stuff from rlig or whatever feature is being used.

But it seems like this is still an open question as to whether it would even be reviewed/approved if someone opened a PR?

@schriftgestalt Any plans or new ideas around supporting the Adobe/fontTools feature syntax?

[simoncozens]

I think there are multiple problems with the approach you suggest. It looks like an alternative way of getting part of Glyphs' variable rules (specifically the conditionsets) directly into the designspace document (and so it would need to be plugged deep into glyphsLib.builder.features, and would work only for the purposes of simple substitution rules. But there's a much easier way to express simple variable conditional substitution rules in a Glyphs file: use alternate layers. The only reason someone would be writing variable feature code by hand is when you're trying to do something more complex than alternate layers provide!

Even then, you'd still need to rewrite the feature code to remove all the #ifdef VARIABLE stuff, so that it can be parsed and built by fontTools.feaLib. At which point, it may be simpler just to transform the Glyphs syntax into the Adobe syntax.

(Sidenote: Most of the complexities of glyphsLib would be eliminated if we moved to a system of progressively transforming Glyphs source files into something directly compilable, instead of trying to resolve all the smart stuff while building a designspace file.)

And of course, simpler still if Glyphs just went with what everyone else is using instead of inventing its own syntax...

[jpt]

The only reason someone would be writing variable feature code by hand is when you're trying to do something more complex than alternate layers provide!

I disagree. I don't think this decision is necessarily dependent on complexity - ultimately it's just a workflow preference. It can be easier to work with alternate glyphs, visible in the Font view, rather than alternate layers. Especially so if you have a lot of masters, or if you have any brace layers. There's a page on the Glyphs website that goes into some detail about why you might choose one approach over the over. In it, Rainer expresses his own preferences for alternate glyphs (https://glyphsapp.com/learn/switching-shapes section: What to choose when: alternate glyphs or layers?)

At which point, it may be simpler just to transform the Glyphs syntax into the Adobe syntax.

Good point (I'm assuming glyphsLib already supports the Adobe syntax?)

And of course, simpler still if Glyphs just went with what everyone else is using instead of inventing its own syntax...

I agree, though I assume there are enough Glyphs files already doing it this way that glyphsLib would benefit more users by supporting both the Adobe and Glyphs-specific syntax. Currently I don't believe the Adobe syntax is supported

[simoncozens]

I disagree. I don't think this decision is necessarily dependent on complexity

Fine. But any solution will need to also support more complex use of variable feature programming, such as multiple substitutions, contextual substitutions and so on; not all of which can be represented by designspace rules.

Currently I don't believe the Adobe syntax is supported

It certainly is in fontTools, and therefore in glyphsLib. Getting it to work in fontmake is... what I spent most of the last two weeks working on. :-)