Leaving out the standard ligatures – problems?

Göran Söderström

I am thinking of completely leaving out the two standard ligatures fi and fl in a typeface since it works fine without them. This will also eliminate all problems if users track differently. Since ligatures are not yet elastic it always look ugly if someone have tracked it tight and a fi ligature pops up.

Is there any problems with this at all from a user point of view? I can not come up with one single problem, but may be missing something.

Christoph Koeberlin

Hej Göran, that shouldn’t be much of a problem. Only people who directly enter the unicodes will get a notdef, but that serves them right.

Nick Shinn

I usually design fonts to work without ligatures—except for those in the old style (antiqua) genre, where they provide an air of sophistication that typographers like and expect.

James Puckett

I used to leave them empty but over the years I’ve learned that some graphic designers enjoy using ligatures in logos and headlines and won’t buy a typeface without them.

Chris Lozos

If you just want to fill the slots, make a lig which is not a lig. Put 'f" and "l" next to eachother as they would be if you typed them and you are done in a minute.

Ray Larabie

I almost always leave those fi and fl slots empty.

Ray Larabie

If you added this to the liga feature...

sub fi by f i;
sub fl by f l;

... if would prevent the old unicode fi and fl ligatures from showing a notdef. Sort of an anti-ligature.

Chris Lozos

one by many ok?

Paul van der Laan

The Macintosh Roman codepage includes /fi and /fl. We always include these glyphs because our fonts support at the very least MacRoman + Win Latin-1.

Georg Seifert

The Substitution only works if you have a fi glyph in the font.
The best solution (IMHO) is to have a fi that looks like a f and an i and no liga feature. Then, in the rare occasion that someone typed it directly (the fi and fl are accessible on some Mac keyboards) it will look ok.
The one to many substitution could improve the appearance if a lot tracking is applied. But that lookup type is not supported everywhere.

Martin Silvertant

I recently decided to start making automatic ligatures where possible so people can make use of ligatures while maintaining the ability to change tracking. For now I did keep f_i and f_l, though I have automatic ligatures for them by replacing f' i with f.alt i and the same for f_l.

I haven't included f_i or f_l in the OT features but I did include the automatic ligatures. Is this good or bad practice? Can I leave the two standard ligatures or should I remove them? I won't run into problems by keeping them, will I?

Kent Lew

The one to many substitution could improve the appearance if a lot tracking is applied.

On the other hand, there are several layout apps that automatically deactivate {liga} substitutions when the tracking surpasses a certain threshold, positive or negative (InDesign, for example). And so the irony of the one-to-many solution above is that in those environments the encoded, fixed ligature could actually reappear when the setting is tracked.

Nick Shinn

Clarification: when I said that I design fonts without ligatures, I meant that the glyphs I put in the ligature character slots are not ligated—they are just links to the component character glyphs.

Martin Silvertant

So for f_i you wouldn't modify the /f? Or do you link to an f.alt?

Nick Shinn

I try to design the /f to fit nicely with following characters such as /b, etc., and accents, but if that is not possible than yes, I do include /f.alt in the font.

attar

Personally I don't include these codepoints at all. They are a hacky legacy solution that should be completely dropped whatsoever.

Martin Silvertant

Why should they be dropped, and what do you use instead?

attar

> Why should they be dropped, and what do you use instead?

These codepoints predate OpenType and the use of GSUB to spawn ligatures, this gets you to the oddity of having a different character altogether for what is solely a cosmetic replacement (fi or fi can look the same since we have OpenType going on here but they aren't the same for search engine, text editors, etc.). What I use instead is OpenType liga, the standard GSUB way of doing it. Digraph codepoints like the one for dutch IJ have been similarly deprecated too, though you could argue that you want it as a single char or whatever. Heh.

Also, OpenType naturally allow for arbitrary ligatures, not just fi fl and a few more.

Martin Silvertant

this gets you to the oddity of having a different character altogether for what is solely a cosmetic replacement

I don't understand. Could you elaborate?

(fi or fi can look the same since we have OpenType going on here but they aren't the same for search engine, text editors, etc.).

They do look the same. What's the difference?

What I use instead is OpenType liga, the standard GSUB way of doing it.

As opposed to what? I thought I was using OpenType liga.

Digraph codepoints like the one for dutch IJ have been similarly deprecated too, though you could argue that you want it as a single char or whatever. Heh.

It depends. When a sentence starts with /IJ, I prefer it to be a single character. In any other case I prefer single letters. However, I do often make an alternate /J that comes after /I, so I can bring both letters a bit closer. In a lot of sans typefaces the /J has no descender, so the loop will use the space on the left which increases the space between the two characters. This should be compensated for.

Also, OpenType naturally allow for arbitrary ligatures, not just fi fl and a few more.

I think I may understand what you're talking about. For sans typefaces I only have /fi and /fl encoded because I thought that's what you're supposed to do. I used to encode all ligatures, but now I just design an alternate /f instead and only keep /fi and /fl, though I don't make an OT feature for those two ligatures. I make a feature for the alternate /f instead.

attar

> They do look the same. What's the difference?

It is a different characters, encoded differently. For instance, search engines will not treat it the same. If you search for letter 'f' in a document the f inside fi's will not pop up, etc.
If you type "f" "i" the letters will show up without the ligature, etc. A different Unicode codepoint is supposed to show a different grapheme, not be a shorthand for technical replacements. Also, what if you change the font from serif to a sans-serif that does not need ligatures? Type designers have usually made up ligature character that is just an assembly of the concerned letters rather than a real ligature, but clearly you can see that this is a hack rather than something proper.
But technology evolves, yet we're still stuck with most fonts having these encoded codepoints. For those who used it anyway, it is just a matter of search-and-replace. Personally, I will not support these characters in my fonts – it is the dilemma of the web developer: "Should I keep supporting this very-old browser? Should I support this proprietary CSS attribute that was only used in Firefox 23 to 25?" But if you keep hacks to support this or that browser, you are encouraging users to keep their bad practise of using an old browser, with security risks it causes. — Encoded ligatures are wrong and confusing, and by including them in the character set, we promote them.

> As opposed to what? I thought I was using OpenType liga.

As opposed to encoded Unicode codepoint. The point of the ligature codepoints is that you type the ligature character, you get a ligature character. But with OpenType it is done automatically and we should get rid of these codepoints for the reasons I outlined above.

> When a sentence starts with /IJ, I prefer it to be a single character. In any other case I prefer single letters.

It is still a debate amongst Dutch speakers, much like the capital esszett is amongst german-speaking people. For instance, Martin Majoor says there is absolutely no reason that the J should be capitalized when ij is the first character of a sentence (see here). But you never know, you just have to make a decision. So ij is widely considered deprecated yet some Dutch type designers use it.

> though I don't make an OT feature for those two ligatures. I make a feature for the alternate /f instead.

It is a distinct matter from what I was saying – I was saying that if you need an fk ligature, or an fh ligature, or an ffij ligature (assuming you encode digraphs), you can't do it otherwise than using the PUA which gets worse since these characters will not be interoperable across fonts, not "copy/pastable" since they are bound to the font, etc.
But tbh I think this is one of the reason that urged the creation of OpenType. [OpenType is also essential for some scripts e.g. Arabic which needs letters to be attached (mark, mkmk) or Serbian/Macedonian which warrant alternate cyrillic forms (locl).]

Martin Silvertant

It is a different characters, encoded differently.

I did get the feeling they were just /f/i and /f_i, but they're actually both ligatures on this website. So wouldn't that mess with the search engines? How can one include a ligature without making it into a merged character?

Also, what if you change the font from serif to a sans-serif that does not need ligatures?

I don't know. Doesn't it fall back to /f/i? Actually I only started to notice ligatures on the web and in certain software recently. Last week I used software to make a list of directories and noticed the text included /f_i ligatures. When I copied the text into InDesign, it became something else. I forgot what, but it wasn't /f/i anymore.

Type designers have usually made up ligature character that is just an assembly of the concerned letters rather than a real ligature, but clearly you can see that this is a hack rather than something proper.

So we should make ligatures to be a single character rather than composites?

But if you keep hacks to support this or that browser, you are encouraging users to keep their bad practise of using an old browser

I have my doubts about that. You could also make a point that this gives the developers more motivation to find a solution to give these hacks full support, rather than to abolish them. But I guess your point is that technologically speaking we're already beyond this, so our practices should conform to the technology rather than the other way around.

The point of the ligature codepoints is that you type the ligature character, you get a ligature character.

How do I type a ligature anyway? I only know how to use ligatures by turning on OT features. So am I actually doing it right or am I still misunderstanding something?

It is still a debate amongst Dutch speakers

Apparently so. I strongly disagree with Martin Majoor. I don't remember actually seeing "Ijzer" or "Ijmuiden". I even went as far as to create an OT feature to prevent that from happening. First off, I've seen the use of IJ as a single character in lettering that is 100 to 200 years old in the city I live in. If IJ is wrong, apparently we've been doing it wrong for a long time. The fact that we've been doing it "wrong" for so long means it has become right. Thomas Milo says the following:
IJmuiden can only be spelled in one manner: with a single capital IJ. Spelling is with upper case I and lower case j is no option. It would look just as ridiculous as Vvilliam instead of William.

That's actually a great comparison, because as you know the /W manifested later. Following Martin Majoor's reasoning, I would have to say using a /W is wrong. Of course I have to admit /W isn't a digraph, but I feel it's a small distinction.

But perhaps most importantly, we pronounce IJ like [ɛi], rather than /i:/ [j] (like they're two letters). In fact, in old Dutch we used the /y instead. So really, Martin Majoor is very wrong. Historically it has always been a single letter and a single sound, so I don't see why he wants us to only capitalize the /I. It looks very wrong and historically it's wrong.

I was saying that if you need an fk ligature, or an fh ligature, or an ffij ligature (assuming you encode digraphs), you can't do it otherwise than using the PUA which gets worse since these characters will not be interoperable across fonts, not "copy/pastable" since they are bound to the font, etc.

But I don't usually encode digraphs unless they're connected, just like I would encode the eszett only when it's connected, and use /ſ/z otherwise. In case of connected ligatures though, I guess there is no way to work around the encoding, is there?

attar

> I did get the feeling they were just /f/i and /f_i, but they're actually both ligatures on this website. So wouldn't that mess with the search engines?

No, because glyph substitution does not change the source text, it is only done at the rendering level.

> So we should make ligatures to be a single character rather than composites?

My process: if you want to add a ligature in your font, create one that is unencoded and add `liga` code. Otherwise, don't create one.

BTW, another oddity of encoded ligatures is that when creating alternate alphabets like small caps you also need characters like FI if you want to keep `smcp` a one-to-one substitution. But caps don't need ligatures.



> How do I type a ligature anyway?

By typing its codepoint or using the char palette. fi is U+FB01, so that would be Alt+FB01 on Windows.

> In case of connected ligatures though, I guess there is no way to work around the encoding, is there?

Well, characters like ß or Æ have their own codepoints. If there is no linguistic difference, there should not be distinct codepoints. Hence the debate on IJ and ẞ (capital esszett).

William Greaves

As an end user of fonts, I'm a fan of ligatures. However, if the "f" and "i" in a font don't overlap at all when they are printed next to one another, I can live without the ligatures.

My test for the need of ligatures is this sentence:

"The only good fido is one with a finicky affordable affinity for affluent fluid mechanics on Khafkian fjords."

If that sentence looks good in your font without ligatures, you're golden.

Martin Silvertant

My process: if you want to add a ligature in your font, create one that is unencoded and add `liga` code. Otherwise, don't create one.

Not that I'm catering to Word users, but I thought the standard encoded ligatures should be included so these ligatures can be used in software like Word. Anyway, from now on I won't encode f_i and f_l anymore, which were the only ones I did encode in my latest typeface.

By typing its codepoint or using the char palette. fi is U+FB01, so that would be Alt+FB01 on Windows.

Sorry, I should have been more specific. How do I type Alt+FB01? I use Alt+Num combinations for dashes and ellipses, but I can't figure out how to type FB within an Alt code. I haven't been able to find the solution on the Internet.

By the way, what about fractions? Should they not be encoded either?

However, if the "f" and "i" in a font don't overlap at all when they are printed next to one another, I can live without the ligatures. 

In my latest typeface I initially had connected ligatures but ultimately found them to be too obtrusive, so I made disconnected ligatures (rather considered to be contextual alternates I suppose). Whether they're connected or not, I often feel standard ligatures should be used to optimize text. Some typefaces don't require ligatures, but I find even when others wouldn't really notice it, I create contextual alternates to improve the rhythm just a bit more.

attar

> Not that I'm catering to Word users, but I thought the standard encoded ligatures should be included so these ligatures can be used in software like Word.

Word 2010+ supports OpenType ligatures (and some other OpenType features, though no small caps), but it is disabled by default.

> By the way, what about fractions? Should they not be encoded either?

Prebuilt fractions are not quite as obtrusive, and still part of Latin-1. I leave the three Latin-1 fractions personally but OpenType frac is of course the recommended way to go about it.

attar

> By the way, what about fractions? Should they not be encoded either?

In a way, the percent sign is just a fraction with zeroes.

Martin Silvertant

Prebuilt fractions are not quite as obtrusive, and still part of Latin-1. I leave the three Latin-1 fractions personally but OpenType frac is of course the recommended way to go about it.

Well, OT fractions are included in my typefaces, but then there are some fractions that are encoded as well. I've been following other typefaces in that regard, as I assumed these fractions are used in contexts where OT functionality can't be accessed. I figured it's the same thing for ligatures in earlier versions of Word when OT functionality wasn't included.

attar

> I figured it's the same thing for ligatures in earlier versions of Word when OT functionality wasn't included.

If your clients have no possibility of getting access to software with OpenType support, I guess you should leave this workaround. It comes down to what your target is, and you can provide both encoded codepoint and substitution. Personally I expect that people who care about ligatures are probably using OpenType-enabled software anyway.

Martin Silvertant

They probably are. I'm very hesitant about supporting functionality that is on the verge of disappearing forever though. People should start using software of this time, rather than designers catering to the needs of the outdated. Of course the situation is a little more nuanced than that and you may in fact still need to cater to the needs of the old in certain situations, but regardless this is the sentiment I feel we should pursue. I suppose I'm a traditionalist by heart but when it comes to ligatures, I'm absolutely convinced—and you helped me to see this—that encoding ligatures is an outdated practice that needs to go away as soon as possible. When it comes to fractions I feel there are very practical reasons for why they should be assigned to codepoints as well, besides having clear OT functionality. I think in the contexts fractions will be used, OT functionality isn't always accessible.

Claudio Piccinini

I’m retrieving this old discussion as I am wondering if it’s safe to leave the encoded f_i and f_l out of basic encodings like "Opentype Standard".
In most of my typefaces there is no use for them, and I don’t like much the idea of just adding them (coded) as letter pairs standard spaced just to fill the encoding slots.

Christian Thalmann

If your font lacks hard-coded fi and fl and you copy/paste a text including them, wouldn't they cause tofu or fallback? Outdated or not, it's still likely to come up every now and then across your user base.