googlefonts / fontc

Where in we pursue oxidizing (context: https://github.com/googlefonts/oxidize) fontmake.
Apache License 2.0
85 stars 14 forks source link

crash with duplicate featureName entries #1019

Closed cmyr closed 1 month ago

cmyr commented 1 month ago

As of #969, I'm seeing a new failure case: some fonts (such as Moderustic) are failing to compile because some of the stylistic set features end up with two featureName blocks.

The generated FEA looks like this:

feature ss17 {
        featureNames {
        name "ss17";
    };

    # Stylistic Set 01–20
        featureNames {
        name "Bulgarian letters";
    };

    sub @loclBGR by @loclBGR1;
} ss17;

fea-rs is erroring because it expects there to only be one featureNames statement. A close reading of the relevant bit of spec suggests this is a mistake, and multiple blocks are allowed (they just have to precede any rules) so I'll go and fix that; but I wanted to open this for discussion, since this FEA looks weird, and I was wondering if anyone (@khaledhosny?) knows where it comes from? Specifically the first label block will end up being overwritten by the second, and isn't doing anything.

khaledhosny commented 1 month ago

That is some odd font! It sets feature labels using GlyphsApp UI to use ssNN names, then is some of the features is has also featureNames block written manually is the feature code. It seems that both GlyphsApp and fontmake will generate a featureNames block regardless of the manually written one, and feaLib seems to not complain about the duplication and it uses the later one (I couldn’t export the font on GlyphsApp due to another error, so I don’t know which featureNames block it will pick).

cmyr commented 1 month ago

dug into this more: with fontmake it seems to be 'last writer wins', and afdko creates name records for both strings, but only references the first.