Compact support for long length ligatures (eg case insensitive ones)

[davelab6]

I have a project that I wanted this ligature in:

sub colon [s S] [h H] [o O] [o O] [t T] [i I] [n N] [g G] hyphen [s S] [t T] [a A] [r R] colon by shootingStar;

@behdad pointed out this explodes exponentially, and even a ligature of len(10) becomes 2^10 = 1024 separate rules.

Is there any way implement this another way in the existing model that isn't very slow (as below), to evolve the OT model to allow for this, or is thing something for the wasm shaper future?

(Behdad proposed this much more complicated ways to do it today, but expects it to be slow, and still might cause offset overflows)

1. Contextually match the ligature first; this would use glyph classes, so doesn't have the same combinatorial explosion problem.
2. For each of the glyphs in the matched input, invoke a lookup to lowercase the letter.
3. Invoke the actual ligature lookup that only operates on lowercase letters.

[dscorbett]

How about this?

1. Substitute every capital letter with its lowercase form followed by uppercase, an invisible mark glyph.
2. Ligate sequences of lowercase letters, skipping marks. No classes are needed.
3. Ligate any lowercase letter followed by uppercase to its capital form.

feature rlig {
    sub A by a uppercase;
    // ...
} rlig;

feature rlig {
    lookupflag IgnoreMarks;
    sub colon s h o o t i n g hyphen s t a r colon by shootingStar;
} rlig;

feature rlig {
    sub a uppercase by A;
    // ...
} rlig;

[behdad]

Oh that's genius.

[davelab6]

How fast is this to shape? :)

[behdad]

I'm not convinced it's a big-enough need.

[cmyr]

Although cute, it feels to me like this should not be treated as a supported case by a shaper, which exists to render text per the expectations of a given writing system. A font developer is welcome to do fun things like this, but they should not expect them to work everywhere or to be performant, and I would not want this sort of example to guide an design decisions made in any software. 🤷