I got the following from Rufus, which I thought y'all might find
interesting... I asked him about the possibility of adding kerning
printouts to FONTTABLE.

Date:  28-Oct-90 09:38 CST
From:  Rufus Hendon [73250,2674]
Subj:  FONTTABL 3/Kerning

                                                                28 October 1990
Jim -
   Hold off on posting FONTTABL 3.0 -- I'm not finished with it yet, and I now
have your suggestion about BIN1/BIN2 to think about.  I had already planned to
include a patch program to enable users of A4 paper to adjust the left margin
so that the right column won't be half off the page; I'll extend that to handle
permanent change from LPT1 to some other port and probably the bin selection as
well. Please go ahead and copy COMPRESF to the Wordstar forum.  

   Kerning is a tough problem to deal with.  The Intellifont format handles
kerning differently from, say, the Adobe format.  PostScript fonts use the
familiar device of listing a series of particular pairs of characters, for each
of which an adjustment of the horizontal offset from the first character to the
second character is specified in order to achieve kerning.  Intellifont fonts
don't use kern tables of this kind.  Instead, a table of "sector kerning
values" is provided for individual characters.  (Not necessarily for all, it
would seem; the font designer can evidently decide which characters he wants
to provide such information for.)  A "sector" is a horizontal stripe containing
part of the character; the number of sectors into which the vertical dimension
is divided depends on the shape of the character, and is specified as part of
the description of the character.  

The sector kerning table for a given character (character a) specifies, for 
each sector, how far a following character (character b) can be moved to the 
left without encroaching on the portion of character a that falls in that 
sector.  The amount of movement depends on the shape of the character:  

If character a is "T", for example, the crossbar, which is in sector 1, 
allows less leftward movement of character b than do the lower parts of 
the stem, which lie in sectors 2-4.  The sector kerning table also specifies 
how much room there is on the left side of the character to accommodate 
rightward adjustment of the preceding character.  The actual kerning for 
characters a and b is then determined by using the right-side kerning 
information for character a and the left-side kerning information for 
character b to see how far they can be pushed together without a clash in
any sector -- to put it dynamically, the squeezing together of the two
characters halts as soon as a clash is imminent in any sector.

   If all characters in the font were provided with sector kerning tables,
the effect would be equivalent to the specification of 256 x 256 = 65,536
kerning pairs.  The printer would be performing calculations for every pair of
characters (characters a and b, b and c, c and d, ...) to see if they could be
moved closer together.

   The interesting question is:  Does this really happen?  I doubt it.  If this
theoretical kerning system were really in effect, no word-processing program
would be able to position line breaks and perform justification without having
access to the sector kerning tables for all characters in the font or an
equivalent n x n table (n = the number of characters in the font) giving the
kerning values for pairs of characters (the table could, of course, be made
sparse by omitting pairs for which no kerning is possible).  Certainly the
programs I am familiar with that support scaleable fonts -- Microsoft Word 5.0
and Microsoft Word for Windows 1.1 -- don't have any such apparatus.  What I
suspect is that the usual 300-dots-per-inch scalable fonts (including the
resident ones) don't have any sector kerning tables at all (they aren't
obligatory according to the FAIS standard).  

Whatever kerning is done is carried out by the word-processing program, not 
the printer, using traditional character-pair kern tables provided by the 
designer of the printer driver; kerning is then implemented by sending 
separate x-axis positioning commands to the printer to move the print 
position to the left after character a has been printed in order to put 
character b closer to character a.  In other words, the printer itself isn't 
doing any kerning (as the presence of sector kerning tables in the font would 
cause it to do); kerning is produced at a higher level, outside the printer, 
by the word processor.  (Incidentally, there doesn't seem to be any PCL 
command to tell the printer to turn font-based kerning off; if the font 
has sector kerning tables, it would appear that the printer has no choice 
but to do kerning using those tables.  Unless, of course, the Intellifont 
rasterizer in the LaserJet doesn't include the capability of utilizing 
the font-internal kerning information -- I think that may be quite likely.

In that case, all kerning would be the responsibility of the word processor, 
regardless of whether there are sector kerning tables in the font.)

   If it is true that the printer doesn't do any kerning based on sector
kerning tables present in the font (and this must be the case, otherwise the
word processor would have no way of doing correct line division and
justification), the AGFA Compugraphic fonts and fonts from other vendors in
Intellifont format don't have any kerning information in them, even though the
FAIS standard permits the optional inclusion of such information, or the
Intellifont rasterizer in the LaserJet is unable to use such information, which
comes down to the same thing.  The scalable fonts are therefore, in this
respect, no different from the bitmap fonts we've been using with the earlier
LaserJets.  Whatever kerning system a particular word processor uses relies
exclusively on information (e.g. a kerning table) internal to the printer
driver.  Since there isn't any kerning information in the font itself (or the
printer is incapable of using it) and FONTTABL operates independently of any
word processor, there isn't any way to get FONTTABL or a program like it to
provide information about kerning.

   As far as I can see, the only way to do what you suggest (print samples
showing kerned pairs, to be examined to see if fine-tuning is required) is to
operate from inside the particular word processor.  A sample would be printed,
then the printer driver would be edited to make changes to the kerning table,
another sample would be printed, and so on.  With some word processors, it
might be possible to make the process somewhat less tedious by writing a macro
that would dynamically alter the kerning table, so that a series of trials
could be printed without having to exit after each one to edit the printer
driver.  The word processors I'm familiar with, though, don't provide any
obvious way in which dynamic modification of the kerning table could be
accomplished; I don't think you could even locate it in memory.

   For bitmap fonts, a different approach would be possible.  A program could
be written that would display text in a given font on the screen, in graphics
mode.  The information contained in the kerning table of the printer driver
provided with a particular word processor could be converted to some generic
form and made available to the program, so that the standard kerning
adjustments would be made on the screen.  The spacing of particular pairs
could then be interactively adjusted with the results immediately visible, and
any changes that appear to be worth saving could be saved.  When execution was
terminated, the program would write a new kerning table in the generic format,
incorporating the changes saved during the session.  This generic table could
then be converted to the format required by the word processor and put back
into the printer driver as a replacement for the original kerning table.

   I already have a program, ADJBEAR, that essentially does this.  Its purpose,
however, is not to generate a kerning table but to adjust the left and right
side bearings of characters in a bitmap font to achieve optimum character
spacing.  (LaserJet bitmap fonts use these side bearings as a low-level method
of kerning; "j", for example, is given a negative left side bearing so that its
tail will overlap the preceding character slightly.  Since this method of
kerning doesn't take into account the identity of the adjacent characters, it
is rather crude, and the side bearings have to be set so that the results look
right with all combinations into which the character enters; the left side
bearing of "j", for example, can't be made so negative that it would cause the
tail to be overprinted on the descender of any character with which "j" is
likely to be combined.  I think in some cases designers of LaserJet fonts have
given "j" a left side bearing that actually would create an overlap with a
preceding "g" or "q", but they rely on the fact that the combinations "gj" and
"qj" don't occur in English.)

   I believe there are also commercial or shareware programs that generate
kerning tables for bitmap fonts.  I think, for example, that Softcraft has
something called KERN or KERN! or the like.

   Incidentally, FAIS stands for "Font Access and Interchange Standard".  I
now have the FAIS manual, but it will take an awful amount of work to make
sense of it and to translate it into programs that could actually extract
information from an Intellifont-format scalable font or modify the font.

   Thanks for the kind things you say about FONTTABL 3.00 -- even though your
words of praise are cunningly accompanied by suggestions for new tasks
designed to keep my nose to the grindstone.

- Rufus


Date:  28-Oct-90 15:48 CST
From:  Rufus Hendon [73250,2674]
Subj:  FONTTABL 3/Kerning

   Share it if you want to, as long as it doesn't involve making it
publicly available.  What I said about kerning is my current guess as to
what the situation is, but I could be wrong -- I don't want to be in the
position of telling people confidently something that may not be right.
                                  Rufus
