> Yes, it appears that groff decomposes the "u..." characters, > recognizes the five as known ligatures, but then outputs the > individual characters because the font description file doesn't > contain the corresponding groff names "ff", "Fi", "Fl", etc., > even though it contains the composite unicode characters.
This seems to me an odd thing for groff to do. For plain text, I can see why one would want groff to take input character combinations that can be rendered as ligatures and transform them thus. But if the user explicitly gives groff a composite character that's defined in the font description file, it doesn't seem that trying to second-guess what the user *really* meant is the right thing to do. More problematically, this behavior remains the same even if I turn ligatures off (via .lg 0). With ligatures off, groff has no reason to handle composite characters that translate into ligatures it knows any differently from composite characters that translate into ligatures it doesn't know. In this mode, it should simply output the glyph of every character exactly as encountered in the input. I feel that this goes beyond the realm of curious behavior and into the realm of being a bug. I confess to not being an expert in this area, so perhaps there is some rationale for this behavior that I'm overlooking. But there does seem to be some sort of flaw when groff makes it impossible to access by name certain glyphs named in the font description file. (The \N'' syntax does work, but this of course defeats kerning of these characters.)
