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.
Yes, that’s why I was asking. Would it make sense to include them coded but have "reverse code" like Ray suggested years ago? Or is the general consensus that it’s better to add them even if they're simply — say — an f followed by an i? Even if this is not the best in terms of supposed spacing?
Even if your ligatures are just the two characters set side by side, it doesn't take that much space to include the fi and fl characters.
As far as spacing goes, at least in InDesign, if you track a word containing a ligature far enough, the ligature will break apart into separate characters. The threshold is approximately -52 and +18, depending on the font. (No idea how it decides what the threshold is.)
Note that this only happens if the ligatures were created automatically by InDesign. If you type the ligatures directly, say using the Mac key combinations shift-opt-5 or shift-opt-6, they will never break apart.
... if would prevent the old unicode fi and fl ligatures from showing a notdef. Sort of an anti-ligature.
The only reason the old fi and fl ligatures would show a notdef, is if they are not present in the font.
BUT this code only functions if you do include glyphs for the hard-coded ligatures in your font!
Even then, it only works if the ligature feature is also enabled. So, under the situation where the user has explicitly asked for the ligatures, you turn the hardcoded ligature into a non-ligature? I am really not getting why this is desirable!
... if would prevent the old unicode fi and fl ligatures from showing a notdef. Sort of an anti-ligature.
The only reason the old fi and fl ligatures would show a notdef, is if they are not present in the font.
BUT this code only functions if you do include glyphs for the hard-coded ligatures in your font!
Even then, it only works if the ligature feature is also enabled. So, under the situation where the user has explicitly asked for the ligatures, you turn the hardcoded ligature into a non-ligature? I am really not getting why this is desirable!
Thanks Thomas. Yes, I was wondering why Ray suggested this back then, as I did not understand much its use either. And I will definitely include "precomposed" ligatures then, just to ensure backwards compatibility.
Even if your ligatures are just the two characters set side by side, it doesn't take that much space to include the fi and fl characters.
As far as spacing goes, at least in InDesign, if you track a word containing a ligature far enough, the ligature will break apart into separate characters. The threshold is approximately -52 and +18, depending on the font. (No idea how it decides what the threshold is.)
Note that this only happens if the ligatures were created automatically by InDesign. If you type the ligatures directly, say using the Mac key combinations shift-opt-5 or shift-opt-6, they will never break apart.
Yes, I recall. The last sentence is the reason for which I was reluctant to include them, but I see every professional designer is still including them, so it seems safer to do so.
... if would prevent the old unicode fi and fl ligatures from showing a notdef. Sort of an anti-ligature.
The only reason the old fi and fl ligatures would show a notdef, is if they are not present in the font.
BUT this code only functions if you do include glyphs for the hard-coded ligatures in your font!
Even then, it only works if the ligature feature is also enabled. So, under the situation where the user has explicitly asked for the ligatures, you turn the hardcoded ligature into a non-ligature? I am really not getting why this is desirable!
Putting this code in 'liga' makes absolutely no sense, but I can see some benefits for including it in 'ccmp'. Then any hardcoded ligatures in the document would be decomposed and you wouldn't have to worry about them when dealing with small caps, kerning, etc.
Putting this code in 'liga' makes absolutely no sense, but I can see some benefits for including it in 'ccmp'. Then any hardcoded ligatures in the document would be decomposed and you wouldn't have to worry about them when dealing with small caps, kerning, etc.
This still changes the encoding, which is probably more trouble than it's worth. It's not such a bit deal to include fi.sc and fl.sc.
Layout features generally don’t change the encoding of the underlying text, as far as I know. (There are some edge cases where the underlying text is lost)
Long-time TypeDrawers folks are probably all well-aware of this, but for other readers....
As far as I know, the most common (or at least most well-known) of those edge cases is… if somebody prints PostScript to disk, with OpenType CFF fonts, and runs that through a PDF generator that does not access the original font (which it perhaps could if that font is installed on the computer that is doing the PDF creation).
If that all happens… in most cases the backing store and the 'cmap' has been lost; all that is left is glyph names.
Comments
Would it make sense to include them coded but have "reverse code" like Ray suggested years ago? Or is the general consensus that it’s better to add them even if they're simply — say — an f followed by an i? Even if this is not the best in terms of supposed spacing?
Ray Larabie said:
As far as spacing goes, at least in InDesign, if you track a word containing a ligature far enough, the ligature will break apart into separate characters. The threshold is approximately -52 and +18, depending on the font. (No idea how it decides what the threshold is.)
Note that this only happens if the ligatures were created automatically by InDesign. If you type the ligatures directly, say using the Mac key combinations shift-opt-5 or shift-opt-6, they will never break apart.
The only reason the old fi and fl ligatures would show a notdef, is if they are not present in the font.
BUT this code only functions if you do include glyphs for the hard-coded ligatures in your font!
Even then, it only works if the ligature feature is also enabled. So, under the situation where the user has explicitly asked for the ligatures, you turn the hardcoded ligature into a non-ligature? I am really not getting why this is desirable!
And I will definitely include "precomposed" ligatures then, just to ensure backwards compatibility.
As far as I know, the most common (or at least most well-known) of those edge cases is… if somebody prints PostScript to disk, with OpenType CFF fonts, and runs that through a PDF generator that does not access the original font (which it perhaps could if that font is installed on the computer that is doing the PDF creation).
If that all happens… in most cases the backing store and the 'cmap' has been lost; all that is left is glyph names.
This is definitely not common.