> > 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.
