Proper technique(s) for scripting OT/CFF

Alex Kaczun

I'm very close to completing a new italic font family and I want to have 2 alternate capital A(s), such that the main cap A works with set (all) capitals. And, the alternate (more slanted version) is substituted, on the fly, when typeset with lower case (in regular text). The italic angle of this font is slanted at about 16 degrees, and the regular cap A works well with the slanted capitals, but the lower case overall is even more slanted and thus requires a suitable alternate cap A to flow better visually.
I'm thinking that this should work as a ligature substitution, like any ffi ligature. If you typeset a cap A with (all) capitals the regular cap A is used, but if you typeset a cap A followed by lower case string, the alternate cap A (more slanted) version is used.
I know how to script for standard type stuff. But, this seems different somehow.
I remember reading somewhere (online) about scripting an elegant way for just this type of situation, but for the life of me, I cannot remember completely.
Can anyone supply this code and/or point me to the resource online.
Many thanks in advance.

Mark Simonson

What you need is a contextual alternate feature (calt). It would look like this:

feature calt {
sub A' @lowercase by A.alt;
} calt;

where "@lowercase" is a class containing all your lowercase characters and "A.alt" is your alternate A. (The tick mark indicates which glyph gets the substitution.)

Assuming you also want to include the accented forms, you would put all your A's into classes as well, and it would look like this:

feature calt {
sub @normalA' @lowercase by @altA;
} calt;

(Note to James: The formatting of the code tag is terrible. Does it really need that box around it? Could the text size be a little larger?)

Alex Kaczun

Thanks Mark. Very helpful indeed. Much appreciated.

This will work just fine.

I can't help but feel that there are several different ways to achieve this.

What I seem to recall reading online somewhere worked a little differently. I think?

If anyone else has an alternative approach, I would be interested in hearing it.

Thanks again Mark for your quick reply.

Mark Simonson

As far as I know, this is the usual way to do it, and I can't think of a way that's more straightforward.

You do have to pay attention to the order of your features. For instance, if you have a c2sc (caps to small caps) feature, and don't have an alternate small cap A, you would want it to come before this particular calt feature.

Nick Shinn

I would make the more slanted version the default, and put the all-cap version in the case feature. That way, it will be activated whenever text is set with the caps-lock key down, the all-caps feature selected, or “command-shift-k” (Mac) implemented.

It would not be implemented only in all-cap situations where text is input holding down the shift key all the time, which is not how people type.

IMO, this method is more basic and sturdy than using calt.
For instance, it doesn’t fail when tracking is increased.

Mark Simonson

That happens with calt? I thought it was just liga that was affected.

Nick Shinn

No, it happens in calt too.
calt was originally conceived for connected scripts, Caflisch in particular, which is why it was thought this behaviour was desirable. Unfortunately, it fucks up “pseudo random” etc. that also use the feature.
It’s particularly annoying for all-cap settings, which are often letterspaced.

Nick Shinn

feature case {
sub @A_source by @A_target;
} case;

A_source will be all your cap A letters, including those with accents, and A_target will be the corresponding all-cap versions. Name them A.case, Aacute.case, etc.

PabloImpallari

I faced a similar situation recently when making a baskerville italic.
Ended up putting the alternates in ss01 so people can decide when they want the traditional more slanted /A /V /W and when to use the updated, less slanted alternates.

Kent Lew

That way, it will be activated whenever text is set with the caps-lock key down,

Nick — I think you misspoke. {case} is not activated by the caps-lock key. Capitals input as capitals, whether through shift key or caps-lock, will not engage the {case} feature.

One has to apply a feature that specifically engages {case}, such as the other two options you mentioned — basically All-Caps (which is what the shortcut shift-command-K activates).

Even a Change Case conversion does not activate {case}, as it just substitutes the underlying character encoding.

Nick Shinn

Yes, my mistake.