Ligatures in OpenType: Discretionary vs. Standard

seanglenn's picture

So, my company bought one of the brand-new FontShop OpenType faces, FF Nexus, and as I was dropping it into our templates to test size and leading I noticed a very odd thing. As part of the standard ligatures, the s_t combination was included. This particular ligature is not one I expected to see in the standard set, especially since the discretionary ligatures contains the rest of the historical ligatures (c_t, f_s, etc.)

Of course, this causes a problem, as in order to get any ligatures, I have to turn on the standard set, but then I automatically get the s_t ligature. Which of course, I don't want.

FontShop has offered to fix this for me (very nice of them indeed) by removing the s_t ligature, but it's got me wondering, should there be a standard for OpenType of which ligatures should be in the standard set?

My preference for the standard set would be:


The discretionary set can contain the rest. I'd love to see a function built into InDesign that lets you set which ligatures the program uses, but I suppose that's another question entirely.

pablohoney77's picture

i'd love to see a function in InD that lets you set your own OT substitutions, but i doubt that'd ever happen.

Thomas Phinney's picture

Probably the st lig belongs in 'hlig' (which is activated alongside 'dlig' in current Adobe UIs).

There are a bunch of other rarer f-ligs sith letters such as b, j, k, and sometimes t. They are rare in the sense that most typefaces don't have them, but if present they would go in standard ligatures.

Also, once you get out of the realm of normal text faces, and push into things like script or handwriting fonts, there may be many more standard ligatures.

Finally, Adobe is fond of the "Th" ligature - as am I - and puts it in standard ligatures ('liga'). However, there is some debate as to whether it belongs in the standard ligatures or it should be discretionary. I prefer it in standard ligatures, myself.

Setting which ligatures the app uses would be interesting, but would have to interact with specific fonts. Maybe one of these days, though. You can always put in a feature request at:



pablohoney77's picture

Setting which ligatures the app uses would be interesting, but would have to interact with specific fonts.

Yes, exactly. It would be nice not just for ligatures, but for other substitutions as well, effectivly building your own style stylistic set for different fonts.

seanglenn's picture

Thomas, I agree that the st lig should be in the 'hlig' (that stands for historical ligatures, right?)

Since the OpenType panel shows which features are available, it seems like a little more coding would allow you to toggle specific sets of ligatures (sort of like the semi-functioning "fi, fl but not ffi ffl" ligature function in Quark 4 & 5).

Still not sure why FontShop added s_t to the standard ligatures. I hope that they drop that, otherwise I'm going to have to request custom versions of every OpenType font I get from them.

Thomas Phinney's picture

Yes, 'hlig' is historical ligatures.

If somebody making an OpenType font wanted to specify additional levels of ligatures, they could always use stylistic sets to do it.

As for FontShop, I wouldn't assume anything from one of their first OpenType fonts. It's probably either a bug or an individual designer's choice, not a long-term general policy decision by the foundry.



paul d hunt's picture

one problem with using the 'hlig' feature for discretionary ligatures is that Photoshop CS does not reference the 'hlig' feature. This might not be such a problem if there were a glyph pallete in Photoshop, but to my knowledge there isn't one.

ralf h.'s picture

>>>if there were a glyph pallete in Photoshop

That is a huge problem and the number one question of my customers. How do I get all your nice PUA characters into Photoshop? And I can't tell them anything else but: use the character palette or create the text in Illustrator an paste it into Photoshop …
I can't see any reason why InDesign and Illustrator have a glyph palette but Photoshop hasn't.


Michael Jarboe's picture

Yeah, it's crazy that in general there isn't more consistency between the Adobe apps regarding Type, especially that InDesign and Illustrator don't access OpenType features (especially Stylistic Sets) in the same way… not to mention the typesetting limitations within Photoshop, among other inconsistencies.

It's pretty ironic that a suite of 'design' programs that are meant to work together seamlessly are so poorly designed in regards to typesetting.

Bhikkhu Pesala's picture

The principle I use is, if a ligature is used to avoid unsightly classes then I include it in the Standard ligatures. If it has a distinctive swash or connecting stroke that distinguishes it from the letter pair, I include it in the Discretionary ligatures:


sub f f i -> ffi;
sub f f l -> ffl;
sub f f t -> fft;
sub f f y -> ffy;
sub f t y -> fty;
sub f f -> ff;
sub f i -> fi;
sub f j -> fj;
sub f l -> fl;
sub f r -> fr;
sub f t -> ft;
sub f y -> fy;
sub t r -> tr;
sub t t y -> tty;
sub t t -> tt;
sub t y -> ty;
sub longs t -> longst;

sub c k -> ck;
sub c t -> ct;
sub s p -> sp;
sub s t -> st;
sub t z -> tz;
sub Q u -> Qu;
sub T h -> Th;

Arno Enslin's picture

@ Bhikkhu Pesala

fi and fl (present in the standard encoding and with Unicode points), but (f_i and f_l [additionally and without Unicode in case of new Adobe fonts]) f_j, f_f and so on.

I likewise would put longs_t into the liga-feature, although it does not necessarily improve the legibility. The t in longs_t is often much more different in comparison to the single t, than b, i and so on are different in longs_b, longs_i and so on.

I don’t see any reason for putting the longs-ligatures into the hlig-feature. In case of P22 Stickley the longs-ligatures are even in the hist-feature (sub s i by longs_i), which is absurd in my opinion.

Generally I either would put each ligature, that improves the legibility and that is not just decorative into the liga feature or I simply would follow the way, that Adobe goes with regard to these features, because if everyone programs the features totally different, each font needs a manual and it is hard to switch from one font to another one.

charles ellertson's picture

It would be nice if InDesign -- or any layout program -- would allow custom selection of ligatures from all the ligature features. Of course, my theme song "let the end user modify the font" would resolve that, but FontFont has lately prohibited people who actually use fonts from using them to best advantage.

A good number of fonts could use more ligatures, esp. in italic: g_g, g_y, z_z, z_y, and so on. Sometimes roman too -- gg, as in "struggle" can appear as an awful blot. Adobe Jenson comes to mind, as seen in The Pacific (World War II as brought to you by the Venetians).

And never forget that Kafka was a halfhearted halfback . . .

William Berkson's picture

Note that some of this stuff can be done through substitutions and kerning. For example, the gj that Frode mentioned at the moment looks awful in the flash title here in Williams Caslon Text-Italic, but with the kerning that is in the font—and doesn't show in flash—it forms a reasonable looking ligature.

If I remember rightly John Hudson has argued that in general it is better—because of tracking—to have contextual alternatives combined with kerning instead of substitutes of ligatured glyphs. Interesting idea.

filip blazek's picture

Using GREP you can control which ligatures can appear in a text. Simply: apply Character Style 'liga' or 'dlig' to particular glyph combinations:

Find: fi|ffi|fl|ff
Replace: Character Style 'liga'

Find: Th|gg
Replace: Character Style 'dlig'

You have to set your Character Styles before - just turn on the required OT feature. Using nested Paragraph styles, you can easily apply the rules to several Paragraph Styles at once.

John Hudson's picture

because of tracking

Not primarily because of tracking, although tracking can be better accommodated using a non-ligature approach. Contextual alternates generally result in a smaller, more efficient glyph set than ligatures, and easily produce arbitrary combinations of e.g. diacritic glyphs in 'ligated' sequences which would require hundreds of ligatures. In fonts that support GPOS mark positioning, using contextual alternates avoids the complexity of enumerated anchor attachments on ligature glyphs.

Thomas Phinney's picture

I second Arno and John's comments above.


Syndicate content Syndicate content