Understanding the OpenType Engine Layout Algorithm

adiabatic's picture

I'm still trying to wrap my head around the OpenType Layout Algorithm. Here's what I have currently, largely adapted from Pecita and OTFPOC:

lookup calt_pass_1 {
    sub @can_2s'    lookup plain_to_2s
        @can_s2'    lookup plain_to_s2;

    sub @can_s2'    lookup plain_to_s2	# matched in [roe][it] 
        @can_2s'    lookup plain_to_2s;

    sub @can_2b'    lookup plain_to_2b
        @can_b2'    lookup plain_to_b2;

    sub @can_b2'    lookup plain_to_b2
        @can_2b'    lookup plain_to_2b;
} calt_pass_1;

I'm trying to figure out what happens when this sort of thing is applied to an arbitrarily long text string. I'm making a script font for Quikscript (3 MB PDF), and I'd like to be able to correctly represent the highly-ligated Senior Quikscript when 'calt' is turned on. If you'd like to see Quikscript, both Junior and Senior in action, turn to the antepenultimate page of the manual. Note that Senior Quikscript has a lot of abbreviations that're in use in the "As written in" section; you may want to have a look at the last word on the page, which is "impossible" written with only one penlift.


  • If I apply calt_pass_1 to a four-letter string, letters 2 and 3 won't shape each other. How do I design subs/lookups so the middle letters can affect each other, as well as the letters they're already (maybe) connected to? As I've written things in my font, I can't guarantee that a second pass will start at the second string instead of the first if there's nothing to change about the first character in the string.
  • Words with an odd number of letters occur frequently. How can I design my subs so I'm guaranteed to be able to change them too if I'm subbing letters two at a time?

Please chime in if I'm not being clear; I've tried to strip out some detail that depends on knowing how Senior Quikscript letters are formed. If it'll help, I'll be more than happy to draw pictures of what things should look like.

agisaak's picture

Without including definitions for the classes and lookups referenced in the above code, it's difficult to comment on this.


adiabatic's picture

Whoops — that was in the first draft of this post, but not the one I actually posted. Here's the whole .fea file. This file is generated by generate-calt.py, which uses data described in glyphinfo.yaml.

Syndicate content Syndicate content