Support Glyphs App “standalone” lookups

[khaledhosny]

A Glyphs App extension that allows defining lookups inside feature blocks without referencing them (i.e. as if the lookup was defined outside of the feature block).

https://handbook.glyphsapp.com/en/layout/standalone-lookups/

[anthrotype]

Thanks Khaled, sorry, I know you did not come up with this so I don't blame you... but I really dislike this.
It's a complete hack. First of all, it stretches the meaning of the word stand-alone. Before this, a lookup could either be said to be standing alone, i.e. in a lookup block outside a feature block and then referenced by name from within a feature, or it could be defined inside a feature block and at the same time also be applied there and then (equivalent of defining a standalone lookup and then referencing it by name inside the feature). It is debatable whether this was a good design choice, but that's how FEA has always worked.
Now, Glyphs.app's developers propose a third kind of lookup that purports to be "standalone" while not actually being such, because it is still defined inside a feature block, not outside of it which was the original meaning of "standalone", and whose only purpose is to allow one to define the lookup inside a feature block without also applying it. But the actual reason they want to do that is becuase of the way their features UI editor splits up FEA into sub-panels for each named feature, that only contain the inside of a given feature block (without the feature tag and enclosing curly braces), and so they would like to be able to define named standalone lookups inside a feature block, nearer to where they will be used, instead of defining them in the so-called "prefix", or outside of any particular feature panel/block (the prefix itself is also another invention of Glyphs.app).
And this new confusing keyword is just a private extension, was never to my knowledge proposed to extend the public FEA spec, and thus would contribute to the futher fragmentation of an already bad situation, with now 3 or 4 implementations increasingly diverging from each another.
So all in all, I am against this and would prefer that feaLib (and fea-rs which natuarally follows feaLib) to not support this. There is already a way for the user to ensure their fonts compile with fontmake or fontc, that is by moving these so-called "standalone" lookups to the features prefix section, without the "standalone" keyword.
Maybe glyphsLib could be more fitting as the translator between these two formats, but I am also afraid that if we encourage the use of this, the we'll find ourselves having to support it in the Rust font compiler as well, and I would like avoid it because I don't really like it for the above mentioned reasons.
Only if it made it to the offical FEA spec I could reconsider updating feaLib/fea-rs to support this, but I doubt it would happen.

[khaledhosny]

I don’t like it either, and if it were up to me I’d drop all the inline and implied lookups from FEA syntax, they have always been a source of trouble. Feature blocks should contain lookup references only. But:

1. It is something Glyphs already supports and we want Glyphs sources to build out of box as much as possible,
2. FEA does not have a functional standardization process, proposals gets submitted and debated then left in limbo, and if one implements a proposal that AFDKO does not yet implement, there is no guarantee that AFDKO implementation will match the proposal when it is done, if ever.

[khaledhosny]

cc @schriftgestalt

[schriftgestalt]

I think the functionality is really needed (I’m open to change the syntax if someone has a better idea). Otherwise stuff gets scattered all over the place. Mostly when doing chaining pos/sub stuff. There you need to define a lookup that is not directly included in a feature record. Without this, those extra lookups have to be defined outside of the feature and that can be hundreds of lines away of where it is used (the problem is a tiny bit exaggerated in Glyphs because there is not "outside of the feature", but that doesn't make a bit difference).

[justvanrossum]

But let's be realistic: it is mainly needed because of a particular detail of how Glyphs works. I find that a very poor reason to just go and add new syntax. Regardless of the poor track record of FEA standardization.

[schriftgestalt]

As I said. This is another argument but not the reason.

[schriftgestalt]

It is much nicer to have this next to each other:

standalone lookup single_subst {
    sub a by b;
} single_subst;
lookup chain_subst {
    sub a' lookup single_subst b c;
} chain_subst;

And having it in a Prefix in Glyphs is even less annoying as to have it somewhere else hundreds of lines away. Features for Indic scripts or Arabic can be VERY long and confusing already.

[anthrotype]

glyphsLib already does a bit of regex to massage and join up the features.fea when translating .glyphs => UFO, I believe it could could take the responsibility to move these "standalone" lookups out of the feature blocks in their own prefix.
So, with my maintainer's hat on, I am going to close this for now.

[khaledhosny]

glyphsLib already does a bit of regex to massage and join up the features.fea when translating .glyphs => UFO, I believe it could could take the responsibility to move these "standalone" lookups out of the feature blocks in their own prefix. So, with my maintainer's hat on, I am going to close this for now.

It is not as simple as some regex substitution, as the lookup order needs to be preserved and lookup flags needs to be carried over.

[anthrotype]

to preserve the lookup order glyphsLib could turn all the lookups as true standalone, and replace the inline ones (inlcuding the so-called "standalone") with references. I'm not sure what you mean by "lookup flags needs to be carried over".
In any case, this feature is badly designed, not officially part of the spec, and one can accomplish the same results without using it, so I reserve the right to not add support for it.

[khaledhosny]

I’m still not convinced. Philosophical purity aside, supporting this does not cost us much, and closing one compatibility gab is an overall one. Supporting this in glyphsLib requires duplicating feaLib.parser or subclassing it in ways it was not intended for, making things more complicated for no much gain.

[rsheeter]

fea-rs would need an update as well. Do we have evidence of the "standalone" syntax being used? At what scale?

[behdad]

AFAIU the lookup order of chained-to lookups doesn't matter. So the whole reasoning in https://handbook.glyphsapp.com/en/layout/standalone-lookups/ sounds dubious to me.

I understand and share Cosimo's frustration, but also empathize with Khaled's desire for supporting .glyphs sources as much as we can. If it was up to me I would have probably accepted this.

[behdad]

The alternative would be to do it in glyphsLib as Cosimo suggests. @khaledhosny lookup order is irrelevant isn't it? What else would feaLib need to allow glyphsLib to subclass the parser, transform the AST, and write it as legal .fea? Maybe the same mechanism can be applied to googlefonts/glyphsLib#800 as well...

[justvanrossum]

Gentle reminder that this feature is mainly driven by a limitation in Glyphs, and not by an objective need for improvement.

[behdad]

Maybe a regex is all we need after all...

[schriftgestalt]

Gentle reminder that this feature is mainly driven by a limitation in Glyphs, and not by an objective need for improvement.

This is not true and I explained that already (having the extra lookup in a "Prefix" in Glyphs makes it even easier to get to them editing). The main reason is to keep the functional parts of the feature code together. Specially Arabic fonts can have a lot of contextual substitutions. Having the actual and the chaining lookup just next to each other can streamline working on it.

One thing that I’m open to change is to move the "standalone" after the "lookup" keyword.

lookup standalone [useExtension] lookup_name { …

[behdad]

ignore lookup...

[schriftgestalt]

ignore is used already, do to remove ambiguity, maybe lookup ignore?

[behdad]

ignore is used already, do to remove ambiguity, maybe lookup ignore?

That's my personal preference, to at least not introduce a new keyword. I'm going to experiment with subclassing the feaLib parser in glyphsLib and see if I can rewrite the .fea.

[anthrotype]

If Glyphs.app Features panel allowed one to write a "prefix" immediately before the current feature, this issue would be solved and we wouldn't need any extra keyword. Please consider adding some option in the currently selected feature panel, say next to "active" and "generate feature automatically" checkboxes, which when selected would show the enclosing feature XXXX { and } XXXX; lines that are currently hidden (but they are still there in order for the FEA to be valid), you could even try to make them not editable; then a user could simply define their standalone named lookups immediately before/outside the feature block, like one would do for standard FEA, and the issue would be solved.

[schriftgestalt]

Not "immediately before".

This is where the lookups are defined:

and this is where it is used:

Or, directly next to it:

And in this case it doesn't make a difference if the "uMatra_ligatures_a" lookup is defined in a "Prefix" or above the blws feature. Neither is visible at the same time.

[anthrotype]

if one wants those two lookups to be close to one another, one could define both of them outside of the feature block, not just the standalone one but also the lookup that references it; then inside the feature block you simply reference the contextual lookup. I don't see a problem with that, it's more explicit and gives you exact control over when lookups are defined and when they are applied, avoiding the define-and-apply-at-the-same-time issue of named lookup defined inside a feature block.

[schriftgestalt]

But then you still need to hunt around to see what is going on. Making sense of those files is quite annoying. I get those now and then and people ask why things are not working. And they are not working because of the lookup order or just because they confuse things.

[khaledhosny]

Gentle reminder that this feature is mainly driven by a limitation in Glyphs, and not by an objective need for improvement.

The whole “modern” font building pipeline is shaped by font editors limitations. Like we are fighting with feature files because FontLab 4 didn’t have an OpenType UI and UFO just followed suit. The whole UFO format is a glorified serialization of of FontLab 4. All the mess of feature file with all its gotchas is probably because Adobe didn’t have an OpenType editor (and probably couldn’t use VOLT) so wanted a hand-editable format instead of a proper structured one.

[khaledhosny]

if one wants those two lookups to be close to one another, one could define both of them outside of the feature block, not just the standalone one but also the lookup that references it; then inside the feature block you simply reference the contextual lookup. I don't see a problem with that, it's more explicit and gives you exact control over when lookups are defined and when they are applied, avoiding the define-and-apply-at-the-same-time issue of named lookup defined inside a feature block.

Even if the order of the chained lookup is unimportant, the order of the contextual lookup often is. So going this route, one ends up defining everything in a prefix and not using feature blocks at all. But folks don’t want to do this (you miss automatic features, and the UI to set ssXX feature names, etc.).

I really don’t understand the strong opposition. It is an ugly hack, I don’t like it either, but what is the big deal! I’m in the business of making fonts and helping people make fonts, that is the end goal: fonts in the hands of the users. The tools to do this are means to and end and as long as this addition does not affect FontTools maintenance in a bad way, I don’t see why wee need to think of all other complicated alternatives to not do the simplest thing.

[khaledhosny]

fea-rs would need an update as well. Do we have evidence of the "standalone" syntax being used? At what scale?

I don’t have data. I needed to use it in a project and I thought it would be nice to be still able to build the font with fontmake.

[khaledhosny]

The alternative would be to do it in glyphsLib as Cosimo suggests. @khaledhosny lookup order is irrelevant isn't it?

I don’t know. The one time I used it was actually to preserve the lookup order of an earlier build of a font to avoid needless changes.