Re: [Groff] Devps unmatched metrics

[Tadziu Hoffmann]

> I usually don't do that. The reason is that the lifecycle
> of a typical document, at least of the ones I usually have,
> is very different from that of typical software: My documents
> are written at a certain time, then finished, and remain
> essentially unmodified from that point on. Nevertheless, I
> do want to be able to regenerate them years later. Thus, if
> I would keep the macros separate from the document, I would
> have to worry about compatibility. On the other hand, the
> old documents typically do not benefit from bugfixes to the
> macros, since a bug that had affected them would typically
> have been fixed during their own development - this is since
> a relevant bug is a visible one (very different from software
> again). So what I do is: I keep the macros with each document
> and copy the best or latest version of them each time I start
> a new one. At least for my situation, I've found that this is
> by far the most convenient approach.

I agree.  This was also what I had in mind when I said
"keeping the actual text and the formatting macros separate".
I was thinking of "separate" as in "not having text and macros
intermingled in the same file".

In principle, one would also have to keep the necessary fonts
together with the document.  But the font modifications I was
thinking of are more in the sense of fixing design deficiencies
that shouldn't have been there in the first place [okay, that
goes for *all* software bugs], and, furthermore, these are not
changes one would make on a document-by-document basis (in
contrast to customization of the macros, which are usually
not bug fixes but adaptations to the style of the document).

Reproducing a document *exactly* usually isn't my main concern
(you can save a PDF for that).  I also find that my views on
what's important in typography change over the years, so that
when I need a new copy of an old document I usually reformat
it anyway (what's important is the text content).  But still,
keeping a reference version around is handy, and here your idea
of keeping font adaptations such as kernpairs (as opposed to
the complete font files themselves) together with the document
is particularly attractive -- not necessarily for the purpose
of being able to exactly reproduce the document, but instead
as a personal reminder of what you thought was important when
initially formatting the document, and which might still be
relevant when switching to a different font, layout style, etc.


> I always try to avoid modifications to fonts; I often find
> the .char request handy in such situations.

I don't think I'm really keen on modifying fonts either.
I was just surprised to find that there's no real consensus
on how to position italic characters within the design grid.


----------------------------------------------------------------

Anyway, as promised, here's my font installation script
(as yet without provision for a "PFA-edited" directory;
I'm still thinking on how to best handle that).

The fonts are given the Postscript FontName as internalname.
This way the names should be reasonably unique and I don't
have to think up arbitrary new names.  The recommended way
to access the fonts is with the 3-argument version of "fp".
E.g., at the beginning of the document say

  .fp 1 TR Utopia-Regular
  .fp 2 TI Utopia-Italic
  .fp 7 HB LubalinGraph-Demi
  (etc.)
  .EQ
  gfont TI
  grfont TR
  .EN

and then the rest of the document can simply assume that
font "TR" refers to the roman/regular font used for body
text, and font "HB" refers to a bold font used for section
headers, etc.

mkgrft
Description: Text document