Follow-up Comment #1, bug #64344 (project groff): I support this. Tadziu's proposal seems well-considered (not a suprise).
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 ... The only thing that makes me uncomfortable about the above is that "ligatures" is already a recognized directive with pretty different parsing semantics. ligatures lig1 ... lign [0] Glyphs lig1, ..., lign are ligatures; possible ligatures are ff, fi, fl, ffi, and ffl. For compatibility with other troff implementations, the list of ligatures may be terminated with a 0. The list of ligatures must not extend over more than one line. It would suck to break back-compatibility, might be fragile to maintain enough state to distinguish the foregoing while maintaining compatibility, and promises to be tedious to document such a Janus-faced directive so that users will understand it. So I would pick a different keyword. _______________________________________________________ Reply to this item at: <https://savannah.gnu.org/bugs/?64344> _______________________________________________ Message sent via Savannah https://savannah.gnu.org/