Take the 2-minute tour ×
TeX - LaTeX Stack Exchange is a question and answer site for users of TeX, LaTeX, ConTeXt, and related typesetting systems. It's 100% free, no registration required.

I'm starting to put together a LaTeX package, which I hope to distribute broadly, that

  • provides lualatex code to disable ligation of character pairs and triplets for selected words (globally within the document for all selected words, but not globally over all possible ligature instances);
  • provides a pre-assembled list of English-language words for which TeX's f-ligatures -- f-f, f-i, f-l, ff-i, and ff-l -- should be suppressed (note that there are seven ways that ligation suppression can occur: f-f, f-i, f-l, ff-i, ff-l, f-fi, and f-fl);
  • provides the proper kerning amounts, which can be quite different from zero, separately for each of the seven different ways of disabling ligation and for each of the following font families

    • Latin Modern,
    • selected font families of the tex-gyre font group, and
    • (possibly) selected other opentype font families as well

    for regular (upright), bold, italic, and bold-italic font shapes;

  • provides reasonably straightforward mechanisms for users to add additional words to the default list as well as to define their own ligation exception lists for ligature pairs and triplets not among TeX's "standard five" f-ligatures.

Before going too far along in the process of creating this package, and risking having to start over more or less from scratch after releasing a first version of the planned package and getting user feedback, I thought it might be worth pausing and soliciting suggestions and requests (and discouragement too!) from interested members of this group as to the features they'd like to see in such a package.

Background

I take it for granted that users of this group know that TeX (i) provides mechanisms for automatic ligation of the "ff", "fi", "fl", "ffi", and "ffl" character combinations and (ii) provides not just one but four [4!] mechanisms for suppressing ligation feature on an ad-hoc, i.e., instance by instance basis; see, e.g., p. 56 of Eijkhout's book TeX by Topic. Interestingly, one of the four methods -- inserting an empty brace group, {}, between the characters in question -- does not work in xe(la)tex and lua(la)tex, i.e., ligation is not suppressed if this method is employed.

In the TeXBook, Knuth cites "shelfful" as a word for which the "ff" ligature should be suppressed. The general principle that suggests/requires ligation suppression may be expressed as: ligatures should/must not cross morpheme boundaries. Morphemes, loosely speaking, are the smallest linguistic units (whether words or word particles) that contain distinct meaning, as in "shelf" and "ful[l]" in the preceding example. Other candidate words -- I've assembled well over a hundred such words in the meantime -- are "selfish", "halflife" and "pdflatex" (ouch!), "stuffiness", "scofflaw" and "cufflink", "wolffish" (yes, there is such a beast), and "safflower", to name some examples of each of the other six cases for which ligatures ought to be suppressed.

To the best of my knowledge, there exists no general method yet that allows TeX/LaTeX users to create a ligation exception list that could be loaded, say, in the document's preamble and which offers a "turnkey solution" to the various issues related to ligature suppression. (For instance, if ligation is to be suppressed for "f-l" for some group of words, the kerning amounts needed to obtain the proper amount of separation between the "f" and "l" character can differ considerably depending on (i) the font family in use and (ii) whether the text is set in an upright, bold, italic, or bold-italic shape.) Thus, writers are left to their own devices and, more often than not, fail to suppress ligation when needed. Incidentally, whereas this problem is generally not too virulent in English-language documents, it seems to be far more serious in other languages, such as German, which feature composite words much more frequently.

Of course, the failure to suppress ligatures selectively for certain words is not an issue that's confined to TeX and LaTeX. Many general-purpose word processing packages, including Word, either don't offer ligation at all or they require it to be enabled via some set of menu choices that most users are apparently not even aware of. (And, once it's enabled, most users don't seem to know how to disable it selectively for certain words...) Whereas some "professional" packages, such as Adobe's InDesign, do offer the option to enable character ligation globally, they do not seem to offer a method for specifying a list of words in advance for which character ligation should be suppressed.

Open Questions

I'd like to solicit your opinions, advice, and comments on the following issues:

  • The code I have to instruct TeX to suppress ligation for a specified list of words is based on lua(la)tex. Hence, the package requires the luatex engine; it will not run under either pdf(la)tex or xe(la)tex. [See the answers to the questions Can one (more or less automatically) suppress ligatures for certain words? and Porting the luatex/ConTeXt module "translate" to lualatex for details on the lualatex code involved.] Given that many (most?!) LaTeX users don't even seem to know about lualatex yet (and many still use the .tex -> .dvi -> .ps -> .pdf route, i.e., don't seem to be familiar or comfortable with pdf(la)tex), is requiring lualatex effectively going to kill the package's usability for all but a tiny minority of TeX users? Or, is it safe and/or reasonable to assume that even though lualatex may not exactly be in widespread use at the present time, it will be used more commonly in two or three years, say?

  • Are there already lists of words for which f-ligatures should be avoided, whether in English or in other languages? I'm not aware of such lists, leading me to assemble my own list of more than a hundred such words in the meantime. However, if anyone is aware of such word lists -- especially if they're accessible to the public -- I'd really appreciate knowing about them.

  • How important might it be to make the package usable for users of fonts other than Latin Modern? Obviously, with hundreds (thousands?, tens of thousands?) of opentype fonts in existence, many of which feature at least the set of five f-ligatures, it's quite impossible for me (or anyone else!) to maintain a list of the kerning amounts neede to fix the ligation exceptions for all of these fonts. Of course, I'll include Latin Modern as well as some of the fonts in the TeX Gyre distributions for treatment in the package. Which other font families should I consider?

  • Suggestions for font families for which not to bother with creating ligation exception adjustments? For instance, some font families have a lowercase-f with a very pronounced right-overhang; in these cases, suppressing the "f-i" and "f-l" ligatures would require moving the "i" and "l" characters so far over to the right, to avoid a collision with the "f", that an ugly visual hole or gap inside the word would result -- creating an even worse typographical problem.

  • Any suggestions for a snappy and/or catchy name for this package?!

Comments and suggestions on other topics -- as long as they're related to the issues at hand -- are obviously also welcome!

Addendum: I've followed up on Mark Everitt's suggestion and found doncherry's question, over in English.SE, about words for which ligation should be avoided. I've posted my current list of such words as an answer to doncherry's question.


Second Addendum: It's been suggested I provide the following piece of information, for anyone who comes across this posting and might be wondering if anything has come of the announced efforts. The comments and answers I received were, in fact, extremely helpful in the creation of the selnolig package. This package performs automated selective ligature suppression for German (f-ligatures, aka common ligatures, only) and English (common and rare ligatures) language documents. This package is fairly stable now but still subject to various potential improvements. Comments and suggestions always welcome!

share|improve this question
1  
Really interesting! I saw a question pop up on the English SE about this recently. Was that you? –  qubyte Dec 7 '11 at 14:04
4  
You could call it "ffs" (for F%&k's sake). A bad joke, I know. –  qubyte Dec 7 '11 at 14:07
1  
It was doncherry. –  qubyte Dec 7 '11 at 14:09
2  
I think this is a really interesting project, but I'm not sure it's suitable for this site. What would a good answer to this question involve? Maybe the LaTeX community forum would be a better fit? –  Seamus Dec 7 '11 at 14:33
2  
Even though you can't compile a list of kernings for all fonts in existence, it would be helpful to provide a test document, which uses a for-loop to typeset common "problem words" with different kernings. That way, any user can put their own \setmainfont at the top of the file, and quickly inspect the output to see what the best value for their font is. You also might want to use e.g. GitHub to allow users to easily submit the kernings for their favorite font – that way you could ship a reasonably large list of defaults without having to generate it yourself. –  Aaron Dec 7 '11 at 18:03

4 Answers 4

up vote 16 down vote accepted

There is the perl program rmligs which does this job for German (German being a language where this is needed quite often). Unfortunately, the word list itself doesn't seem to be available. I also don't know how good the list is; it probably follows pre-reform orthographic rules. Maybe you can reach its author. There is a project for improved German hyphenation which has quite extensive word lists. Maybe they can be of help as well.

As for the question whether it's smart to rely on LuaLaTeX I say: go ahead. One problem of the TeX world is exactly how slowly people adapt to new tools. But if no one starts, no one will move. The more attractive tools exist for modern engines, the more people will actually start to use them.

EDIT: And since I'm a huge fan of Stempel Garamond and Frutiger, these fonts should definitely be considered. ;) Seriously though: Couldn't the package just remove wrong ligatures for all fonts and only care about proper kerning for a selected few?

share|improve this answer
3  
I wholeheartedly agree with your comment on luatex. The more functionality of it is actually used (and expected by users), the greater the probability (and shorter the time to do so) that the LaTeX team will choose luatex as the default/required engine for LaTeX3! ;) –  mbork Dec 7 '11 at 16:47
5  
The word list for rmligs is included in the perl script itself (about 1600 words, following the new German spelling rules). The latest version is available here. –  Robert Dec 7 '11 at 17:04
    
Removing the ligatures for pre-set words is the easy part. Unfortunately, as I've discovered, the kerning tables are frequently poorly set up for glyph pairs, such as "f-l" and "ff-l", that the designers apparently thought would never occur as they'd be replaced with "fl" and "ffl" glyphs. As a result, depending on the font in question it's sometimes necessary to add positive and negative kerns of up to 0.7pt [!] to make the "new" letter pair look OK, i.e., to avoid both glyph collisions and ugly gaps between letters. Ideally, of course, this should have been fixed in the kerning tables. –  Mico Dec 7 '11 at 20:48
    
You could make the package work with any font, but deliver a warning or an error if the kerning values for the font used aren't included in your package. In turn, you could offer a package option to turn off these messages (next to a function like Aaron suggested in his comment to the question). –  doncherry Dec 8 '11 at 17:18

Since you are writing a luatex module, store your data as a lua table so that it may be reused by other formats or programs. For TeX modules, data is often stored as TeX macros, e.g.

\suppressligature{selfish}{self{}ish}

etc. This makes it hard to use the same data in other formats/programs and leads to a lot of duplication of effort. A better solution would be to store the data is a separate lua file as

thirddata = thirdata or {}
thirddata.ligatures = thirddata.ligatures or {}

local suppress = {
   ["selfish"] = {"self", "ish"},
   ....
}

thirddata.ligatures.suppress = suppress

etc. It is relatively easy to read the lua table and generate the appropriate TeX macros, while parsing TeX macros is always a pain.

share|improve this answer
1  
If you really want language-neutral data, wouldn't it be more appropriate to store as something like a CSV, then read that in to a language-dependent data structure at point-of use? –  Joseph Wright Dec 7 '11 at 16:29
2  
@Joseph: CSV is more limited than Lua tables, in particular, Lua tables can have nested tables (which are useful when you want to store a list: for example, in char-def.lua table in ConTeXt stores the tex names for all unicode characters. Some of the math characters have multiple mappings with different mathclasses, and this information can be easily stored in a lua table. Storing it in CSV will be more difficult). But, in principle, I agree with you. It is better to use a language independent data storage format (perhaps JSON or YAML). –  Aditya Dec 7 '11 at 17:36
    
I would rather use something like the configuration file in microtype and frankly speaking any package should built on top of its ligature suppressing figures. –  Yiannis Lazarides Dec 7 '11 at 18:48

luatex: As there doesn't seem to be a solution to this problem without luatex, you might as well be hopeful that your package will recruit new luatex users. What's the microtype situation for luatex, does the current release work for it? If not, I'd stick with pdflatex.

fonts: You could take the font poll as inspiration, so Palatino and Linux Libertine would be other fonts to consider.

names: How about smartliga / smartligs or cleverliga / cleverligs?

share|improve this answer

This is a great idea! I don't see any problem with using LuaTeX. It would be nice if the code would easily also work with ConTeXt, though. And please don't limit the package to a fixed set of ligatures - ligatures are a feature of a font and a font can have many more than just "ff" etc.

As a start I'd like a package that can produce a list of all words used in the document with ligatures, and a package that can read a list of words for which ligatures should be suppressed. That way one can easily check the list of currently used ligatures and suppress ligatures as needed.

share|improve this answer

Your Answer

 
discard

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.