Standalone lookups inside of features

Glyphs
1

I plan to add a custom marker to the lookup that makes not apply it automatically. Something like freestanding in the lookup flags. But maybe it it better to use a special comment to not disturb the syntax. But then you might like the disturbance to not get a wrong result in a feature compiler that doesn’t know about this.

2

I don’t think a special comment will be easy to miss since the lookup has to be referenced I side another lookup or feature block to do anything, so a compiler that does not the special comment will get a reference to a nonexistent lookup and error.

3

I meant a syntax like this:

lookup RO {
 lookupflag standalone;
 sub R by R.alt;
 sub O by O.alt;
} RO;

lookup RO_context {
 sub R' lookup RO O' lookup RO;
} RO_context;

or

lookup RO standalone {
 sub R by R.alt;
 sub O by O.alt;
} RO;

or

lookup RO { # standalone
 sub R by R.alt;
 sub O by O.alt;
} RO;

The last one would be the least intrusive but a compiler that doesn’t know the special comment would activate that lookup. The new keyword would at least produce an error.

4

I see. What I had in mind per-feature prefix (e.g. GSFeature.prefix, like the comment and code), or alternatively putting the lookup in the comments and have some special comment to mark it (e.g. # Prefix Start and # Prefix End).

A special lookup keyword is problematic for a fontmake-based workflow as it will require supporting a very Glyphs-specific syntax in feaLib, or implementing some Jacky preprocessing step in glyphsLib.

5

I don’t think resolving such standalone lookups in glyphsLib would be inappropriate.

6

Any structure we come up with will need some special processing somewhere. Either is the compilation would fail because of the unknown keyword or the lookup would be missing when it is hidden in comments.

I would make the case that the “standalone” keyword would be a useful addition to the syntax. If you have a feature with a lot lookups, you can keep the extra lookup next to the substitutions that use it.

7

What would you do about lookup order with the standalone keyword? Right now we have lots of control over the order in which lookups get applied. Would we still have that with this innovation?

8

The lookup order doesn’t really matter with those standalone lookups. As they are “called” from a very specific place. But I would think that the lookup order would follow the order in the .fea file.

9

Oh, of course. I don’t mind using the prefix, but it sounds like a good feature to add.

10

I just spoke with my colleague and we decided on this:

lookup RO standalone {
…
11

It would be easier to handle if it was in some Glyphs-soecific structure, but extending feature syntax is problematic because you either need a full-blown Glyphs-specific feature file parser or some hacky regular expressions. And the keyword is pretty much result of how Glyphs file itemize feature code into sub-blocks, so it isn’t much useful in general to add to feaLib or other general feature file parser. E.g. instead of doing:

feature foo {
 lookup bar standalone {
 } bar;
 ...
} foo;

One can always do the equivalent that works with any feature file parser today:

lookup bar {
} bar;

feature foo {
 ...
} foo;
12

As I said, it might be interesting if you have a long features. Then it would be nice to have the lookups close by. Saves you from scrolling. And you can keep the functionality together.

1 Like
13

Finally!

14

I’d put “standalone” in front, both to make it more visible and to follow English grammar:

standalone lookup RO {
…
15

this would look better, you are right. But adding it after the name puts it next to the useExtension keyword.