Things fea can't do: specify chain execution order

[simoncozens]

As discussed with @punchcutter on Twitter, if you have a contextual lookup such as:

sub a' lookup luB b' lookup luA;

this is currently encoded as

<SubstLookupRecord index="0">
  <SequenceIndex value="0"/>
  <LookupListIndex value="indexOfluB"/>
</SubstLookupRecord>
<SubstLookupRecord index="1">
  <SequenceIndex value="1"/>
  <LookupListIndex value="indexOfluA"/>
</SubstLookupRecord>

That is, the chaining lookups are always executed in order from left to right as they appear in the rule. However, according to the spec:

The array should list records in design order, or the order the lookups should be applied to the entire glyph sequence.

i.e. the designer should be able to specify the order in which to apply chaining lookups.

The FEA language should, ideally, be extended with a mechanism for enabling the designer to specify the lookup execution order. Something like

sub a' lookup luB:2 b' lookup luA:1;

although we can bikeshed what that ought to look like.

[punchcutter]

I was thinking something with the lookups defined after backtrack/input/lookahead instead of inline:

sub x' y' z' lookup lu2:2 lookup lu1:1 lookup lu3:3;

Or with a fuller context:

sub @backtrack1 @backtrack2 x' y' z' @lookahead1 @lookahead2 @lookahead3 lookup lu2:2 lookup lu1:1 lookup lu3:3;

Where lookup :n gives the input index starting at 1 and the following lookup <name>:n+ are applied in order. One thing we need to keep in mind here is that the index may shift as lookups are applied. The user needs to consider this and write the rules accordingly. Some more contrived examples:

lookup xy_lig {
     sub x y by xy;
} xy_lig;

lookup yz_lig {
     sub y z by yz;
} yz_lig;

lookup xyz_lig {
     sub xy z by xyz;
} xyz_lig;

lookup change_x_before_yz {
    sub x yz by q;
} change_x_before_yz;

lookup z_alt {
    sub z by z.alt;
} z_alt;

In the following example test1 yz_lig is applied first resulting in [a b c ] x' yz.
Then change_x_before_yz is applied resulting in [a b c ] q
In this case the lookup index does not shift

lookup test1 {
    sub [a b c ] x' y' z' lookup yz_lig[2] lookup change_x_before_yz[1];
} test1;

In the following example lookup xy_lig is applied to the input at index 1 resulting in [a b c ] xy z. This shifts the input index so that the next lookup xyz_lig must consider the new indices of the incoming string. In this case the result of the first lookup now has 2 indices instead of the original 3 and we want to apply lookup xyz_lig to index 1:

lookup test2 {
    sub [a b c ] x' y' z' lookup xy_lig[1] lookup xyz_lig[1];
} test2;

Another example to hopefully make this more clear. Here the original input indices are x=1,y=2,z=3. After xy_lig is applied the index for z shifts from 3 to 2. So we need to know what input we expect at this step and apply to the correct index. If we try to apply z_alt to index 3 because it is 3 in the original stage then nothing will happen because at the stage where we apply z_alt there is no index 3.

lookup test3 {
    sub [a b c ] x' y' z' lookup xy_lig[1] lookup z_alt[2];
} test3;

[simoncozens]

Sure, the user needs to know what they're doing if they're using this facility. (Although to be honest I think it's more likely that this kind of rules will be written by machines than by humans...) From an implementation perspective, though, we just need a go-ahead on the syntax - I like the idea of putting everything at the end and specifying glyph positions there. What about marking out the positions, though? I'm not a fan of square brackets because they unconsciously make me think of either glyph classes or array indexing. Colon feels better, but how about this:

sub x' y' z' lookup lu2($2) lookup lu1($1) lookup lu3($3);

To me that screams "I am making a function call (lookup) with a parameter which is the second item in this sequence". Familiar to Perl and awk users at least. :-)