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

Re: kern pairs in CM fonts TFM

On Wed, 26 Mar 1997 08:49:07 -0500 (EST),
"Berthold K.P. Horn" <bkph@ai.mit.edu> wrote:
: re: apparently conflicting kern pairs in CM TFM files.
: Can anyone tell me where the apparently contradictory kern pairs come from in
: CM TFM files?

They are declared in the Metfont source.  For example CM's "roman.mf"
contain the two lines

 ligtable "k": if serifs: "v": "a" kern -u#, fi\\"w": "e" kern k#,
  "a" kern k#, "o" kern k#, "c" kern k#;

If "serifs" is defined, there will be two different kern pairs for
"k"+"a", but they won't do any harm:

	TeX will take only the first matching kern or ligature

: There are a few cases where there are two occurences of a
: particular kern pair with different kern amounts.  Now presumably TeX stops
: looking after it finds the first one, so one of these values is always
: shadowed.

Correct.  The kerning/ligature table is search for a matching pair
using a simple linear search.

: But I am curious whether this is an `optimization' that METAFONT
: does, or whether it is something the font author has control over.

As shown above, it is under the control of the font author... and
Metafont won't remove shadowed pairs.

An addition:

I have made prototypical reimplementation of TeX's ligature/kerning
builder to allow kerning between two ligatures.  (With TeX it is only
possible to kern between a ligature/character and the following
character.  Even if the following character will form a ligature
afterwards, TeX doesn't support ligature-ligature or character-
ligature kerning because of the necessity to backstep.)
  This reimplementation is running.  It separates the necessary
ligature pass from the following kerning pass, nonetheless both passes
can be implemented in a single pass(!).  The new algorithm allows
suppressing ligature building and for this case it's possible to do
some kerning using the fact that the kerning/ligature table of a font
can have both: a kern and a ligature step between two
character/ligature pairs.
  Before someone will ask: The implementation was done in Common-Lisp,
implements left/right boundary characters, has a compatibility switch
to get TeX's original behaviour (for comparison: the re-implementation
of the read-tfm-font function needs ~500 lines of code, the new dolig
function needs ~180 lines), and it's planned to incorporate this
algorithm rewitten in Web-Pascal in one of the next e-TeX versions.