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.
1
Comments
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.
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?
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.
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).]
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. 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?
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).
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.
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.
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?
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.
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.
In a way, the percent sign is just a fraction with zeroes.
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.
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.
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.