Disappearing ligatures and contextual alternates

Grrrben's picture

If I apply a certain amount of tracking to, say, a paragraph of text, InDesign will turn off ligatures and contextual alternates (actually not in the OpenType menu within the character window but the way it type sets text in a document). A situation I'm not really happy with since I'm providing my typeface with these features not for nothing. Fortunately the ligatures and contextual alternates will remain when doing this in Illustrator. Does anyone know how this happen, or preferably, how to get rid of this happening?

k.l.'s picture

It is a special "feature" of InDesign ...


Grrrben's picture

Thank you Karsten. So it is a special setting of InDesign nothing can be done to within the font file itself? Like another OpenType feature which ignores/overrides InDesign's features.

k.l.'s picture

InDesign's behavior is nonsense, especially since it does not only affect liga but also calt. Think of a non-connecting pseudo-random font whose randomization is switched off as soon as the designer increases the tracking.  :(
Unfortunately I cannot think of a(n automatic) way to work around this behavior -- nor do I think that font developers should address applications' peculiarities.

Maybe bomb Adobe with feature requests (which would actually be an un-feature request).

Thomas Phinney's picture

I agree that an application preference or some way of turning this off would be nice.

I think the basic idea of breaking the ligature when the tracking gets too extreme is a reasonable one. I personally confirmed both the general idea and the specific values InDesign uses back before the behavior was introduced. I agreed with the engineer proposing the change that past a certain amount of tracking, having a ligature results in such deviant spacing that things tend to look better without the ligature.

Applying the same logic to 'calt' was a more unfortunate call. At the time, years ago, we believed that 'calt' would get used for what the feature specs originally suggested, making connecting alternate forms. Implicit in that, we thought, was the idea that the default forms would not be connecting. So overriding the connecting behavior in a connecting script when it got too heavily tracked "seemed like a good idea at the time." In retrospect, not so much, I must say.



James Arboghast's picture

Tom, if you cast you mind back to the first thread we had about web font embedding you may recall yourself questioning why several of us on that thread were grumbling about Adobe softrware given the great boon of the OpenType format.

My response was along the lines of, "I am grateful to Adobe for giving us a font format that allows me to realize dream projects."

I stand by that response. At the time I neglected to make a clear distinction between Adobe application software and the OpenType format. These are two quite different animals. It is Adobe application programs that disappoint me, not the OpenType format itself.

This thread provides one more example of the infuriating engineering standard of Adobe application programs. For me it includes other stuff such as the messed-up ergonomics and interface design of Adobe apps, their sheer stupidity at not being able to keep track of folder locations I use repeatedly, resource hogging, and generally unintuitive software design. Photoshop for example annoys me so much I only use it when no alternative app will suffice.

It's worth saying that Microsoft application programs are barely any better engineered than Adobe's.

I don't mean to hijack this thread. Just sayin', as a follow up.

j a m e s

k.l.'s picture

My post of yesterday night was a bit grumpy. I should clarify:
The idea that ligature substitution is switched off with increased tracking is a nice one. But it should be the font which defines up to which amount of tracking ligatures be applied. It depends on the design, e.g. the extend at which the f reaches out to the right. The amount could be a lookup-related flag.
Given fonts like Caflisch Script I can understand that switching off calt too was not regarded as problematic -- a connected script shouldn't be tracked anyway. The flaw is in the implicit assumption that calt is used in connected scripts only, rather than considering connected fonts as a subset of fonts that may use calt.  ;-)

Grrrben's picture

Thank you everyone for the extensive responses. Cheers!

charles ellertson's picture

Adobe's reasoning as expressed by Thomas sounds good. I wonder it the ligature breaking happens only when the ligature was formed by 'liga', as opposed to directly entered -- either by entering the Unicode value when one is assigned to ligatures, or directly selected from the glyph pallet?

There are other reasons to have this kind of layout engine behavior. Traditionally, ligatures weren't used above a certain size. I never much agreed with that one, but of course, in metal they also weren't generally available above a certain size.

If such a notion could be implemented (unbreaking only when created by 'liga'), it might cover the situation. Automatic ligaturing is only an aid to the compositor -- we used to have to spot them & set them ourselves.

Theunis de Jong's picture

Traditionally, ligatures weren’t used above a certain size.

Traditionally, tracking increases with size.

Since a ligature is drawn as two characters at a fixed distance, you cannot allow for tracking -- not unless OT has a major overhaul!

The OpenType 'size' feature could be put to good use here, except I understand it has a few implementation flaws that should be ironed out first. Then again, people might complain ligatures disappear at a certain size ...

Theunis de Jong's picture

That should be,

Traditionally, tracking decreases with size.

miha's picture

>But it should be the font which defines up to which amount of tracking ligatures be applied. It depends on the design, e.g. the extend at which the f reaches out to the right. The amount could be a lookup-related flag.

It does not need to be a lookup, because this functionality is already defined in OpenType for more than a decade now. Justification Maximum Table seems appropriate: [...] values define the maximum shrinkage or extension allowed per glyph. For example, a fi glyph.

Needless to say, there is no GUI in FontLab to specify proper amounts, but also no way to code it. Well, we can expect support for this thing in InDesign in decade or two. Hard to predict, really :-)

k.l.'s picture

You may have been attracted by the ffi example in the specs, yet JSTF is only meant to deal with justified setting (address too long or too short lines), it is ignorant of tracking defined by a user in a layout application.

(I said lookup-related flag, not lookup.)

miha's picture

You are right, I was probably attracted by ffi example (at first sight), and then desperately wanted to find appropriate table.

But … well, text is justified also if tracking is changed. But yes, even if it can be theoretically done, there is no mention of such usage in specification.

John Hudson's picture

It may be helpful to know how the InDesign algorithm for turning ligature features on and off relative to tracking works. I asked Eric Menninga about this at TypeCon this year, because it has implications for how to design ligating alternates (contextual variant letters that form on-the-fly ‘ligatures’, activated by ligature features).

The amount of positive or negative tracking triggering disabling of the ligature features is relative to the width of the /space/ glyph in the font. An increase of more than 8% of the width of the /space/ glyph turns off the ligatures, as does a decrease of more than 22% of the width of the /space/ glyph. That is to say, for a font with a /space/ glyph 200/1000 em units wide, the ligature features will turn off beyond +16 units tracking and -44 units tracking.

dezcom's picture


Syndicate content Syndicate content