# [Dev-luatex] Wishing is free: fonts and glyph placement

Javier Múgica javier at digi21.eu
Tue Oct 20 12:01:15 CEST 2009

If one takes a look at the kerning pairs of a font with many accented
letters, for instance lmr10, there are many "duplicate" pairs, in the
sense that in addition to "ko" there also appear "kó", "kò", "kô" and
so forth, and "ke", "ké", etc., obviously with the same kerning value,
and if we had \'k (accented k) then all of the combinations again. If
a new accented letter gets added, all its pais have to be encoded.
There is clearly some logic missing there.

The idea is that something which is at the right like k, plus
something which is at the left like o, needs a kerning of such and
such.

While the quadratic grouth of pairs is still tractable for normal text
with the current speed and memory capacities of computers, it becomes
out of control in math, where the possible pairs is beyond any
tabulation capacity. I for example had recently Q\Sigma, which clearly
requires kerning.

The underlying problem is that TeX does not take into account the
actual shape of the glyphs, but just its enclosing rectangle. Since
this is not sufficent for high quality typesetting there are two
pieces of information relating to the shape of the gliph beyond the
enclosing rectangle that TeX knows about: the kerning pairs and the
italic correction.

There are just two patches that leave many situations to be manually
adjusted by the editor (I refer to the person), depending on his
patience and quality standards, specially in math, where both the
pairs of gliphs that get combined and the relative position of them is
virtualy unlimited.

While computing gliph spacing by analyzing the glyph's shapes may be
too involved, a good, easier solution could be that, in addition to
the rectangle enclosing the glyph, another shape were known, not so
complicated as a glyph's shape but not so crude as a rectangle. I
could be restricted to a one-piece polygon without holes enclosing the
character and leaving a little space between its border and the
character (as the character's box currently does).
For example, the polygon for the letter k could be a rectangle with a
wedge intruding at the right side, while that of o, ó, e, etc. could
be an octagon. So when these characters were placed together it would
be done so that the respective polygons touch, instead of the
rectangular boxes as is now the case, and the need of kerning would
disappear.

This approach would:
-- reduce the kerning pairs drastically
-- need a linear grouth with the number of glyphs in the font (the
-- New glyphs, specialy adorned variants of existing ones, would
automatically get the correct spacing with existing ones.
-- Pairs that seldom appear and are thus not considered in the
kerning tables, would also get the right spacing automatically.
-- The unlimited possible combinations inside math would get handled
correctly. Most of them or at least many.
Thus, the need for dozens of \! \, \phantoms and like stuff would
decrease substantialy. Here are some examples:

\Bigg)_{\!0}  (or was it even _{\!\!0}?)

f^2\,)  %here it is the left protruding of the )'s polygon that would
come into play.

1/\!\sqrt{3}

This requires adding another piece of info per-character in the font.
Now I can't remember how the tables of an OT font are orginized and
don't know whether this is possible or not.

The inconvenience I see in trying to compute the spacements based
directly on the shape of the gliph (with respect to the polygons I'm
proposing), appart from the many bugs that could be present till it
finally got properly programmed, is that it is too big a jump form the
current glyph placement algorithms in math, but it may well be that my
fears are unjustifed. The polygon approach has also the advantage that
it is easier to define the polygons so as to obtain the current
spacing between the most common kerning pairs, while it would be more
difficult to program an algorithm based on the glyphs' shapes
achieving the same effect, but on the other side it need not be better
to exactly preserve the current kerning values.

It may be too son for proposing this now, but I'm sure this will
sooner or later (possibly later) come to be discussed, since for the
finest text editor, a glyph placement in math based solely on the
rectangle of the glyphs and the italic correction cannot possibly be
the definitive solution.

Cheers to all

Javier A. Múgica