I am trying to compose a sort of old-style book. I would like to use a specific historical font for the entire text. This font includes ligature glyphs for: ff, fi, fl, ffl, and st (see Figure 1 for the italic style).

Map of characters

Unfortunately, XeLaTeX and LuaLaTeX seem not to recognize the presence of ligatures. I tried the following simple code.

% !TEX TS-program = xelatex

ff fi fl ffl st

Unfortunately, the LaTeX result is without ligatures (the same occurs with the light style of the font). On the other hand, different fonts (e.g. Linux Libertine) work correctly. I tried also to install the font in LaTeX system but I did not obtain any result (the font works but not the ligatures).

Do you know any solution?

Another (and secondary) question. Some interesting glyph (as ct, us, and as) are present. I have no idea, how to integrate them in the LaTeX code. I would like to type words using those glyphs without particular declarations.

For your information: I use a fully updated TeXLive on Windows 10 (x64).


Thanks for all answers. It works fine, but I would deepen the matter with the LuaLaTeX code. If I had more than a single font in use (e.g. ITALIC.otf and ROMAN.otf), how could I have adapted the Lua-code for lacking glyphs in different fonts? Let me explain through an example: The ligature glyph is (uchar(916)) exists for ITALIC.otf but not for ROMAN.otf. In this way, the simplify code:

% all your LuaLaTeX-code
is \textit{is}

produces a PDF uniquely with the italic is (the roman is is missed). I suppose, that LaTeX tries to search the ROMAN glyph uchar(916) instead of inserting the ROMAN glyphs of i and s. Do a solution exist? Thanks again for your attention.

  • Is use of XeLaTeX or LuaLaTeX required?
    – 1010011010
    Commented Aug 18, 2015 at 17:37
  • 3
    Get the Fell types, with OpenType features, from iginomarini.com/fell/the-revival-fonts Then it will suffice to use \setmainfont{IM FELL English PRO}[Ligatures=Rare] (but there is no discretionary st ligature, only ct, as, ij, is, us…).
    – Thérèse
    Commented Aug 18, 2015 at 17:49
  • 1
    @GranducaPlinio - Regarding the questions you raise in the follow-up comments: The reason I found it necessary to come up with some highly font-specific Lua code in my answer is that the name table of the font Historical-FellTypeItalic is, to put it politely, highly non-standard. If you have other fonts whose name tables are also non-standard, more specialized Lua code will almost certainly be needed to activate their ligatures. The real solution, in my view, would be to clean up and re-release the fonts, now standard-adherent name tables.
    – Mico
    Commented Aug 30, 2015 at 17:06
  • 1
    @GranducaPlinio - I'm afraid I'm not sure what my recommendation would be regarding what you may want to do if several fonts have messed-up name tables. (My LuaLaTeX-based answer was tailored to one specific font.) I also don't know if FontForge is the best tool for cleaning up a messed-up name table. (There's probably more than one may to mess up a name table, right?!) Maybe the best thing to do, at first, is to contact the authors and maintainers of the fonts and -- assuming they can be identified -- ask them if they happen to have a version of the font(s) with standard name tables.
    – Mico
    Commented Aug 30, 2015 at 18:15
  • 1
    There’s a solution to the problem with accents at tex.stackexchange.com/a/203153/7883
    – Thérèse
    Commented Sep 2, 2015 at 10:44

2 Answers 2


The problem with this font -- as far as its ligatures are concerned -- is that the ligature names in the internal font table are, shall we say, utterly non-standard. For instance, instead of going with standard names such as f_f and f_f_i for the ligatures, a search with the FontForge app reveals that the font uses the names Omega and approxequal. No joke!! (A not-uncharitable assessment of the situation might be that the font's name correspondence table got garbled at some point prior to compilation.)

Given this situation, it's probably not a surprise that LuaLaTeX and XeLaTeX are not able to figure out the name mappings without special help.

Using LuaLaTeX, I can think of two solutions to this mess. The first solution creates a custom "feature file", which informs the system about the ligature names actually used by the font. The second, shown further below, uses LuaTeX functionality directly to get the ligatures working.

With the help of FontForge I was able to find the "names" for all ten ligatures. These names are used to set up a so-called "Feature File", named addligs_HFTI.fea, that can be loaded via an instruction such as \addfontfeatures{FeatureFile=addligs_HFTI.fea}.

Unfortunately, despite having found the font's ligature "names" for all ten ligatures, this approach succeeds in activating only four of them (ct, ff, ffi, and ffl, to be specific). Maybe something else got garbled as well when the font was compiled?

enter image description here

% !TEX TS-program = lualatex

languagesystem DFLT dflt;
languagesystem latn dflt;
# Ligatures
feature liga {
    sub a s   by summation;
    sub i s   by Delta;
    sub u s   by divide;
    sub c t   by plusminus;
    sub f f   by Omega;
    sub f i   by fi;
    sub f l   by fl;
    sub f f i by approxequal;
    sub f f l by radical;
} liga;

\newcommand\liglist{as is ct ff fi fl ffi ffl}

w/o ligatures: \liglist

with ligatures: \liglist

Addendum. Given that the feature file approach doesn't succeed in activating all ten ligatures present in the font, the following solution, which is entirely coded in Lua, may be worth considering. It uses the process_input_buffer callback to run a function that performs a "brute force" substitution of the ten character pairs and triples with the corresponding glyphs that represent the ligated versions. (Full disclosure: The code used below gratefully uses code originally provided by @michal.h21 in his answer to my recent posting, entitled LuaLaTeX: How to use a \char directive inside a string.gsub function?) Observe that special care had to be taken to ensure that any LaTeX macros that may include strings such as "ff", "fi", etc aren't caught up in the brute-force substitution.

enter image description here

% !TEX TS-program = lualatex

local uchar = unicode.utf8.char
function ligsub ( s )
  local x = s:gsub('(\\?)([%a%@]+)', 
            if back~="" then 
               return back .. text  
            text = text:gsub ( 'ffi', uchar(8776)) 
            text = text:gsub ( 'ffl', uchar(8730))
            text = text:gsub ( 'ff',  uchar(937))
            text = text:gsub ( 'fi',  uchar(64257))
            text = text:gsub ( 'fl',  uchar(64258))
            text = text:gsub ( 'as',  uchar(8721))
            text = text:gsub ( 'is',  uchar(916))
            text = text:gsub ( 'us',  uchar(247))
            text = text:gsub ( 'ct',  uchar(177))
            text = text:gsub ( 'st',  uchar(9674))
            return text
  print("x", x)
  return x
    \directlua{luatexbase.add_to_callback (         
              "process_input_buffer", ligsub, "ligsub" )}}

\newcommand\off{off}  % dummy macro (see below)

off fit fly office baffle

as is us act step

\off --note: no ff-ligature

Remark: The only downside I can see to taking this approach is that it's definitely going to mess up the work of a screen-reader: eight of the ten ligatures -- those for ff, ffi and fl, as, is, us, ct, and st -- get rendered as Ω, , , Σ, Δ, ±, and , respectively. Argghh. (In contrast, fi and fl do get rendered correctly; probably not coincidentally, those are the two ligatures that have a "normal" name in the feature file, which was shown earlier.) That's not really the fault of the LuaLaTeX-based approach, though; rather, the font's messed-up name tables are to blame. Ideally, the authors and/or maintainers of the font would re-release it, this time with the name table cleaned up drastically.

  • 1
    Unfortunately, anyone using a screen reader or searching or copying will get unintelligible results; the feature file affects only the appearance of the text. Better to use Igino Marini’s fonts than to spend time repairing this version, though note that even Marini’s fonts could use some fixing (tex.stackexchange.com/a/203153/7883).
    – Thérèse
    Commented Aug 18, 2015 at 19:46
  • @Thérèse - I'm afraid I have no experience with screen readers. However, searching for, say, "ffi" or "ffl" in the pdf file seems to pose no problem at all. Likewise, copying the ligatures from the pdf file into a plain-text file also doesn't seem to generate any untoward surprises.
    – Mico
    Commented Aug 18, 2015 at 19:51
  • Hmmm. I wonder if there’s something going on that varies by operating system. I just tried your example (I had been loath to install that badly made font on my system), but I get no ligatures at all. GNU/Linux, with a vanilla TeX Live 2015, updated a few hours ago. I’ve fixed other fonts with feature files, but this one won’t cooperate.
    – Thérèse
    Commented Aug 18, 2015 at 20:08
  • @Thérèse - Interesting. FWIW, I have a MacBook Pro running MacOSX 10.10.5 and MacTeX2015.
    – Mico
    Commented Aug 18, 2015 at 20:10
  • Your second approach is interesting and works on my system — not for accurate searching and extraction of text, but at least for display of the ligatures. It’s curious that the usual approach didn’t work (has anyone tried it on Windows?): according to otfinfo, the font is a 1994 production of the Hoefler Type Foundry, apparently an early incarnation of Historical Allsorts (typography.com/fonts/historical-allsorts/overview). Maybe it’s one of Apple’s versions of Hoefler fonts?
    – Thérèse
    Commented Aug 23, 2015 at 12:19

It turns out that your font is freely available. As I suspected, the font doesn't have OpenType features (screen capture from FontForge):

enter image description here

What's worse, the font is not a Unicode font. It has replaced various code points with ligatures. If you want to, you can access the ligatures by typing the characters that occupy those slots according to the Unicode standards:

O≈ce ◊ar

Or define more sensible shortcuts:

O\ffi ce \st ar

enter image description here

  • there seems to be an opentype implementation of the fell types, downloadable from a link at iginomarini.com/fell/the-revival-fonts ; the missing information about ligatures might be available with those fonts. Commented Aug 18, 2015 at 17:55
  • @barbarabeeton And of course there's no fj ligaure .. :(
    – Sverre
    Commented Aug 18, 2015 at 17:59
  • 1
    no fj ligature -- true. but i think in the 17th century, the british weren't writing much about fjords. (a pity!) Commented Aug 18, 2015 at 18:05
  • @barbarabeeton The thing is, revivals of old fonts from Western Europe tend to "modern" them up by including various characters used in the modern Scandinavian and Slavic languages, but they very rarely think of our ligatures ...
    – Sverre
    Commented Aug 18, 2015 at 18:08
  • 2
    the problem, as i see it, is that the other "f" ligatures are present in unicode (although it's because they were grandfathered in, rather than because the unicode technical committee thought they really deserved it on their own), so most font "modifiers" probably don't even think about adding an fj. maybe some pressure could be applied there ... i'll ask my contacts. Commented Aug 18, 2015 at 18:12

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .