TeX - LaTeX Stack Exchange is a question and answer site for users of TeX, LaTeX, ConTeXt, and related typesetting systems. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

In several documents I'm creating with LuaLaTeX (using MacTeX2012 on a Mac that's running MacOS X 10.7.5), I primarily use the Adobe-issued font Garamond Premier Pro as the main text font. I use this font because it provides a slew of

  • "Common" ligatures: These comprise not only the five TeX-standard f-ligatures, viz., ff, fi, fl, ffi, and ffl, but also ligatures for ft, fft, fb, ffb, and a few more; and

  • "Rare" (aka "Discretionary") ligatures: For this particular font, "rare" ligatures are available for the character pairs ct, st, sp, and ft (but not fft; see also below) in both upright and italic shapes, as well as for the character pairs as, is, us, at, et, th and a few more in the italic font shape only.

If just the "Common" ligature set is enabled (via the option Ligatures=Common), the ft and fft groups, in both upright and italic shapes, are typeset like this:

enter image description here

Just in case this matters, the Unicode character representations for these ligatures are U+E18D and U+E187, respectively. In the upright font shape, the "glyph id" numbers are 277 and 271 and the "character codes" are 57742 and 57735, respectively. In the italic font shape, the Unicode character representations are the same, but the "glyph id" and "character code" numbers are 283 and 276, and 57864 and 57857, respectively.

However, if the "Rare" ligature set is enabled -- irrespective of whether the "Common" ligature set is enabled as well -- the ft and fft character groups are rendered as follows:

enter image description here

(Aside: For another rendering of the "rare"-style ft-ligature, check out the web page Garamond type ft-ligature.)

Not only does the "Rare"-style ft ligature look rather different from its "Common"-style counterpart, the fft ligature no longer exists at all: the fft character triple is now rendered as a plain "f" followed by the "Rare"-style ft ligature. For my purposes, the absence of a ligature for the fft character triple if "Rare" ligatures are enabled is rather unfortunate. The fact that the crossbars of the "f" and "ft" glyphs don't line up properly in the italic font shape is also rather problematic. Separately, I also prefer the look of the "Common"-style ft-ligature to that of its "Rare"-style counterpart, but that's only a secondary concern. (Incidentally, the Unicode character representation for the "Rare" ft-ligature is U+E18E. In the upright font shape, its "glyph id" and "character number" codes are 278 and 57742, resp.; in the italic font shape the latter two numbers are 283 and 57864, resp.)

My question is: Is there a way -- preferably using macros provided by the fontspec package -- to disable the "Rare"-style ft ligature globally in order to re-enable the "Common"-style ft ligature -- while still being able to use all other "Rare" ligatures as well as the "Common" ligatures?

Just for completeness, here's the code that generates the first example above:

% !TEX TS-program = lualatex
    ItalicFont={Garamond Premier Pro Italic}]
    {Garamond Premier Pro}
ft fft \em ft fft

To generate the second example, replace the option Ligatures=Common with Ligatures={Common,Rare}.

share|improve this question
One consideration is that typesetters historically eschew ligatures when they span components in a compound word, and the only English words I can think of that include "fft" ("offtrack", "offtake") are such...I think typesetters would use the "ff" ligature and liberate the "t" in both cases. I know this is not an answer, but it may explain why some foundries don't bother with "fft"...? – commonhare Jan 9 '13 at 6:52
@commonhare - I think your conjecture is correct. I should have mentioned, maybe, that some of my documents are either in German or mixed German/English. In German, there's definitely a need for an fft ligature, for words such as "gerafft" and "geschafft", to go along with the ft ligature. Of course, historically accurate typesetting of old German documents would call for the use of blackletter (e.g., "Fraktur") fonts... – Mico Jan 9 '13 at 11:55
small warning ... the unicode values cited here are in the "private use area", so don't expect that the shapes found at those locations in other fonts will necessarily be the same. – barbara beeton Jan 9 '13 at 14:33
That is a font bug, the ligature lookups are ordered wrongly; the longer ligature lookups should precede the shorter ones (in the font) or they will not get applied. One possible way way to fix this is using an OpenType feature files, defining lookups that revert the unwanted ligature. – Khaled Hosny Jan 9 '13 at 15:26
@KhaledHosny - Many thanks for providing this insight. If you wouldn't mind writing this up as an answer (preferably with an example of an applicable OpenType feature file), I'd very much appreciate it (and will upvote&accept it). – Mico Jan 9 '13 at 15:59
up vote 14 down vote accepted

Some thing like this using feature files should work:

First the feature file:

# scripts and languages, if the font use others they should be defined here too
languagesystem DFLT dflt;
languagesystem latn dflt;

# this undoes the effect of rare ligature on ft
feature liga {
  sub f_t.alt by f t;
} liga;

# move rare ft to historic ligatures
feature hlig {
  sub f t by f_t.alt;
} hlig;

# apply the regular ligature on ft and fft
feature liga {
  sub f f t by f_f_t;
  sub f t by f_t;
} liga;

The order of the above is important, this way regular “ft” and “fft” are used even with Rare ligatures, but not with Historic.

The glyph names should match those in the font with f_t.alt being the name of the unwanted “ft” ligature, and f_t & f_f_t being the names of the wanted ones.

The full feature file syntax is documented by Adobe (but LuaTeX supports v1.6 f the syntax + FontForge extension, not the current one, so there are some differences).

Then it can be applied to the font by using FeatureFile fontspec option:


\fontspec[Ligatures={Common,Rare},FeatureFile=test.fea]{Garamond Premier Pro}
ft fft \em ft fft

\fontspec[Ligatures={Common,Rare,Historic},FeatureFile=test.fea]{Garamond Premier Pro}
ft fft \em ft fft
share|improve this answer
Thanks! This answer certainly looks like it should work. Unfortunately, your conjecture that "uniXXXX (with XXXX being the hex Unicode value) might work" for the glyph id doesn't seem to apply, at least not for the font at hand (Garamond Premier Pro). Any other suggestions on how I can pass the correct glyph ids to the feature file? (I listed the unicode codes, character codes, and glyph ids in the body of the question.) – Mico Jan 13 '13 at 14:49
You need glyph names not ids, you can get the correct glyph names by opening the font in a font editor. – Khaled Hosny Jan 13 '13 at 15:23
Success at last! I had to install fontforge (which, in turn, necessitated downloading and installing Xcode and macports...), and learned that the glyph names I need are f_t, f_f_t, and f_t.alt, respectively. I'll modify your code to include this information, just in case someone else ever has to undertake something similar. Incidentally, it turns out that it's not possible to assign f_t.alt to the "historic" ligature group as no such group is currently set up for this font... – Mico Jan 13 '13 at 19:08
@Mico: Even if there is no hlig feature in the font, adding one in the feature file will work (I tested that with another font and I know it works). – Khaled Hosny Jan 13 '13 at 19:45
Thanks for clarifying the relationship between the work of the feature file and the (prior) absence of an hlig feature for a given font. Maybe I got misled by yet another bug in the font Garamond Premier Pro when I concluded that it couldn't be done? (I've been aware of at least one more bug with this font: the italic font that's selected by default is the "Italic Semibold" variant, not the regular-weight variant.) – Mico Jan 13 '13 at 20:32

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.