Re: bug in fontinst 1.801: duplicated kernings (was: ae fonts Q)

[Lars Hellström <Lars.Hellstrom@math.umu.se>]

Vladimir Volovich wrote, on the topic of why certain lines of code had been
commented out:
>Hmm... i've just checked, and found that when those lines are
>uncommented, fontinst generated duplicated kernings, e.g.:
>
>   (LABEL D 27) (COMMENT ff)
>   (LIG D 105 D 30) (COMMENT i ffi)
>   (LIG D 108 D 31) (COMMENT l ffl)
>   (KRN D 39 R 0.7699) (COMMENT quoteright)
>   (KRN D 63 R 0.7699) (COMMENT question)
>   (KRN D 33 R 0.7699) (COMMENT exclam)
>   (KRN D 41 R 0.7699) (COMMENT parenright)
>   (KRN D 93 R 0.7699) (COMMENT bracketright)
>   (KRN D 39 R 0.7699) (COMMENT quoteright)
>   (KRN D 63 R 0.7699) (COMMENT question)
>   (KRN D 33 R 0.7699) (COMMENT exclam)
>   (KRN D 41 R 0.7699) (COMMENT parenright)
>   (KRN D 93 R 0.7699) (COMMENT bracketright)
>   (STOP)
>
>there are 10 kern pairs, of which the last 5 repeat the forst 5.  This
>looks like a bug in fontinst... I'm mailing a Cc: to the fontinst
>list.
>
>Description of a bug: if one uncomments some commented kerning stuff
>in aelatin.mtx from the ae fonts package (e.g. shown above), then
>fontinst generates duplicated kernings. Please, help to fins the
>reason/correct this problem.

As fontinst is constructed (as v.1.504 is constructed anyway, I haven't had
the time to chech out v1.8 yet, but I wouldn't expect any differences here)
all \setkern commands store an extra kerning instruction in the \l-GLYPH
and \r-GLYPH control sequences, for use when the LIGKERN table gets written
to the VPL file. If two \setkern commands are executed for the same
character pair then two kerns for the same character pair will be written
to the VPL file. The second kern won't affect the typeset result but it
will occupy one word of font memory in TeX and it will cause TeX to work
slightly slower (hardly noticable, though) since TeX will have to examine
an additional kerning instruction in every case where it will eventually
conclude that no kern should be inserted.

I have written a modification of the relevant parts in fontinst which would
fix the "bug" you describe (as well as allow kerns to be changed after they
have been set), but I should update that before I could expect anyone else
to try to use it. It should work fine under v1.504, though.

Lars Hellström