Okay, I am simplifying my questions.

Why is the lookup needed in the following code?:

feature calt {
lookup alpha {
sub bracketleft one one' bracketright by A;
} alpha;
sub one' A by A;
} calt;

[11] is replaced by [AA] as intended.

feature calt {
#lookup alpha {
sub bracketleft one one' bracketright by A;
#} alpha;
sub one' A by A;
} calt;

But with the code above [11] results in [1A].

Second question: Why can’t I call a lookup registered with the same languagesystem statement?

I cannot code …

feature calt {
lookup alpha {
sub bracketleft one' bracketright by A;
sub bracketleft one one one' bracketright by A;
sub bracketleft one one' bracketright by A;
} alpha;
lookup beta {
sub one' A by A;
} beta;
lookup beta;
} calt;

… but I have to code

feature calt {
lookup alpha {
sub bracketleft one' bracketright by A;
sub bracketleft one one one' bracketright by A; #The first one will be substituted in lookup gamma, the second one in beta.
sub bracketleft one one' bracketright by A; #The first one will be substituted in lookup beta.
} alpha;
lookup beta {
sub one' A by A;
} beta;
lookup gamma {
sub one' A by A;
} gamma;
} calt;

How can I make out, that I manually have to add a lookup without testing?

> feature calt {
> sub bracketleft one one' bracketright by A;
> sub one' A by A;
> } calt;

> But with the code above [11] results in [1A].

There is one lookup defined in your calt feature (implicitly). Your feature definition is equivalent to:

feature calt {
lookup delta {
sub bracketleft one one' bracketright by A;
sub one' A by A;
} delta;
} calt;

You have the input glyph run [11].

The lookup delta steps through the glyphs one by one:

1. First, the glyph [ is "current". The lookup is searched for the best match, and finds none.

2. Then, the first glyph 1 is current. The lookup is searched for the best match, and finds none.

3. Then, the second glyph 1 is current. The lookup is searched for the best match, and finds the match in the rule sub bracketleft one one' bracketright by A;, so it executes it. The current glyph is substituted by A.

4. Finally, the glyph ] is current, and no match is found.

So the output run is [1A].

The code

> feature calt {
> lookup alpha {
> sub bracketleft one one' bracketright by A;
> } alpha;
> sub one' A by A;
> } calt;

defines two lookups, so it's equivalent to

feature calt {
lookup alpha {
sub bracketleft one one' bracketright by A;
} alpha;
lookup beta {
sub one' A by A;
} beta;
} calt;

You have the text run [11].

First the lookup alpha is executed, and after skipping the first two glyphs, the second 1 gets a match for the rule sub bracketleft one one' bracketright by A;, so it's executed. At the end of the lookup execution, the output run is [1A].

Then the lookup beta is executed on the output run of the previous lookup, i.e. on the glyph run [1A]. After skipping the glyph [, the glyph 1 hits a match for the rule sub one' A by A;, so the rule is executed, and the glyph gets substituted by A. So the final output run is [AA].

Very simple and logical. But only if you remember that the lookup statement in the AFDKO syntax is always implied if it is not defined. In fact, I recommend using it explicitly, especially in contextual substitutions, to keep track what's going on.

It's kind of similar to our previous discussion about languagesystems, when I recommended to always spell out script latn, language dflt and include_dflt in feature definitions that define different behaviors for different languagesystems, rather than relying on the implied use of those statements.

The general rule is: the implicit definitions are useful for simple situations, when you mean to say "all languagesystems" (in case of languagesystems) or "one lookup" (in case of lookup definitions within feature definitions). But mixing explicit and implicit definitions is a road to hell when it comes to debugging, so it's always better to spell everything out explicitly if your code becomes more complex.

Best,
Adam

If you're paying close attention, you might ask why I wrote

# Variant 1

feature ss01 {
lookup ss01a {
sub a by a.ss01;
} ss01a;
} ss01;

feature ss02 {
lookup ss02b {
sub b by b.ss02;
} ss02b;
} ss02;

feature salt {
lookup ss01a;
lookup ss02b;
} salt;

when I could have just written:

# Variant 2

feature ss01 {
lookup ss01a {
sub a by a.ss01;
} ss01a;
} ss01;

feature ss02 {
lookup ss02b {
sub b by b.ss02;
} ss02b;
} ss02;

feature salt {
sub a by a.ss01;
sub b by b.ss02;
} salt;

which would be equivalent to

# Variant 2 explicit

feature ss01 {
lookup ss01a {
sub a by a.ss01;
} ss01a;
} ss01;

feature ss02 {
lookup ss02b {
sub b by b.ss02;
} ss02b;
} ss02;

feature salt {
lookup saltab {
sub a by a.ss01;
sub b by b.ss02;
} saltab;
} salt;

In other words: why did I choose to use two lookups in salt (in Variant 1), when the output run of the first lookup is not related to the input run of the second lookup. Indeed, I could have used Variant 2.

Basically, Variant 1 means that I save a little bit of space in the font (because I only define two lookups instead of three), but it means that I lose a tiny bit of performance, because the salt feature executes two lookups one after another, rather than just one. On the other hand, Variant 2 menas that I speed up the performance a tiny bit, but I lose a few bytes of space in the font size.

The differences are so minute that I wouldn't worry. It's just a matter of code optimization vs. code brevity. If I want code that is simpler to read and edit, I choose Variant 1. If I want perfect speed optimization, I choose Variant 2.

Hope this helps,
Adam

I guess I’m the one you should bill :p

@ Adam

Well, the principle seems to be indeed simple, but it can be hard, not to loose the overview. In case of the lookups "Index 1" and "Index 2" from the calt feature, that I have coded for Frode, the comprehension was much harder. I really had to comprehend step by step, why the one and only rule of lookup Index 2 cannot be put into the end of lookup Index 1, although the last rule of lookup Index 1 can be put in the begin of lookup Index 2.

(Notice to myself: Check, if only lines can be commented in code [with the number sign] or also whole blocks with begin and end markers.)

I think, that I meanwhile understand the very most of your explanations and extra information except from the problem, about which I was talking in the second paragraph of my previous message.

The first call of the lookup beta is the definition of the lookup beta and it cannot be called more than one time with the same languagesystem statement.

feature calt {
lookup beta { #Definition of lookup beta AND call of lookup beta.
sub one' A by A;
} beta;
lookup beta; #unsuccessful call of lookup beta, that was defined above.
} calt;

The substitution is not well chosen, but that is unimportant in this context. There are cases, in which it would be useful to call a lookup a second time in the same feature and under the same languagesystem statement without defining it a second time. Not only with regard to the comprehension of the own code, but probably also with regard to the file size.