> And here's the design error: The values in the `ligatures' > line of a groff metrics file should be *groff entities*, > not PS glyph names.
They were already called ffi, ffl, etc. before Postscript was invented, so it unlikely they are PS glyph names but rather input character sequences for which ligatures may be substituted. That the PS glyphs had the same names is just a coincidence (they might just as well have been called "fi-lig" or so). The "new" glyph naming tries to systematize the scheme a bit by having ligatures called by the names of their components, "something_something", but this appears to be only a convention (e.g., Linux Linertine defines a ligature of "degree" and "F" called "fahrenheit"). > In other words, the allowed values should be > > ff, fi, fl, Fi, Fl > > instead of > > ff, fi, fl, ffi, ffl > > Then the look-up code in the troff program would be > completely independent to the real glyph names in the > metrics file, [...] You still need the mapping of input characters sequences to groff entities. Of course one might consider this implicit in the definition of groff entities like "Fi" (but then there would be no advantage to the current implementation, in which "ffi" is also mapped implicitly onto "Fi"), and considering that groff entity names can be created on the fly, this is just as severe a limitation as the current design is. I think the best would be a specification that allows sequences of characters to be mapped to groff entity names, either in terms of already-compounded entities (similar to what the AFM file defines for PS glyph names, or what TeX does), ... charset ... ligatures f i fi f l fl f f ff ff i Fi ff l Fl kernpairs ... or looking at more than just the next input character, ... charset ... ligatures f f i Fi f f l Fl f i fi f l fl f f ff kernpairs ...
