I’m trying to recompile Noto Sans Chakma from the TTF binary (the .glyphs source was compiled with FontDame in a build process that I can’t replicate).
When I open the TTF in Glyphs, the feature code throws up some errors and the font won’t compile.
Is it correct that a chained contextual lookup can’t reference rules that are defined later? Or is it some other problem? I imagine there’s a reason the lookups are defined in that order.
What Glyphs version is that. We recently worked on the GOPS to fea import.
ah sorry 3133.
Can you try the latest 3.2 (3184) only for the import. You should be able to edit in any older version if you prefer it.
Thanks. I’ll have a look.
I had a look. It seems that the lookups are imported in the order as they are in the file but are referenced forward. That is fine in the binary but not in feature code. You can move the POS_1 lookup above POS_0 (and so on for a few more lookup pairs).
I’ll check if we can fix that in the importer.
That’s great. I wonder why they’re in that order in the binary, it does seem a little strange.
When writing the lookups to binary, it makes sense to add extra lookups after the one where they are needed.
I’d normally keep referenced lookups in a prefix so they don’t get applied twice, but it does make sense to keep related lookups of this type together I suppose.
BTW could it be possible to have the option to show all errors not just the first 20? I’d like to be able to know all the problems throughout the code
It there are more than 20 errors it usually means that there is something quite wrong (e.g. a missing closing brace, or not updated glyphs names). Keeping on parsing then makes not much sense. And it will slow down the app when it adds all those error markers.
I know it’ll slow things down, and most people don’t need it, but I’d still find it helpful to have the option. In this case the rest of the code looks clean although it’s full of errors.
