groff
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Groff] using Linux Libertine with groff


From: Tadziu Hoffmann
Subject: Re: [Groff] using Linux Libertine with groff
Date: Mon, 11 Nov 2013 11:12:35 +0100
User-agent: Mutt/1.5.21 (2010-09-15)

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]