31

Whether or not certain ligatures should be used (if available in a font) is a least in theory depending on the language used. For example traditional German texts would not have an "ffl" ligature but would have "ft" and also "ch" and "ck".

pdfTeX supports disabling selected ligutures but you will always disable the full set beginning with a certain character, so it is not possible to drop "ffl" but keep "fi", say. (I haven't checked what pdfTeX actually does, this is my understanding from the microtype manual).

From reading through the LuaTeX manual I can see that there should be (in theory) much finer control possible, but I don't see concepts to hook into the ligature mechanism to easily provide a language-based abstraction. In my opinion a mechanism should apply at (or close to) the typesetting stage and not at during input preparation, i.e., the answer to "Can one suppress ligatures for certain words?" addresses this too early in the game.

So my questions are:

  • Has something for this already be programmed?
  • If not, how complicated would it be, given the current functionality in LuaTeX, or are there some useful interfaces for this still missing?

Unfortunately this doesn't address how to specify that for certain languages you may want to have "ligature-kerns" i.e., some extra kerning used only in a particular language to bring some character pairs closer together than in other languages.

|improve this question
  • 1
    There is no ready-to-use interface for that. You can use the pre_linebreak_filter to break up these ligatures but this is - if you take the trivial approach - an all or nothing question (disabling ffi is easy, transform ffi to fi is probably not that easy). That said, if you really need this, that should be the callback you should hook into and analyse the list ans de-ligature yourself "manually". – topskip Jun 24 '12 at 15:40
  • @Patrick that seems to me the the wrong abstraction layer because at that point I wouldn't have access to language information without doing a lot of external housekeeping (just think about different text pieces being reshuffled on a higher level) – Frank Mittelbach Jun 24 '12 at 16:18
  • 2
    The "prevent selected ligature" feature of microtype use the \tagcode primitive of pdftex and as far as I unterstood it clears the complete lig_table of a char. Regarding luate: I think you could use feature files to revert ligatures, see the documentation of luaotfload. – Ulrike Fischer Jun 24 '12 at 16:30
  • This should be handled partly at the OpenType level: The font should supply the correct ligatures for the current language. – Martin Schröder Jun 25 '12 at 14:17
  • @Martin and how many fonts would do that? And how do you specify to the font which language ligatures you want? Also the number of languages a font would "understand" is probably much smaller than the number of languages that culd be typeset with it ... so not sure that the font level would be the right abstraction level. – Frank Mittelbach Jun 25 '12 at 16:34
6

In addition to the question Can one (more or less) automatically suppress ligatures for certain words? (and the associated answers) that you already mention in your posting, you may also want to check out the content of the follow-up questions: Any suggestions/requests for features for a new package that allows disabling ligatures for (pre)selected words? and How to suppress the operation of a luatex-defined macro on a string if the string is part of macro or a label. Shameless self-citation alert!

In the latter question in particular, I provided the rudiments of lua code to suppress the use of certain (or all) ligatures for certain words. This code could easily be made language-specific by linking it, say, to the use of a language option set in babel.

Unfortunately, my initial plans to create a stand-alone package that implements this approach have gotten stymied after I discovered that the code is too powerful: the ligature substitution (suppression, if you will) algorithm cannot be instructed not to operate on TeX macros; e.g., should there be a macro named \auflaufen, one apparently cannot instruct luatex not to replace the string "auflaufen" with "auf{\hspace{0pt}}laufen}, leading to unpredictably chaotic consequences. Similarly, the ligature suppression algorithm can't be instructed not to operate on the arguments of certain macros such as \label and \ref (and, by extension, \vref, \cref etc.). For these reasons I've given up for now on making this a standalone package, as its applicability would always be "experimental" at best. Hopefully, more lua programming tools and hooks will be made available so that it'll become possible to set up the needed exceptions (e.g., don't operate on the names of TeX macros, and don't operate on the arguments of \label, \ref, etc) to make the approach I've developed usable for a general public.

|improve this answer
  • Might Arno L. Trautmann’s chickenize be helpful in making your idea work better? – J. C. Salomon Jul 3 '12 at 19:33
  • 1
    @Mico: I've added a new answer to the last of your referenced questions. If you are up to it, feel free to use that code. – Taco Hoekwater Jul 10 '12 at 8:45
  • good resources @Mico, shamesless self-citation or not :-) and it points in the right direction for a kind of language dependency handling. – Frank Mittelbach Aug 6 '12 at 20:16
  • 1
    @FrankMittelbach - thanks! I'm actually quite close to uploading to the CTAN a beta version of a package I'll call selnolig, to suppress ligatures selectively for both English and German language applications. I suspect the German application will be by far the more useful one of the two... – Mico Aug 6 '12 at 22:58
  • 1
    @FrankMittelbach - At long last I've completed a (beta) version of the selnolig package; see meta.tex.stackexchange.com/q/2884/5001 over in Meta for a pointer to where the relevant files are located on GitHub. As you'll see, I've incorporated your suggestion that it may be worthwhile disabling certain ligatures globally. However, I didn't apply it to the ffl ligature but, rather, to other f-ligatures such as fb, fh, fj, and fk -- with due allowance for words of non-German origin such as fjord, fjell, and Kafka. Comments most welcome! – Mico Nov 18 '12 at 2:41
7
+200

OpenType fonts class ligatures as Required, Common, Contextual, Rare/Discretionary, and Historic; and there are “features” for each of these (rlig, liga, clig, dlig, & hlig), which can be enabled or disabled separately via fontspec (and, presumably, ConTeXt, but I don't know for certain).

For example, in this answer, letter-spacing Fraktur requires certain ligatures (ch, ck, ſt, & tz) to be kept, but others disabled. The fontspec invocation given therefore disables the “Common” ligatures but explicitly enables the “Required” ones;—and this is the important part—the font used in that example has the ligatures classed correctly for this purpose.

This is therefore only a partial answer. It only works for OpenType fonts for which this classification of ligatures has been correctly done, and it’s not useful in the arbitrary case of (e.g.) enabling “fi” but disabling “fl”. (On the other hand, a font designed for German might have different ligature tables enabled depending on the language setting. YMMV.

(On the gripping hand, see An example of changing kerning of a font in LuaLaTeX, which indicates that patches to faulty OpenType tables [presumably including ligature tables] can be included at font-load time.)

|improve this answer
  • 2
    As I mentioned in my answerto @Martin, I'm not sure that a font based interface would offer the abstraction level needed. For a start it would require that different fonts use precisely the same convention how to mark up different ligature classes and I doubt that this is a the case (though it might come). In my opinion the interface has to be a higher layer, e.g., on the LuaTeX side which in turn could make use of functionality offered by fonts if available. – Frank Mittelbach Jun 29 '12 at 16:01
  • 1
    @FrankMittelbach, I did acknowledge that this depended on the foundry getting these details right. On the other hand, that’s where this sort of expertise is supposed to be employed. To use the example from my answer, if a Fraktur font has the ck ligature anywhere but the rlig table, it’s defective. (I wonder if LuaTeX’s font-handling can alter the in-memory version of the font’s ligature tables.) – J. C. Salomon Jun 29 '12 at 16:37
  • right you did and getting such information from the font is a good start, but manipulating it should (imho) happen higher up. For example, if a font would have language specific information you would need to control that after the font is loaded, I doubt (but perhaps I'm wrong) that there would be a way to load a font several times with different settings and even if, it would seem a questionable resource management, or not? – Frank Mittelbach Jun 29 '12 at 18:27
  • 1
    Not need to re-load the font; only to patch or create the language-specific ligature tables. And you’re right; a better use of resources would be to get the font fixed. The folks at typophile.com say that the important foundries like Adobe will correct these issues as they’re raised. – J. C. Salomon Jun 29 '12 at 22:58
  • I haven't yet worked with LuaTeX on this level, but from reading the documentation I wonder how efficient this could be. You either would have to keep adjusted tables for every font and every language and remap the tables or you would need to change them on the fly whenever you change fonts or language. Neither seems to me a very robust solution. Well, it all is a very abstract discussion unless somebody actually shows how it could be successfully implemented. – Frank Mittelbach Jun 30 '12 at 6:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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