# Mapping a combination of characters to a ligature manually with otftotfm

I'm trying to convert a sizeable OTF font to TeX font metrics. Inevitably, I have to make some choices about what ligatures, kerns, and so on to use. The otftotfm manual mentions a --ligkern=<command> feature which should do what I want.

The manual has the following to say about the feature:

--ligkern=command

Add a LIGKERN command to the encoding. For example, ’--ligkern "T {L} h"’ suppresses any T_h ligature in the font. You can supply multiple --ligkern options. See ENCODINGS, below.

Going to the ENCODINGS section, it has the following to say about ligatures:

LIGKERN comments in the encoding can add ligatures and inhibit kerns, as in afm2tfm(1). To add a ligature, say:

% LIGKERN glyph1 glyph2 =: result ;


In the case I would want to map characters T and h to the glyph named T_h and this combination is not automatically recognized by otftotfm (somehow), I devise that I have the following options to map T + h --> T_h:

1. I can set --ligkern="T h =: T_h" in the command prompt or
2. Use a comment %LIGKERN T h =: T_h inside whatever *.ec file I use.

Independent of whether I use a custom encoding file or the generic 8r encoding, the result is that:

1. The glyph does show up in the font table
2. Th is not replaced by the ligature correctly.

So where did it go wrong? I'm happy to supply more info if necessary.

Added picture to show the issue:

• Unless the swashes are intended for use in maths, this is unlikely to be useful. Moreover, it is not easier to set this up than to do it for text. It just complicates things. Better say the swashes are not supported in (pdf)TeX format and be done with it. – cfr Jun 7 '15 at 13:29
• Note, too, that you should be using a known encoding rather than 8r. That is intended as an intermediate encoding ('raw'). It is hard to tell as I'm not sure exactly what you are doing but I don't usually use that encoding with otftotfm as opposed to fontinst and, for fontinst, I don't necessarily use it even as an intermediate encoding (although I do sometimes). What you don't want is that the TFMs which are invoked in the font definition files, for example, use the 8r encoding because that isn't a regular encoding for use in a document. (You want T1 or OT1 or LY1 or T2 or TS1 or...) – cfr Jun 7 '15 at 19:47
• I don't think this really matters for otftotfm but there are multiple senses or kinds of encodings around. In the creation of fonts for TeX, two of these are of importance. If you are creating virtual fonts, you can use intermediate encodings which are arbitrary and private. There's no problem with doing this. Then there are the encodings of the final fonts which are the ones called in the font definition files. It matters that these are in a standard encoding (T1, OT1, LY1, TS1 etc.). If you are using additional ligs etc., you can vary a standard encoding without doing much harm. – cfr Jun 7 '15 at 19:50
• This is a hack but it is a very effective one. It is crucial, however, that you document every variation you introduce. This should be noted in both the relevant part of your source and in the user documentation you provide. For this reason, I recommend specifying additional ligs etc. in files rather than passing them as options. It makes it much easier to document them. For otftotfm, just the files are fairly self-explanatory so you only need worry much about the manual. For fontinst, I always note these changes at the top of modified .etx files, for example, as well as in the docs. – cfr Jun 7 '15 at 19:54
• – cfr Jun 7 '15 at 20:21

Take a look at berenisadf source. I generally use fontinst rather than otftotfm for this kind of work but I used the latter for berenisadf. The files for the LY1 encoding in the source will be the most informative here as they contain additional ligatures etc. You've not really supplied enough information to say what is wrong.

Take a look at romandeadf source as well. This creates virtual fonts using fontinst. The basics are well documented in The Font Installation Guide. More complex cases need to use information from fontinst's manual but I found this very difficult to understand without looking at examples of usage. Many of my font packages support additional ligatures, swash characters etc. and they all include the source in the CTAN packages. The documentation for the packages gives a 'big picture' idea of the packaging strategy (as well as usage information).

You mentioned swash characters in chat. If you just meant fancy ligatures, that is fairly straightforward. If you are talking about contextual swashes, that is more involved. For example, you might want something like e.end in the OTF to be used at the end of words but not the beginning or the middle. This can be part of a variant which will be automatised so that the user need only type something like \swashstyle to enable (a set of) contextual swashes.

However, for a font the size you mentioned in chat, I would either just advise users to use LuaTeX/XeTeX or I would not even try to make everything in the font available for (pdf)TeX. Instead, think about useful sets of 256 characters. It is not useful to create sets which drop so many core characters to make room for the fancy stuff that nobody in practice will actually be tempted to use them.

Bear in mind that most users who use a font package will want to say \usepackage{name} and forget it. The more discerning will be happy to say \usepackage[some options]{name} and a few may also want to use custom commands, if they are relatively intelligible and usable, for special styling within the document.

• What additional information is required to say something about the problem? I have converted the the tex font metrics to property list files, and everything seems in order. For some random reason, some ligatures (the default ones that don't require any extra commands in otftotfm) do show, but the ones I specified explicitly, don't. – 1010011010 Jun 7 '15 at 13:48
• @1010011010 What does 'seems in order' mean? The character itself is there, I take it. Are the ligatures also defined correctly? – cfr Jun 7 '15 at 13:54
• Hmm, I just checked again and now the ligatures do work (I just ran the same command again and now it shows the ligatures). Anyway, what I did was convert through tftopl and check if the mapping from the octal characters for T and h to the octal character for Th was correct, and it turned out that it was. – 1010011010 Jun 7 '15 at 13:59

I'm unsure what was wrong, but I ran the command again and now it does seem to work. The command used (in my case) was:

otftotfm -a -e 8r --vendor Typofonderie -fkern -fliga --ligkern="T h =: T_h" --ligkern="a e =: ae" LeMondeLivreClassicPro-Book.otf fmlk8r


The above command removes T and h (if found in sequence) and replaces it with the character T_h, and it also maps a and e --> ae.

## The following post is trying to be as complete as possible to cover a few bits beyond the basics to set up a text font to your liking with otftotfm.. possibly longer post

There are a couple of caveats to consider when debugging what's wrong. Assuming you know the basics of otftotfm as covered in How do I use TrueType Fonts with PDFTeX using otftotfm?), the basic command is the same as above, so

otftotfm -a -e 8r --vendor Typofonderie -fkern -fliga --ligkern="T h =: T_h" --ligkern="a e =: ae" LeMondeLivreClassicPro-Book.otf fmlk8r


Important part: the file name specified all the way at the end, fmlk8r (as per the font scheme used for fontinst). I've used fml as the type family name, so my fd file is

\ProvidesFile{t1fml.fd}
[2012/04/22 scalable font definitions for T1/LeMondeLivre.]
\DeclareFontFamily{T1}{fml}{}
\DeclareFontShape{T1}{fml}{m}{n}{<-> fmlk8r}{}
\endinput


I used the following to get the font table and to test some specific ligatures in text:

\documentclass{article}
\usepackage{fonttable}
\usepackage[T1]{fontenc}
%\usepackage{geometry}
\usepackage{microtype}
\pdfmapfile{Typofonderie.map}
\begin{document}
\xfonttable{T1}{fml}{m}{n}
\fontfamily{fml}\selectfont There you go. Some beautiful formulae. Here's a ligature ffi ffl. Therefore.
\end{document}


To check whether a particular character + another character maps correctly to your ligature, check the font table and extract the octal number. In this case it is 240. 24 because of the red box (see below) and 0 because of the blue box (adds up to 24-0). (Remember the octal number of the ligature.)

The next step is to convert your TeX font metrics to property list files. Use the command

tftopl fmlk8r.tfm fmlk8r.pl


to create fmlk8r.pl. Open this with any text editor.

Inside this property list file, you can see if the ligature is correctly mapped by looking up the capital T and checking whether it maps to the ligature. Alphabetic characters simply show up as CHARACTER C <letter>, while all other characters, ligatures and so on, use CHARACTER O <octal number>. In this case we would want to check whether CHARACTER C T has something related to CHARACTER C h, which should map to CHARACTER O 240. In my case it does:

(CHARACTER C T
(CHARWD R 0.615)
(CHARHT R 0.6925)
(COMMENT
(LIG C h O 240)
(KRN O 73 R -0.04)
(KRN O 72 R -0.04)
(KRN O 140 R 0.035)
...
)
)


The line (LIG C h O 240) tells us about a LIGature, which should only be called when the next letter is a C h, and it maps to O 240.

If it doesn't something went wrong at the stage of conversion between OTF and TFM. In that case I would consider consulting the otftotfm manual.

Hopefully this is of use to somebody!

• æ etc. ought not be encoded as ligatures. These are distinct characters and should be encoded as single letters. – cfr Jun 7 '15 at 14:50
• As your font table clearly shows the encoding you are using is not T1 (see the table on page 22 or texdoc encguide) You should either encode the font to T1 or use a local font encoding name. – David Carlisle Jun 7 '15 at 20:53