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.
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
[1] At the same time it's nice to see something _other_ than Times,
Courier, and Helvetica in groff documents occasionally.
signature.asc
Description: PGP signature
