Re: [Groff] Devps unmatched metrics

[Gunnar Ritter]

Tadziu Hoffmann <address@hidden> wrote:

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

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.

In contrast, software is never finished and has important
invisible bugs, so the equivalent of troff macros (headers,
libraries, etc.) totally makes sense with it, of course.

And then, of course, it is possible to have macros that
only contain .kernpair requests if desired, so it should
be a sufficiently generic mechanism to satisfy everyone,
including people that disagree with me on the above.

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

Yes, they do have to have exactly the same fonts, but
nothing else with my approach. Fortunately, most fonts do
not change very often (though I wouldn't dispute that this
sometimes is a problem).

But this also affects my own copies; I want to be able to
reproduce a document years later. Thus, with font or macro
modifications separate from the document, I would either
have to have versioning with them as well, or undertake
the almost impossible task of complete compatibility.

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

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

Gunnar