Re: [Groff] Devps unmatched metrics

[Tadziu Hoffmann]

> > The neat thing about groff's way of having the (editable)
> > metrics file separate from the actual font file (as opposed
> > to, say, a system where the metrics are read directly from a
> > not-so-easily-editable truetype or opentype font file), is
> > that it is extremely easy to adjust things like the subscript
> > kern for individual letters or to add new kerning pairs.

> With this I disagree (not with the feasibility, but with
> it being good software design). It means that in order to
> reproduce a document, you have to distribute the metrics
> as well. It also means that automatic kerning is restricted
> to the glyphs of a single font. These were the main reasons
> why I introduced the ".kernpair" request in Heirloom troff.

You're right.  Good software design would be having not only
the metrics but also the glyph outlines in a textual format,
so that they too could be edited by the end user. ;-)

But seriously, regarding document portability I concede your
point: anything that goes beyond the "standard" should become
part of the document.  (Especially that cross-font kerning
is a pretty neat idea.)

On the other hand, the same goes for (extensions to) the
macro package used, and I believe a good case can be made for
keeping the actual text and the formatting macros separate.
Therefore I don't consider it particularly restrictive if I
have to edit two different files to achieve my desired results.
(After all, kerning information is font-related, so why not
put it where it belongs?)  If you're talking about others
being able to reproduce a document at that particular level
of detail, I think you need to also make sure that the others
are using exactly the same versions of the fonts that you're
using and also the exact same version of the macros (thus,
you'd probably have to distribute these as well).

Furthermore, it might perhaps not be sufficient to only adjust
the "normal" kerning, but also other metrics of the fonts,
meaning that the formatter would need to provide to the
document an interface to the entire internal font machinery.
An example that comes to mind is subscript kerning in
equations.  (But for expressions that are used often it is
usually simpler to define a suitably fine-tuned macro in eqn
and just use that macro.  Of course one could do the same in
the body text of the document, but whereas in TeX you could
just write "\keV" or whatever, which is not too much of an
extra effort to write, in troff you'd need to type "\*[keV]"
which is much more cumbersome.)

Even worse, due to bizarre inconsistencies between fonts
it may even be necessary to modify the actual font files
themselves (or to implement appropriate correction mechanisms
in the text formatter).  Example: in math, one often uses
accents to denote certain mathematical concepts (operators,
particular properties of variables, etc.).  For a slanted
letter (e.g., variables set in an italic font) the accent has
to be right-shifted correctly for the result to look good.
My naive interpretation of how eqn goes about doing this
is that it centers the accent in the width of the character
and then shifts it over by the slant times the height of the
character.  But the accents were often shifted over too much,
and I thought that the italic angle specified in the font
description file was incorrect.  I could fix the problem by
reducing this value, and this actually worked very well.

However, while reworking my font installation script I have
reexamined the issue and it turns out I was wrong: the italic
angles are usually correct.  The problem is that the letters
are often differently placed in their (skewed) "bounding
boxes".  For the spacing between letters of the same font this
does not matter, since only the advance widths are important,
so my guess is that the font designer did this for reasons
of appearance in a mixed slanted/upright font environment,
e.g., to reduce the amount of white at the beginning of a line
and to prevent characters from sticking out too much at the
end of a line (although that could have been better handled
within text-processing applications by kerning with suitable
(invisible) beginning-of-line and end-of-line characters).

What's more, this varies completely from font to font.  Two
contrasting examples are Times-Italic and Helvetica-Oblique.
Helvetica-Oblique is just a slanted version of the normal
upright Helvetica, and here the characters are perfectly
centered in the skewed boxes, whereas in Times-Italic the
characters are noticeably shifted to the left.  Fortunately,
the transformation matrices in the PFA files are outside
the encrypted part and can be modified (but the metrics
will have to be regenerated as well).  I'll see whether
fixing the matrices has any negative effects on typeset
text (transitions from roman to italic and back will be
different), and probably fixing the accent positioning
with a font-dependent correction value in eqn will be the
best solution.