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?
0
Comments
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}.
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.
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.
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.)