Wildcard for Opentype Substitution code?

Ryan Maelhorn's picture

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.

oldnick's picture

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 ];

Ryan Maelhorn's picture

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.

eliason's picture

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

Ryan Maelhorn's picture

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?

Karl Stange's picture

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

AlexanderKatt's picture

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...

Thomas Phinney's picture

"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.

Thomas Phinney's picture

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

avangel's picture

Hi,

I just found a simple and elegant solution to the problem of targeting beginning- or ending-of-word letters. It is based on the example provided in the Adobe's specs :


feature cswh {
# --- Glyph classes used in this feature:
@BEGINNINGS = [A-N P-Z Th m];
@BEGINNINGS_SWASH = [A.swsh-N.swsh P.swsh-Z.swsh T_h.swsh m.init]; @ENDINGS = [a e z];
@ENDINGS_SWASH = [a.fina e.fina z.fina];

# --- Beginning-of-word swashes:
ignore substitute @LETTER @BEGINNINGS';
substitute @BEGINNINGS' by @BEGINNINGS_SWASH;

# --- End-of-word swashes:
ignore substitute @ENDINGS' @LETTER;
substitute @ENDINGS' by @ENDINGS_SWASH;
} cswh;

But this example does not work if applied to a single letter (at least in FontLab, the only place where I tested it for now). It seems that exclusion rules (ignore substitute) are cumulative. So first letters would be correctly replaced, but then the second rule will be limited to single-letter words (i.e. without a letter before - rule 1 - AND without a letter after - rule 2).

A simple solution to this problem is to isolate each rule into a dedicated lookup block :


lookup beginning_s {
ignore sub @ALL_LETTERS s';
sub s' by s.starting;
} beginning_s;

lookup ending_s {
ignore sub s' @ALL_LETTERS;
sub s' by s.ending;
} ending_s;

However, I did not tested using classes exactly as in the example, maybe the fact of using classes instead of single glyph also isolates contexts.

Hope this will help with this common issue, there are very little resources available on this topic.

Fred.

avangel's picture

Ok I just tried with the exact same technique as in the specs, and it doesn't work in FontLab. So the 'lookup' trick seems to be the safer way to accomplish that.

Syndicate content Syndicate content