Re: [Groff] using Linux Libertine with groff

[Werner LEMBERG]

>> 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