6 ms·

Usually, the author is spot-on with his recommendations and I really enjoy reading his website. So I was a bit surprised about this: > When we’re using a serif

Usually, the author is spot-on with his recommendations and I really enjoy reading his website. So I was a bit surprised about this: > When we’re using a serifed text font in ordinary body text, we don’t have the same considerations. An fi ligature always means f followed by i. In that case, ligature substitution that ignores context doesn’t change the meaning. Maybe this is different in English typography - I'm a bit more proficient in German - but ligatures do have semantic meaning. At least in German, they should never cross a word boundary in composite words, for example Kaufleute (merchants) is Kauf-leute (buy-people), so you would not use a "fl" ligature. There are actually words where this resolves an ambiguity, I think. Historically, this is the reason sometimes ss and sometimes ß is used. I always assumed there were similar subtle rules in English. As to the "ligatures" in programming fonts - I would not call them such, problem solved. Rather, they are substitutions in the tradition of APL or vim conceal mode - to get mathematical notation with a standard keyboard.

pjc50 8y ago
Perhaps, but the automatic ligature substitution doesn't know that, and indeed in Times "Kauflete" is rendered with a ligature. Probably because native English speakers aren't used to accent or ligature rules. Anyway, I too agree with the author; if you want ≥ to appear on your screen, it should be in the source text as the UTF-8 bytes for U+2265 and the tooling should understand it. Programming is too fragile to allow misunderstandings between the bytes that are interpreted by the machine and the glyphs that the programmer understands to be inserted. Going much further back, there are the C trigraphs '??!' etc, for those whose character sets don't contain '|'. I've not seen editors attempt to automatically show those as the substitute characters either. (Oh, and if you want to be unpopular, try entering unicode characters in your language variable identifiers or git commit messages and see how much tooling you can break...)
- Freak_NL 8y ago
  Why would using non-ASCII characters (I assume that is what you mean by Unicode characters) in a git commit message break anything sensible? It's meant to be human readable text, and defaults to UTF-8 (although you can use legacy encodings if you really must). Any git hook processing stuff would just look for stuff it does understand (like '([Cc]lose(s)?|[Ff]ix(es)?) #[0-9]+' or something similar) and ignore the rest. Scores of developers use non-ASCII characters as part of their native language every day in git commit messages, and even non-BMP Unicode characters like emoji work just fine.
  - aasasd 8y ago
    Well, I dunno if you consider GitHub branch names circa 2015 sensible...
- WorldMaker 8y ago
  I've used emoji and other astral planes characters in git commits and variable identifiers and haven't seen a tool break yet.
cotelletta 8y ago
The whole point of ligatures is that they are visually subtle enough that you don't consciously notice them, while removing distracting collisions of adjacent glyphs. The German rule seems entirely pointless and counterproductive. That said, OP is wrong that ligatures would "break Unicode". The only ligatures that are directly encoded exist for historical reasons. Fonts can and should make contextual alternatives, and this is a normal part of typesetting for several languages. Unicode breaks Unicode, it's not meant to be consistent, only compatible.
- kapep 8y ago
  > The German rule seems entirely pointless and counterproductive. The rule provides visual hints for how to pronounce words. I think that is way more useful than slightly increasing the readability by joining glyphs without context.
  - wirrbel 8y ago
    i makes a lot of sense, just think of Kaufleute = Kauf ++ leute (merchant / trader, from kaufen = to buy) Kaufläche = Kau ++ fläche (chewing surface / morsal surface from kauen = to chew) But I am sure only professional typographers + a small minority of pedants (in the good sense) would be aware of this.
- cyborgx7 8y ago
  Yes. I learned from this article that there are code points for ligature glyphs in unicode and it seems like a pretty bad idea, tbh.
jfk13 8y ago
For an English example, some typographers would consider it better to avoid an "ff" ligature in "shelfful" (see The TeXbook, p.19).

pjc50 8y ago

Perhaps, but the automatic ligature substitution doesn't know that, and indeed in Times "Kauflete" is rendered with a ligature. Probably because native English speakers aren't used to accent or ligature rules. Anyway, I too agree with the author; if you want ≥ to appear on your screen, it should be in the source text as the UTF-8 bytes for U+2265 and the tooling should understand it. Programming is too fragile to allow misunderstandings between the bytes that are interpreted by the machine and the glyphs that the programmer understands to be inserted. Going much further back, there are the C trigraphs '??!' etc, for those whose character sets don't contain '|'. I've not seen editors attempt to automatically show those as the substitute characters either. (Oh, and if you want to be unpopular, try entering unicode characters in your language variable identifiers or git commit messages and see how much tooling you can break...)

Freak_NL 8y ago
Why would using non-ASCII characters (I assume that is what you mean by Unicode characters) in a git commit message break anything sensible? It's meant to be human readable text, and defaults to UTF-8 (although you can use legacy encodings if you really must). Any git hook processing stuff would just look for stuff it does understand (like '([Cc]lose(s)?|[Ff]ix(es)?) #[0-9]+' or something similar) and ignore the rest. Scores of developers use non-ASCII characters as part of their native language every day in git commit messages, and even non-BMP Unicode characters like emoji work just fine.
- aasasd 8y ago
  Well, I dunno if you consider GitHub branch names circa 2015 sensible...
WorldMaker 8y ago
I've used emoji and other astral planes characters in git commits and variable identifiers and haven't seen a tool break yet.

cotelletta 8y ago

The whole point of ligatures is that they are visually subtle enough that you don't consciously notice them, while removing distracting collisions of adjacent glyphs. The German rule seems entirely pointless and counterproductive. That said, OP is wrong that ligatures would "break Unicode". The only ligatures that are directly encoded exist for historical reasons. Fonts can and should make contextual alternatives, and this is a normal part of typesetting for several languages. Unicode breaks Unicode, it's not meant to be consistent, only compatible.

kapep 8y ago
> The German rule seems entirely pointless and counterproductive. The rule provides visual hints for how to pronounce words. I think that is way more useful than slightly increasing the readability by joining glyphs without context.
- wirrbel 8y ago
  i makes a lot of sense, just think of Kaufleute = Kauf ++ leute (merchant / trader, from kaufen = to buy) Kaufläche = Kau ++ fläche (chewing surface / morsal surface from kauen = to chew) But I am sure only professional typographers + a small minority of pedants (in the good sense) would be aware of this.
cyborgx7 8y ago
Yes. I learned from this article that there are code points for ligature glyphs in unicode and it seems like a pretty bad idea, tbh.

jfk13 8y ago

For an English example, some typographers would consider it better to avoid an "ff" ligature in "shelfful" (see The TeXbook, p.19).