At 2026-01-28T22:43:08+0000, Deri wrote: > On Wednesday, 28 January 2026 21:04:57 GMT G. Branden Robinson wrote: > > Can you clarify whether your grievance is with "--without-urw-fonts" > > existing at all, or with its presence as a "headline" item? > > Well I suppose it is both since I don't understand why you promoted > normal warnings to abort a build, I am unlikely to understand why a > sticking plaster solution deserves such prominence.
1. Because it is a bad practice to train people to ignore warnings.
Do you require me to cite authorities on this point?
2. Because the stock/default/preferred configuration of gropdf is its
"full service" mode, which has an external dependency: the URW
fonts. The URW fonts have proven fickle in at least two different
dimensions: the URW foundry keeps changing the file name it uses for
these fonts, and distributors keep changing the directory name into
which they install them (and can't agree on same). Further, the
mere presence of the desired URW font files is insufficient for
gropdf to attain its "full service" support level. The "Foundry"
and "download" files must also be appropriately populated, and each
of these files contain strings corresponding to the ever-shifting
names and locations of the prerequisite externally supplied files.
We could invert the stock/default/preferred configuration, assume
that URW fonts are wholly unavailable, resulting in gropdf's "basic
service" level, and require that people building groff from source
"opt in" to gropdf's higher-tier features.
I don't think you'd like that, as it would exhibit fewer fruits of
your labor. _I_ wouldn't like that as a groff developer, because I
want to see difficult code paths, even in configuration code,
frequently traversed so we can make them robust. I also wouldn't
like it my (newer) role as _maintainer_, because it would less
effectively advertise groff's capabilities as a typesetting engine,
which as I observed recently on this list, are routinely derogated
by ill-informed people.
3. A lot of people still employ groff as a mere man page formatter for
terminals. Ingo has not yet managed to suck them all over to
mandoc(1). I want to support that audience without alarming them
with heaps of warnings about files they don't care about, like
"typesetting.pdf" (a mom(7) example), or "groff-man-pages.pdf" when
it can't locate embeddable font files for the roughly 33 text
typefaces supported by grops and gropdf. (Their man pages
illustrate each face, which furthermore serves the goal of making
failure of this mechanism easy to spot.)
Is that adequate justification?
> > You seem to be justifying the latter with an argument against the
> > former, and the latter is the topic under discussion.
>
> Perhaps, if you explained what "slight" or "chunky" things go wrong,
I think what I had in mind when writing were these:
Slight: a font isn't embeddable, but no damage is done because it's one
of the base 14, which most PDF viewers will adequately render.
Chunky: a font is required but not embeddable, so you get whatever
failure mode PDF allows/prescribes for that scenario--I think
one is blank areas of the page where readable glyphs should be.
(I _think_ this can happen if the metrics are available to
groff, but the font file itself is not, and the viewer doesn't
perform a substitution. I have no idea whether that behavior is
within the PDF spec or not.)
Generation of "typesetting.pdf" from "typesetting.mom" fails hard if the
"U" foundry is not available. The document composes its pages
carefully, and uses the New Century Schoolbook and Palatino families,
which are not in the Base 14, so I judged that it's better to not
produce a PDF at all than to render the wrong font. I welcome feedback
from Peter if he was unaware that this was a failure scenario and would
like to take some alternative approach.
With "groff-man-pages.pdf", it actually doesn't matter all that much if
the names of the fonts in the "Typefaces" seconds of grops(1) and
gropdf(1) aren't used to set themselves, so falling back to Times roman
is okay. It's not like people reading these man pages in the terminal
get to see the pretty fonts in any case.
> I might agree --without-urw-fonts is the best thing since sliced
> salami.
I would never tout it so highly. I think you're presenting a false
dilemma between "sticking plaster" and "best thing since sliced salami".
As explained above, I added the option because we saw people testing RC1
on dozens of host platforms--Nelson reported about 70, I think--some of
which don't package the URW fonts. It shouldn't be necessary for people
who want to test groff--doing us a quality assurance favor!--to obtain
anything that isn't "packaged" for whatever sort of distribution,
container, VM, or other host system they're using. It should be enough
to take groff's distribution archive, read INSTALL.extra, satisfy any
build dependencies listed there (which are fairly light and usually
"packaged"), and then run "configure" and "make".
platform-testers isn't quite a continuous integration system (CI), but
it has many of the same benefits--just on a more episodic basis. Make
life easy for CI, and CI will pay you back by catching problems it
would've taken developers weeks more to notice.
Volunteer testers also aren't, as a rule, intimately familiar with
groff. How are they to know what to make of the blitz of warnings one
would get when gropdf was degrading to its intermediate or basic service
levels?
Such warnings as remain _should_ be fatal ones, _because they are
unexpected_ (by groff developers).
The more easily the question "should I be concerned about this
diagnostic message?" can be answered, the better.
> There could be a huge problem of which I'm unaware.
If so, I don't think you want it lost in the noise I was seeing when I
built without URW fonts where our `GROFF_URW_FONTS_CHECK` Autoconf macro
could find them.
Also, if anyone would like to reduce the number of warnings a groff
build emits, please have a look at Savannah #62932.
https://savannah.gnu.org/bugs/?62932
> > I'm not at all wedded to this (brand new) configuration option as a
> > headline item. But I get the feeling that throwing it out would not
> > suffice to satisfy you.
>
> You are perspicacious. :-)
Since your objection is to the new configuration option rather than its
"headline" per se, your reply was unresponsive to the question I posed.
Starting a new thread to complain about the new configuration option
would have been better.
Incidentally, Dave has been awaiting a reply from you in Savannah #66342
since 8 December.[1] So have I. That's me using this thread to raise a
clearly distinguishable issue.[2] It is said that turnabout is fair
play...
Regards,
Branden
[1] https://savannah.gnu.org/bugs/?66342#comment9
[2] I do not say "independent" or "orthogonal"; there _is_ coupling
between the headline item and URW font support in that if we lacked
the latter, we need not have a headline. And similarly, if gropdf
didn't support embedding fonts at all, the whole issue of URW font
support would go away, as would the question raised in #66342. But
these matters are not somehow all the same thing.
signature.asc
Description: PGP signature
