On Friday, 30 January 2026 00:26:46 GMT G. Branden Robinson wrote: > At 2026-01-30T00:03:42+0000, Deri wrote: > > On Thursday, 29 January 2026 20:40:52 GMT G. Branden Robinson wrote: > > > At 2026-01-28T22:15:21-0500, Peter Schaffter wrote: > > > > I didn't know. I thought we'd resolved family issues when we > > > > switched N and P for U-N and U-P ages ago. At the time, I > > > > proposed simply editing the document to use families that didn't > > > > cause trouble. I can't recall why, but I was discouraged from > > > > pursuing that path. I propose it again if it simplifies things. > > > > > > If I understand this Base 14 vs. Base 35 stuff correctly, it > > > _wouldn't_ help, or not much. Families N and P aren't in the Base > > > 14 set, so they'd need to be embedded in PDF anyway, and if their > > > font files weren't found, such embedding is not going to happen. > > > > > > Maybe Deri can shed some light on why the foundry was made explicit. > > > A quick glance over "typesetting.pdf" suggests to me that you're > > > _not_ using exotic glyphs. What you do use--I assume--is satisfied > > > by the 256 glyphs of Adobe's N and P families. > > > > With groff in intermediate mode (urw no, gs yes) all the 256 glyph > > default foundry fonts are available and can also be embedded. So you > > can use N & P. > > > > In basic mode (urw no, gs no) if you want typesetting.mom built stick > > to H, T, C families. > > We don't, at present, have a way to distinguish these two levels _in the > build system_. It's either: > > urwfontsupport = yes -> full service > urwfontsupport = no -> basic service > > That doesn't mean the build system imposes a degradation down to "basic > service" upon gropdf/devpdf--it means only that our Automake/Makefile > logic is more limited in how it's parameterized than gropdf itself. The > practical consequence affects questions like, "which artifacts (such as > PDF files) do we create during a groff build?" > > > Of course you could do something like:- > > > > .ie F NR .FAM N > > .el .FAM H > > > > Which would work in all pdf modes and ps would always use N (because > > NR is always available). > > If Peter's designed his page layouts flexibly enough that Helvetica > would look (about) as attractive as New Century Schoolbook, then I > reckon that might work.[1] We could then rip out the conditional > bracketing generation of the "typesetting.pdf" target.
That's for Peter to decide. I am still seeing build issues. :-( First lets agree our 3 test setups:- Basic ===== mv your urw font directory(s) somewhere safe. rename gs program to gs.sv configure --without-urw-fonts see message about missing ghostscript and basic pdf support after make these fonts available: CB CR CTH download Foundry HI JPM map/ symbolsl.afm TBI util/ CBI CSH CTS enc/ HB HR KOG S symbolsl.pfb TI ZD CI CSS DESC EURO HBI JPG KOM SS TB TR Currently no pdf documents are built, even though with the recent changes to grops.1 and gropdf.1 everything could be built except typesetting.mom (which could be added to the happy band with adding a conditional .FAM code which uses H or T if N or P are not available). Intermediate ============ rename gs.sv back to gs configure --without-urw-fonts see no messages about ghostscript and pdf support after make these fonts available: AB BMBI CI CTS Foundry HNBI JPM NBI PI symbolsl.afm TR ABI BMI CR DESC HB HNI KOG NI PR symbolsl.pfb util/ AI BMR CSH download HBI HNR KOM NR S TB ZCMI AR CB CSS enc/ HI HR map/ PB SS TBI ZD BMB CBI CTH EURO HNB JPG NB PBI stamp TI [derij@pip build (master)]$ ls contrib/mom/examples/ copyright-chapter.pdf letter.pdf mon_premier_doc.pdf slide-demo.pdf copyright-default.pdf mom-pdf.pdf sample_docs.pdf No typesetting.pdf even though N and P are available. groff-man-pages.pdf is built. Full ==== mv your urw fonts directory back from whence it came configure (option --with-urw-fonts-dir if it is non-standard place) see no messages about ghostscript and pdf support after make these fonts available AB CI Foundry JPM PI TR U-CBI U-HR U-TB ABI CR HB KOG PR U-AB U-CI U-NB U-TBI AI CSH HBI KOM S U-ABI U-CR U-NBI U-TI AR CSS HI map/ SS U-AI U-HB U-NI util/ BMB CTH HNB NB stamp U-AR U-HBI U-NR U-TR BMBI CTS HNBI NBI symbolsl.afm U-BMB U-HI U-PB U-ZCMI BMI DESC HNI NI symbolsl.pfb U-BMBI U-HNB U-PBI U-ZD BMR download HNR NR TB U-BMI U-HNBI U-PI ZCMI CB enc/ HR PB TBI U-BMR U-HNI U-PR ZD CBI EURO JPG PBI TI U-CB U-HNR U-S [derij@pip build (master)]$ ls contrib/mom/examples/ copyright-chapter.pdf letter.pdf mon_premier_doc.pdf slide-demo.pdf copyright-default.pdf mom-pdf.pdf sample_docs.pdf typesetting.pdf All present. Notes ===== Each run had a distclean and a bootstrap. All out of tree builds. No installs tested Hopefully Branden can duplicate the findings above. If so, and Peter is happy for a slightly degraded typesetting.pdf if N and P families are not available, then all groff pdf documentation can be produced no matter the state of finding the fonts, so long as -P-e is not used. This is the KISS solution. If it is desired to keep the embedded option then -P-e can be used except when configure outputs BOTH the ghostscript and URW font warnings. Interestingly if you don't use --without-urw-fonts the only difference is the suppression of a number of (now) non-fatal warnings when in basic mode. I wonder if this flag could be turned on automatically if BOTH the ghostscript and URW font warnings are output by configure, to save users having to inform configure a status it is already aware of. > Here's what I mean: > > $ sed -n '94,108p' contrib/mom/mom.am > if USE_GROPDF > MOMPROCESSEDEXAMPLEFILES = \ > contrib/mom/examples/letter.pdf \ > contrib/mom/examples/mom-pdf.pdf \ > contrib/mom/examples/mon_premier_doc.pdf \ > contrib/mom/examples/sample_docs.pdf \ > contrib/mom/examples/slide-demo.pdf \ > contrib/mom/examples/copyright-default.pdf \ > contrib/mom/examples/copyright-chapter.pdf > if HAVE_URW_FONTS > MOMPROCESSEDEXAMPLEFILES += contrib/mom/examples/typesetting.pdf > endif > momprocessedexampledir = $(exampledir)/mom > nodist_momprocessedexample_DATA = $(MOMPROCESSEDEXAMPLEFILES) > endif > > ...that `HAVE_URW_FONTS` thing could go (it's of pretty recent vintage). > > I haven't yet figured out if I can collapse the Automake variable > `HAVE_URW_FONTS` and the `AC_SUBST()`ed paramter `urwfontsupport`. They > do have similar meanings. (Identical? To be determined.) There's a > lot about Automake and its interaction with Autoconf that I don't > understand (yet?). > > Another thing I don't know is whether the choice of SHOUTING_CAPITALS or > runtogethershellvariablenames carries idiomatic significance or if it's > just the usual chaos arising from programmers with different symbol > naming preferences failing to coöperate with each other or achieve > consistency within a project. > > I don't see any of these issues as gating 1.24.0, personally. The SEGVs > (Bruno's and yours) are more pressing, with yours being more so because > that _does_ suggest a regression since 1.23.0. > > Regards, > Branden Cheers Deri > [1] At the same time it's nice to see something _other_ than Times, > Courier, and Helvetica in groff documents occasionally.
