Typophile

Wildcard for Opentype Substitution code?

Dixon Yamada

I want to work with spaces in my sub code, or rather the glyphs immediately adjacent to the space. I wonder if there is any way I could use a wildcard and simple variables to make this code a lot shorter. I'm trying to have a special glyh substition for all glyphs at the end of words, and all glyphs at the begining of words.

If not I could always generate a line of code for every glyph - space combination, and every space - glyph combination.

Sounds like a job for init and fina features, but I have yet to use them, so I’m not much help. However, the same thing can be accomplished with the calt feature.

As I understand it (which I may not, and amendment will surely follow), text strings within brackets are processed and/or recognized sequentially, so—instead of a line of code for every glyph—you could use code like this:
sub [ a b c d e f etc .]' space by [ a.fina b.fina c.fina d.fina e.fina f.fina etc.fina ];

Yes init and fina seem to be exactly what im looking for. Researching them has led to more confusion however. Looks like I need to make 2 substitution tables. I have no idea how to do that. Moreover I can't find anything on what the code would actually look like, or how to go about doing all this in fontlab.

See http://www.www.typophile.com/node/60990
As for "wildcards," isn't that what OpenType classes more or less do?

Ok, Im advancing myself a little farther down this rabbit hole:
Very hard to find actual examples of opentype code online.
Lots of sites describing its capabilities, and a few sites that list all its "features" aka methods,
but very little actual code examples.

It seems like this is what I want, though I haven't been able to get it to work:

@LETTERS = [ < all letters in the font that could be part of a word>];

feature clig {
lookup BEGIN_WORD_LIGS {
ignore @LETTERS @LETTERS'; # will match any word glyph preceeded by another word glyph.
sub c t by c_t.begin; # you know that there is no word glyph before the 'ct' sequence.
};

lookup END_WORD_LIGS {
ignore @LETTERS' @LETTERS; # will match any word glyph followed by another word glyph.
sub o f f by o_f_f.end; # you know that there is no word glyph after the 'off' sequence.
};
} clig;

I get that they are addressing a class with the @LETTERS, but did they have to create this class through fontlab somehow, as in a new set of glyphs? That is, is it or is it not being substantiated in the actual code itself? And why isn't Fina or Init being used here? Is Lookup an actual built-in function, or "feature", or just what the author chose to name this function right here in this example?

If you have not already seen it you may find this useful.

Hello Ryan,

I am not an expert on OT myself, but after a lot of trial and error I managed to achieve a pretty sophisticated result...

You can see my code in this thread: http://typophile.com/node/92348

About your issue: Isn't "space" just a glyph like any other? It would make sense for it to be...

"I get that they are addressing a class with the @LETTERS, but did they have to create this class through fontlab somehow,"

Yes.
"as in a new set of glyphs?"

New glyphs? Presumably not: the whole point was to reference all existing letter glyphs in the font.

> That is, is it or is it not being substantiated in the actual code itself?

Yes, there needs to be code for it. There are no built-in classes in FontLab or OpenType.

>And why isn't Fina or Init being used here?

That's a question for the person who wrote the code. If it were me, my most likely reason to avoid 'init' and 'fina' would be poor app support. Even InDesign, which does support these features, contradicts the OpenType spec by not having them on by default. I lobbied hard to get them supported, but couldn't get them on by default. :(

> Is Lookup an actual built-in function, or "feature", or just what the author chose to name this function right here in this example?

The concept of a lookup is fundamental to OpenType itself. The AFDKO feature language supports it directly for those cases where a lookup needs to be explicitly handled for some reason. Your feature code will otherwise create one lookup per OT feature where it is not explicit.

BTW, this discussion really belongs in "Build" rather than "General Discussions."

Captured from web.archive.org on 14 May 2012. view this capture