Hi Deri, [This message took a while to compose. Edits are marked.]
It sounds like the remaining issue lacking clarity or requiring decision
to finalize groff 1.24.0 (in this respect) is "how many font
descriptions should install to font/devpdf when gropdf is available at a
service level other than 'full'"?
For those just joining us, I'm including the new "URW font support"
subsection of the gropdf(1) man page as a footnote. It provides
necessary background.[1] (I'm beginning to think this section should be
retitled "Service levels and URW font support".)
There are two "inferior" gropdf service levels ("basic" and
"intermediate"), and two sets of font descriptions it makes sense to
consider. Both sets apply to the default (Adobe) foundry. They are the
PDF Base 14, and the PostScript level 2 Base 35. Ignoring the font file
format, the latter is a superset of the former.
So we could do this (Automake configuration "A"):
basic: 14 fonts
intermediate: 35 fonts
or this (Automake configuration "B"):
basic: 35 fonts
intermediate: 35 fonts
A point possibly in favor of configuration "B", and which I could not
find any better place to document in this message, is that Ghostscript's
"%rom%" search path feature, wherein the program has an unknowable set
of built-in fonts available to it, means that documents can format
correctly even when we have no reason to expect they might from
inspecting the file system. I remember a couple of years ago you were
skeptical that this configuration of Ghostscript was something that is
still done, but I keep running into it. The Ghostscript in Solaris 11,
at least the one installed on the relevant host in the FSF France's
compiler farm, has this trait. Does this information influence your
thoughts?
Given that context, I'll now try to tackle your messages.
At 2026-02-04T16:12:24+0000, Deri wrote:
> I believe readers look for the urw fonts on your system and may supply
> them if they are not embedded, they definitely do not come with their
> own private copies. So in the case where gropdf is in basic mode and
> has not found the urw fonts, it follows that any pdf reader is also
> unlikely to find the font requested. The attached pdf is produced with
> current master with the unwanted extra fonts that do not have real
> fonts to embed. Also a png showing how it looks on my system in
> okular, (xpdf refused to show anything at all).
Right. Looks like Okular fell back to Helvetica italic.
> Looking at the pdf on your system, it may look different, if you have
> urw fonts installed, but we are talking about the user who is using a
> basic mode groff without any urw fonts installed.
For me, xpdf found Zapf Chancery medium italic...or something that looks
a lot more like it than Helvetica italic, at any rate.
> You have said you wish to show off groff's typographical abilities so
> allowing a user to produce pdfs like this may well put them off using
> groff.
I suspect that you, too, want to show off the abilities of gropdf in
particular. :) That might militate shipping as many different font
descriptions as possible at all service levels ("configuration B").
However you also, I perceive, want gropdf to support a wide variety of
host configurations (in terms of what non-groff resources or packages
are available). That means having graceful, documented degradation
paths when gropdf cannot be employed to its fullest and most flattering
extent. A person using the "basic" service level might wonder why groff
ships with font descriptions it can't fully use, or why they should want
to use gropdf to produce a PDF that renders a blank page, as with xpdf
and your example on your system. If a device-independent formatter
(troff) has no description for the font a document selects, it can't
select that font--there are no metrics for its glyphs, so it doesn't
know how to position them--and ignores the font selection attempt. This
scenario militates for restricting the set of descriptions available at
the basic service level to the 14 that any reader/device conforming to
the PDF standard is expected to render satisfactorily (if in a
"fallback" mode about which recent versions of the standard wags its
finger): in other words, "configuration A".
Each of the foregoing approaches has pros and cons. So the best kind of
decision, a correct one per our (unspecified) system of mathematical
logic, is foreclosed to us, and we must make a sweaty, grimy engineering
decision that subjects us to trade-offs and compromises.
> This behaviour has only been changed in the last few weeks, it was not
> done in rc1.
That might due to fallout from my reorganization of the Automake
variables used, and also from (not completely consciously, perhaps)
flipping my perspective between each of the two above. Or it might be
because you managed to get your build tree into a bad state--more on
that below.
> So this change (munging the build devpdf directory during install)
I don't think that's what's going on. Consider the scenario of running
"make" followed separately by "make install". I don't perceive the
build directory being altered in any way by "make install". If it is,
that's a bug utterly independent of the topic at issue.
Can you reproduce this misbehavior? If so, please advise of a host
configuration that does so. Sharing the "configuration summary" as
reported by the master branch in Git (that is, post-rc2) _should_ be
enough for me to suss it out.
[EDIT: I see you did that in the subsequent message quoted below.]
> is very recent, typographically it is hit and miss for the user, and
> the pdf produced does not conform to pdf standards. I hope these are
> reasons enough to restore the behaviour seen in 1.23.0 for basic
> users.
I don't think there's an obvious superior choice here. I ask you to
express your preference between "configuration A" and "configuration B".
At 2026-02-04T16:12:49+0000, Deri wrote:
> > > These extra (non base-14) fonts have appeared in the build
> > > directory and been installed. Is this normal make install
> > > behaviour.
> >
> > Not if you "make distclean" and re-"configure" after uninstalling
> > whatever packages supply the URW Base 35 fonts on your system. :)
>
> Ok, thanks I'll try exactly that, let me know if I am doing something
> wrong.
>
> URW fonts gone. Check
> Ghostscript gone. Check
> git checkout master. Check
>
> Now go. (cwd 'build' directory)
>
> make uninstall
> make distclean
>
> # A bit of belt'n'braces
> cd ..
> rm -rf build
> mkdir build
> cd build
> rm -rf /usr/local/share/groff/1.24.0
"make uninstall" _should_ work just as well here (better, even, since it
will also clean out groff's executables and man pages).
If it doesn't, I urgently want to know about it!
> ###
>
> ../configure --without-urw-fonts
> # see missing ghostscript message and no urw fonts
> make -j
>
> make check
>
> ============================================================================
> # TOTAL: 310
> # PASS: 299
> # SKIP: 6
> # XFAIL: 5
> # FAIL: 0
> # XPASS: 0
> # ERROR: 0
> ============================================================================
Everything seems reasonable so far.
> $ ls font/devpdf
> CB CI DESC enc/ Foundry HBI HR S symbolsl.afm TB TI util/
> CBI CR download EURO HB HI map/ SS symbolsl.pfb TBI TR ZD
>
> sudo make install
>
> $ ls font/devpdf
> AB BMB CB DESC Foundry HNB HR NI PI symbolsl.afm TI ZD
> ABI BMBI CBI download HB HNBI map/ NR PR symbolsl.pfb TR
> AI BMI CI enc/ HBI HNI NB PB S TB util/
> AR BMR CR EURO HI HNR NBI PBI SS TBI ZCMI
>
> Those extra files added to font/devpdf again by 'make install' (i.e.
> after 'make check' so we are installing files which were not present
> when the check was done), what have I done wrong - if you are saying
> it should not happen.
Yes, that should not happen. That's weird.
I'll go see if I can reproduce this misbehavior by attempting a groff
build targeting gropdf's basic service level. However, I reiterate that
this issue is irrelevant to the selection of "configuration A" versus
"configuration B". That decision is (should be) made by the build
system long before the "install" target does its work.
A difficulty I encountered recently is that weird/stupid things,
including multiple spurious rebuilds of groff documentation, can occur
if a directory is used for an out-of-tree build after having been once
used for an in-tree build (and not savagely cleaned afterward). I think
this has to do with the way out-of-tree build support ("VPATH") got
bolted onto the Make program well after its initial implementation.
(This precise semantics are, therefore, one of the areas where GNU Make
and BSD Make diverge.) The distinctions that Automake recognizes
between clean targets--they come in regular/unnamed, "distclean", and
"maintainer-clean" varieties--while necessary as far as I can see,
entangle with "the VPATH problem" in unpleasant ways.
So I must urge you (and anyone attempting to develop groff!) that if you
switch between in-tree and out-of-tree builds, to apply stern discipline
to keeping their respective source trees separate.
If you ever get frustrated with an ill-behaved build that seems to shift
underneath you like a serpent in the sand, I strongly recommend making a
fresh new directory and doing a build from a distribution archive, or
making a new Git working copy, from there. Evaluate _that_ for defects
in the build process. For the latter, I can't recommend highly enough
using one local checkout as the source for another. It's way faster to
update because you don't have to hit the network (except for an initial
fetch of gnulib, which is time-consuming and which aggrieves me because
the up-to-date submodule checkout IS SITTING RIGHT THERE, but for which
I hold no hope of resolution, ever[2]). This approach does of course
cost more in disk space.
> > We rely on a stamp file, font/devpdf/stamp. Unfortunately, the
> > stamp file is not made out of date by NOT removing files that it _no
> > longer_ depends on. So a possibility exists for running the tests
> > against a configuration that no longer reflects the state of the
> > system.
>
> Note the entire 'build' directory was removed prior to configure.
That sounds like a safe and advisable procedure (my "make-*-groff*"
scripts do the same, except when my `IN_TREE` shell variable is set
appropriately). However as noted above, a source directory can become
"tainted" by an in-tree build in ways that are difficult to detect. You
may need to run "git status --ignored" and watch out for entries marked
'!!'. Some of the commits I pushed yesterday were to remedy problems in
precisely this area.
Regards,
Branden
[1] gropdf(1):
URW font support
The traditional PostScript Type 1 fonts are limited in their glyph
repertoire, and the original versions from the Adobe foundry are
not free software. Historically, because their presence was
mandated by the PostScript standard, one could expect to find
support for them in any conforming device or software PostScript
renderer. PostScript (“Level 1”) initially standardized 14
typefaces: Times, Helvetica, and Courier each in four styles (which
groff groups into “families”); a symbol font; and a dingbats font.
PostScript Level 2 increased the number to 35, adding the families
Avant Garde, Bookman, Helvetica Narrow, New Century Schoolbook, and
Palatino; and a text font in one style, Zapf Chancery medium
italic. A document could be small because it did not need to embed
font resources unless it had unusual (for the time) glyph or
typeface requirements. This situation carried over into the early
years of PostScript’s successor page description language, PDF.
Nowadays, it is common to embed fonts in PDFs, and authorities
widely recommend this practice, which increases the reliability of
document rendering, and many free software fonts are available with
much greater glyph coverage than Adobe’s Type 1 fonts for
PostScript.
gropdf attempts to work in variety of scenarios, and delivers
better results when configured with supporting digital font files
(for embedding) and font metrics files describing those fonts to
the formatter.
• Full service is available when gropdf can locate all 35 fonts of
the PostScript Level 2 standard on the file system along with
their corresponding font metrics (AFM) files. The Adobe‐
compatible unnamed foundry supports up to 256 glyphs in each
typeface. Fonts from the URW foundry (“U”) are compatible
extensions of the Adobe fonts with extended glyph coverage,
including support for Cyrillic script.
• Intermediate service is available when gropdf can locate all 35
fonts of the PostScript Level 2 standard but not their
corresponding font metrics (AFM) files. Glyph coverage is
reduced to 256 glyphs maximum from each face, and the “U”
foundry is unavailable.
• Basic service results when gropdf cannot locate all 35 fonts of
the PostScript Level 2 standard. Only the base 14 fonts of the
PDF standard are available, and only in the sense that the
formatter can use their metrics. Use of the -e option to embed
fonts in the generated PDF results in an error.
[2] However, there is this ticket, which I still need to explore.
https://savannah.gnu.org/bugs/index.php?66804
signature.asc
Description: PGP signature
