Contextual Alternates in a Variable font

Scripting
1

Hi all,

My question is whether contextual/stylistic alternates can work between characters that have different axis values? Some context below:

I’m playing around with a variable font with 2 stylistic axes, such that in practice I’m changing values on a character-by-character basis — for example I might have an /a/ set to “axis1:50 axis2:0” next to an /n/ set to "axis1:20 axis2:80.

This all works fine, however the problem I’m having is that I want to sub a’ e with an alternate /a/ style. When exported and used in variable font-capable adobe apps, the contextual alternate only kicks in when the variable settings of the two characters are identical. So /a/“axis1:50 axis2:20” and /e/“axis1:50 axis2:20” works, however the /a/ reverts to the default glyph when the settings are mismatched — /a/“axis1:50 axis2:20” and /e/“axis1:50 axis2:30”/. Is there a way to have contextual alternates work globally in an axes-agnostic manner?

Happy to be pointed towards another thread/tutorial if this idea has been covered and I’ve missed it,
Thanks

2

You can use an alternate a.calt with bracket layers. This way, lowercase a can change in the context of other letters. IIUYC this is how far you got, right? This solution is axis-agnostic. The problem is that you will not find a layout engine that deals with this the way you expect it to. Generally, if the formatting changes, the context limit changes as well. Same as changing the font or changing the color.

3

Thanks for the reply,

I’m using an a.alt but just with a simple substitution — sub a’ e by a.alt. How would the bracketed layers be set up differently? I’ve read the tutorial on bracket layers for interpolation, but not sure I understand how this would be set up to create a contextual alternative.

To be honest I was expecting that the different formatting would break the context rule irretrievably as you mention, but just wondered if there was a trick out there to get around it. Willing to try the bracket thing just to see what happens if I can get my head around it though.

4

The problem is that if you change anything on the formatting, the context for OpenType features stops there. So, I think there is not much you can do.

5

Just to point out that the main restriction to this comes directly from the OTSpec. From the last paragraph on this section:

…layout processing implementations must treat different variation instances of a variable font as distinct style runs for purposes of OpenType Layout processing.

Which is a shame, but also a very difficult problem to deal with if done otherwise. On the web one could potentially tailor some code to a specific functionality for a specific variable font. But then that is very limited in scope.

Cheers