PostScript fonts and the groff build process (was: [ms] Add a standard glyph name for hooked o instead of relying on .AM?)

[G. Branden Robinson]

At 2021-01-13T04:34:50-0600, Dave Kemper wrote:
> On 1/4/21, Denis M. Wilson <dmw@oxytropis.plus.com> wrote:
> > rfc1345 does not have a base-line ellipsis, a character frequently
> > used in English writing.
> 
> > It is available as \N'188' in the symbol font or as \[u2026].
> 
> Since commit aac5fd24 (2003), it has been available in the Symbol font
> as \[u2026] as well, no longer requiring the \N syntax to access it --
> a good thing, since, like .char, \N inhibits kerning (though this is
> moot for the ellipsis in the default groff fonts while
> http://savannah.gnu.org/bugs/?58897 is unresolved).

I was looking at #58897 just the other day as I slowly grind my way
though "[PATCH]"-annotated Savannah tickets.

I reckon it can be applied as-is, but it brings to my mind a smelly can
of worms that I keep finding under my nose when I research several
different outstanding Savannah tickets, and that is the relationship
between the PostScript core fonts[1] and the groff build process.  Right
now these are completely decoupled in the procedural sense, and this
causes grief in multiple respects.  Even if Adobe's fonts are stable (or
moribund), GhostScript's aren't.  This has caused issues with
distributors seeing groff mysteriously break when GhostScript gets
upgraded, forcing a rebuild of groff against the new ghostscript.  As I
understand it, it also led to the weird \[lh] (left hand) glyph problem
that Werner recently analyzed[2].

To me, it seems like afmtodit should be run against Adobe or GhostScript
PostScript Level 2 fonts as part of the groff build process, which means
a build-dependency of some kind, and this further leads to the
uncomfortable question of the non-freeness of the Adobe fonts and
whether GhostScript's replacements are truly metrically identical.  I'd
answer this question for myself except I cannot figure out where to
download Adobe's PS Level 2 font repertoire!  Can someone tell me?

I don't think the non-free build-dependency issue is a real challenge,
it just moves the lump in the carpet.  As I have argued before, the font
metrics themselves should be uncopyrightable under U.S. law and they can
be extracted and distributed as part of groff.  Re-extracting them (or
verifying their continued stasis) for each new groff release would then
be a procedure for our recently-added FOR-RELEASE file.

I'm not too concerned with the _esthetics_ of GhostScript fonts--if they
look ugly, those are bugs in GhostScript and we can report them.  If the
metrics are truly incompatible, then either that's a GS bug or we really
do need to add the foundry feature

https://savannah.gnu.org/bugs/?58969

and distinguish URW from Adobe accordingly.  This, too, should not be a
big deal, as conscientious Free Software distributors and users should
already have or prefer the URW fonts anyway.

_If_ we can solve these build-time issues, then we can also solve some
distributor problems, by encouraging them to use package triggers to
regenerate relevant groff font files with afmtodit when the actual fonts
on the system are updated.  I suppose this would be done for devps and
devpdf.

These matters have been troubling me for some time, and I don't feel
confident that I fully understand them, so I would appreciate
corrections to any of the above.

I do sense that addressing my concerns will involve some mild
architectural work, and I am pessimistic that anything beyond Dave's
patch in #58897 (which I've already applied to my local Git checkout,
and which will appear in my next push after I verify that it does no
harm to generated files) can be done in time for groff 1.23.0.

Regards,
Branden

[1] https://en.wikipedia.org/wiki/PostScript_fonts
[2] https://savannah.gnu.org/bugs/?59531

signature.asc
Description: PGP signature