Contextual Alternates button/option in Illustrator & InDesign

Ramiro Espinoza

Hi there,

I don't understand why the "Contextual Alternates" button/option in Illustrator & InDesign it is not blocked in the interface.
It is activated by default, which is fine BUT if the user copy-paste text frames that belong to fonts without the feature or change the font assigned to the frame a couple of times, the feature can de-activate resulting in a malfunctioning font.

It is a pain to explain all these things to clients when you make a font hat really take advantage of the "Contextual Alternates" possibilities. In my opinion it should be more an icon indicating the feature is present...

Any thoughts on the subject?

Paul van der Laan

I know it is bad practice, but for these cases I have usually put the same feature code in both CALT and LIGA. Sort of a catch all.

Ramiro Espinoza

Thanks for tip, Paul. I will try to combine the CALT with the LIGA and see what happen.

Kent Lew

Is that really true? I’ve never encountered a case where changing to a font without {calt} deactivates the feature. In InDesign at least, typically when a feature is active and then the font is changed to one that does not have this feature, the feature is bracketed out and ignored. But the on/off state of the feature does not actually change as a result of a font change, such that if you later change that string to a font which does have the feature, it comes back into play again.

This can indeed lead to unexpected behaviors, but changing the font isn’t the cause of feature-state changes (at least not that I’ve ever experienced, and I just tried unsuccessfully to recreate this issue).

Rather, the activity that usually is responsible for turning off {calt} and {liga} is inserting a glyph from the glyph palette. When this is done, Adobe always turns off both of those default features. How this can affect other text is tricky and can be difficult to predict.

Basically, if one inserts a glyph at the end of a string and immediately resumes input, then {calt} and {liga} will only be off for that single inserted glyph and will not be inherited by the rest of the text. The same is true if one highlights an existing glyph and substitutes from the glyph palette; surrounding text is not affected.

If, however, one inserts a glyph, navigates away in certain ways, and then returns to the insertion point following that glyph, now any subsequently entered text will inherit the off condition of {calt} and {liga}.

I believe that under certain circumstances (the details elude me), the off state can be carried to an end of paragraph marker. This might lead to copy-paste text carrying the off state with it and other unexpected behaviors. But again, in my experience, the original culprit is a manually inserted glyph. That’s the primary action that turns off {calt} and {liga}.

John Hudson

Are you aware of some reason for that behaviour, Kent? I find it incredibly annoying, and since other OpenType Layout features are not disabled by glyph insertion, I don't understand why these should be.

Ramiro Espinoza

@Kent: I think you are right. I assumed the CALT feature was de-activated due to font changing but probably is because of Glyph window usage. But I think the situation stay more or less the same. A user should be able to use the Glyph palette without having to click again the CALT feature.

Kent Lew

John — I do not have any official explanation. For that you’d have to find someone at Adobe (and probably part of the InD team) who knows definitively.

My assumption has been that it has to do with how manually inserted glyphs are handled by the application. In the absence of a Unicode point (i.e., for stylistic alternates), the application has to find some way of capturing the desired glyph and representing it in the text string.

At one point in its evolution, I believe that InD relied upon the GID; but later evolved to attempting to use an underlying feature. (I could be wrong about this shift, as it could instead be an evolution of my conceptual understanding, rather than the actual implementation; but I could swear that CS3 used GIDs.)

Since the app isn’t using pure GIDs and is relying on feature relationships, my guess is that InDesign turns off {calt} and {liga} because it doesn’t want any potential feature interaction interfering with the representation of the glyph being placed in the text. For instance, I can imagine that if {calt} was left on and someone tried placing a glyph that was a target of {calt} and got changed, such that the user wasn’t getting the glyph they thought they were inserting, then they’d be pretty miffed and blame a buggy application. So, turning off {calt} and {liga} is probably a butt-covering attempt to give the user what they seem to want.

Why {calt} and {liga} specifically, while seemingly leaving other features on? — I can only assume it has something to do with the GSUB types of these features. I note that there is a correspondence between these two being targeted for deactivation and the fact that these are the two features which are not represented by subsets in the Glyph palette.

Obviously, other features, especially stylistic sets, can have contextual or many-to-one GSUBs, but those two — {calt} and {liga} — are reliably predictable. And in fact, if a stylistic set includes contextual GSUBs, it will not be offered as a subset option in the Glyph palette.

I have not tested to see if when a sset with contextual GSUBs is on and a glyph is manually inserted whether InDesign might think to turn that one off for similar reasons. Probably not quite that smart.

Those are my best guesses as to why this extremely annoying behavior is there.

Kent Lew

P.S. I just checked and it seems to turn off {dlig} as well as {calt} and {liga}. We just don’t worry about that, since we don’t expect it to be on by default.

Kent Lew

A user should be able to use the Glyph palette without having to click again the CALT feature.

Ramiro — I agree. And in many cases, the user doesn’t have to turn it back on. As I said, in many commonplace circumstances, the deactivation of {calt} and {liga} is only localized and does not affect surrounding or subsequent text.

But there are certain circumstances when the deactivation does get inherited — and that’s the source of the annoyance. It doesn’t always happen, and it can be hard to predict, and that’s why it’s so problematic.

John Hudson

I think a more sensible approach would be to turn off only those GSUB features in which the inserted glyph is an input in lookups. That would avoid the circumstance of an explicitly inserted glyph being transformed by layout features, while not inconveniencing users but turning off a whole group of features that might not relate to that glyph at all.

Kent Lew

I agree; your suggestion would be a more precise approach. But it probably wouldn’t completely eliminate potential problems.

The root issue here is the fact that feature activation is a character-level attribute and InDesign has somewhat inscrutable inheritance patterns. Under certain circumstances, all sorts of unexpected or unintended inheritances can cause problems.

Surely we’ve all had the experience of editing some text that has an italicized word or phrase in it and, when working in proximity to the italics, accidentally picking up the inherited formatting. In these cases, it’s usually readily apparent and we can reset the relevant attribute. But in the case of OpenType features, it is not always so immediately obvious.

I’ve seen plenty of similarly annoying situations with regard to stylesheets, where highlighting & editing or copying & pasting can pick up unintended inheritance and lead to hidden misbehavior.

As I’ve pointed out, the most commonplace methods of getting a special character into text don’t have any widespread effect on feature (de)activation.

If you’re typing along and then go to the glyph palette to insert a special character from the glyph palette and then immediately continue typing, the deactivation is only applied to the inserted glyph and is not inherited by subsequent input. And if you go into existing text and insert a special character (or highlight and replace a character), the deactivation will only apply to the inserted glyph(s) and will not “infect” the surrounding paragraph.

But when you get into the realm of editing & re-editing or cutting/copying & pasting, then you have to be wary of inheritance mischief.

The conclusion I’ve come to regarding this issue is: The more you can reduce the need (or temptation) for your users to have to go to the glyph palette to get the setting they want, the more robust and reliable your feature-interaction will be. (And there will always be a subset of inveterate tinkerers for whom all bets are off.)

Mark Simonson

This would explain some maddening behavior that can happen with Bookmania in InDesign. I've got multiple alternate ligatures, and the only way to use some of them is to insert them from the Glyph palette. However, doing that turns the ligature feature off, and you have to turn it back on to get the alternate ligature glyph to display.