[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" <email@example.com> 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
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.
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
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.