>> I think this is because afmtodit assumes these ligatures will be
>> called "fi", "fl", "ff", "ffi", and "ffl", but in the new fonts
>> they are called "f_i", "f_l", "f_f", "f_f_i", and "f_f_l".
Yeah, this is a partly a limitation and partly a design problem, see
below.
> I see. It looks like afmtodit looks for variants with spaces in the
> names, but not underscores:
>
> $ fgrep -A6 'default_ligatures =' `type -p afmtodit`
> my %default_ligatures = (
> "fi", "f i",
> "fl", "f l",
> "ff", "f f",
> "ffi", "ff i",
> "ffl", "ff l",
> );
Nope, it only looks up the values to the left; the right ones are the
corresponding `L' entries of the AFM file (which afmtodit synthesizes
instead of looking at real `L' values).
>> (I believe other ligatures can't currently be used with groff.
>> As far as I know, this is hardwired.)
>
> Yes, according to "info groff gtroff fonts ligatures", those five
> are the only ones supported. A quick grep through the code shows
> that src/include/font.h defines five enum values in class font, for
> LIG_ff, LIG_fi, etc. And as the above code snippet shows, those are
> the only ones afmtodit looks for.
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. 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, and afmtodit
could easily map entity name \[Fl] to `f_f_l' (by extending the
`symbolmap' file), for example. The worse alternative is to patch
afmtodit to make it synthesize an `ffi' entry from `f_f_i', and ditto
for the other ligatures.
> It should be fairly straightforward to add new hard-coded ligatures
> to the groff source, and to afmtodit.
Well, the concept of ligatures in the today's font world is much more
complex than 30 years ago, so extending hard-coded values is a no-go
IMHO.
Werner
